in analytics, add an export button above the links graph

[mrhydejc]

On analytics page, add an export button above the links graph to export links's clicks details. #650
This information is not otherwise available.
Tested on my cluster.
This is my first experience in golang and vuejs. I hope I have followed the rules.

[mrhydejc]

it's look like this.

[knadh]

Thanks for the PR @mrhydejc

This is my first experience in golang and vuejs. I hope I have followed the rules.

I took a quick look and it looks like a surprisingly good PR for a first time Go / Vue commit! Will review properly over the weekend and submit comments.

[mrhydejc]

Thanks @knadh
I plan to make export for the others analtytics categories (view, click, bounce).
Would you like I push them with this PR or with separates PR.

About i18n, I duplicated the key subscribers.export to campaigns.analytics.export.
Shouldn’t I be merging them in a new key globals.buttons.export ? (Be careful of language packs)

[knadh]

Since it's one feature on the same page, it can be in the same PR. Yep, it should ideally be moved to globals.buttons.export.

[mrhydejc]

Okay, I’m done, you can review.
I am not satisfied with campaigns.go/handleGetCampaignAnalyticsExport().
I tryed to avoid to duplicate the main for loop but the solution I found use reflect. It's look like bad design and I like simple code.
Is there a better way to achieve this with golang? If not, I can refactor with 4 differents functions.

[knadh]

• handleGetCampaignAnalyticsExport() duplicates much of what handleGetCampaignViewAnalytics() already does. Querying DB for different types of stats, scanning results to a struct, sanitizing ... A better way would be to move this logic to a shared getCampaignAnalyticsData() or something and reuse that in the current JSON handler and in the new CSV export handler. Instead of adding new SQL queries, the existing queries can be reused (with some modifications to include any new fields required by the CSV export).

• campCountStats can be renamed to something a bit more generic like campStatsData, and the additional fields required by the CSV export can also be added there. Even if these new fields show up in the JSON API, it should be fine, but these fields can be selectively turned-off for JSON export by using json:"omitempty". This will eliminate a lot of type selection logic and reflection.

• The bounce export seems to be exporting subscriber data and not just aggregates. I think that's more appropriate on the Subscribers -> Bounces page.

[mrhydejc]

Hi @knadh, thanks you for the review.
Using single model with json:"omitempty" is a better approach !

Actually, my initial need is to export subscribers views and clicks with their timestamp.
As "Subscribers > Views" and "Subscribers > Clicks" pages does not exists, I thought it would be nice if the statistics CSV exports were not aggregated. It meets my need. I did the other ones (click + bounce) to make the feature consistent. (one export for each graph).
ATM, each export is not aggregated except click. (otherwise it would be the same as link's export)

With exports not aggregated, it could be difficult to share SQL as :

• There is GROUP BY for graphs and not for the CSV
• CSV's queries use OFFSET/LIMIT as there is lot more records.
  It’s probably could be done, but should we?

Do you want exports on statistics page to be aggregated (same datas as the graph) ?
If yes, should I :

• Update export on analytics pages with aggregated queries
• Create "Subscribers > Views" page and put the not-aggregated export on it (new PR)
• Create "Subscribers > Clicks" page and put the not-aggregated export on it (new PR)
• Move the not-aggregated Bounce export on "Subscribers > Bounces" (new PR)

[knadh]

Apologies for the super delayed response @mrhydejc. Wasn't able to find time to review the big PR in detail.

Just took a close look at this and also ran it locally on a large DB. It's almost there! Couple things:

• 2022/01/31 21:52:39 campaigns.go:735: error executing query: sql: Scan error on column index 2, name "suscriber_email": converting NULL to string is unsupported (when exporting clicks data)
• Could you resend the PR from a feature branch from your repo instead of master? That way, any final (minor) cosmetic tweaks I'd like to add to the PR can be merged alongside your commits.

[mrhydejc]

continue on #689