Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monthly / weekly scheduled reports not working correctly #19674

Open
tarasowski opened this issue Aug 25, 2022 · 9 comments
Open

Monthly / weekly scheduled reports not working correctly #19674

tarasowski opened this issue Aug 25, 2022 · 9 comments
Labels
Potential Bug Something that might be a bug, but can't be reproduced (yet).

Comments

@tarasowski
Copy link

Expected Behavior

When email reports get created we want to get monthly / weekly stats.

Current Behavior

Scheduled monthly / weekly email reports display only data for the last day

Steps to Reproduce (for Bugs)

  1. Go to settings -> email reports
  2. Create a weekly or monthly report and lick on download or send per email

Your Environment

Latest Matomo version.

@tarasowski tarasowski added the Potential Bug Something that might be a bug, but can't be reproduced (yet). label Aug 25, 2022
@sgiehl
Copy link
Member

sgiehl commented Aug 25, 2022

Hi @tarasowski
The download button should actually let you download the scheduled report for the date / period selected in the global date selector. Same applies to the send report now button.
But reports send automatically should always contain the configured period.
But I agree that it should at least be displayed somewhere in the UI, that those buttons will use the selected date/period.

@sgiehl sgiehl added this to the For Prioritization milestone Aug 25, 2022
@tarasowski
Copy link
Author

Hi @sgiehl,
looks like it's not a bug, but a feature ;-) Let me test it again and see if it solves our issue.
Thank you!

@tarasowski
Copy link
Author

@sgiehl So tested it again as you mentioned, the report generated by the server still not showing the right time range.
I created a report for a week but it sends me a report for the last day only. Any idea what the problem could be?

@benj5378
Copy link

benj5378 commented Jun 15, 2023

I can confirm this bug on Mantomo WordPress plugin 4.14.2. Though here is a more thorough description:

When creating email reports, there is an option called "report period". While the graphs range is set separately, this option determines the data range in the tables of the email reports. If report period = days, tables should show data for 1 day back, if report period = weeks, tables should contain data for 1 week back, if report period = months, tables should have data for 1 month back.

But whatever option is chosen, the report range is always one day back! This renders the email reports useless in terms of all the tables. Please test the features before shipping - this is a pretty significant bug and should be prioritized.

Tagging @michalkleiner as it's relevant to fix together with #20738

@Stan-vw
Copy link
Contributor

Stan-vw commented Jul 20, 2023

Thanks for progressing this together. I've had a look at it with a few people, and made a simple visual overview of what I think the current situation is, with the challenge in red and an initial idea in green what we could do to improve it.

image

The send now/download buttons use the selected dates from the date picker in the top left. This doesn't seem to be a bug, but there seems to be consensus that the current state is not clear or necessarily intuitive.

In my view, there is a lot of merit to being able to get your regular reports for custom date ranges, so I don't think the send now/download buttons should be hardcoded to some logic that is fixed to the configured reporting period. But I agree we should make it clear what people are about to send/download.

Keen to get your thoughts on what the preferred solution/improvement is.

@michalkleiner
Copy link
Contributor

michalkleiner commented Jul 23, 2023

I would actually argue that, for the 'send via email' and 'download' actions from the UI, the reporting period should be what is set in the report configuration, and the trigger time is when the action is used, similarly to when run by cron.

A counter suggestion from me would be to display the reporting period as a column in the reports list (maybe dynamically updated showing the actual dates that it will produce), and possibly hide the global date selector for this UI view.

Or, another option, would be to have two sets of actions, one that creates the report based on the above (actual time and the configured reporting period), and one using the global period selector.

@bx80
Copy link
Contributor

bx80 commented Jul 23, 2023

I would actually argue that, for the 'send via email' and 'download' actions from the UI, the reporting period should be what is set in the report configuration, and the trigger time is when the action is used, similarly to when run by cron.

I’d agree it should have been that way from day one, but now there could be people who have gotten used to this as a way to quickly email reports for a custom time period, so we might not want to remove that capability.

A third option would be to have a drop down to choose the reporting period type next to the send / download actions.

@Stan-vw
Copy link
Contributor

Stan-vw commented Jul 27, 2023

I like the idea of a dropdown next to / when clicking on the buttons. E.g. you click on Download, and you can choose whether you get the monthly report or the report for the selected date range.

However, note that the likelihood of implementing the fix is higher when the work to fix it is smaller, as this issue is not critical.

@Javi-Ormaechea might have some thoughts on options here as well.

@heurteph-ei
Copy link

Next to the download / email links, you could provide a text / hint (or change the link text):
This will download the report for {{period}} period, as selected in the Matomo date selector

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Potential Bug Something that might be a bug, but can't be reproduced (yet).
Projects
None yet
Development

No branches or pull requests

7 participants