-
Notifications
You must be signed in to change notification settings - Fork 109
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
Add download button for Usage reports #1149
Comments
Since generating a unique CSV enclosing all the topic sounds not sensible, I have decided to generate separated export files for each topic. These buttons are placed right-top above each yearly graph and basically its CSV associated represents the same data. @stephaniesimms and @sjDCC let me know what do you think... If you are happy with the changes, I can extend the Usage dashboard to include a third graph for no. plans for each template (from my org) in a yearly basis too. See current snapshot from PR #1157 below: |
Download button for each yearly topic. #1149
|
I thought the reports were just meant to be data per month with yearly totals. I think this would be enough rather than all data from beginning of time. We separate the Edinburgh stats out on an annual basis. |
Renamed export to download. DMPRoadmap#1149
hi @jollopre - i missed your note above about adding a third graph for no. plans for each template (from my org) in a yearly basis too. that would be great. it's a requirement for DMPTool to include all data in the CSV reports (per month since the Org joined). this provides trends for the Org over more than just the past year. and otherwise there's no way for an Org to assess previous year's data without contacting us. so please include everything in the CSVs. |
@stephaniesimms, is there any problem if we postpone that big download to after MVP release? Right now as we wanted something workable, the CSV files are calculated on demand, i.e. any time you press download in any topic, 12 queries to the db are send, one for each month. The ideal solution for this would be to have history tables that are updated automatically each month (e.g. cron job). That would mean that we would reduce from 12 to 1 query, however this is big chunk of work todo right now when multiple bugs addressing basic functionality are still on board. Can we create a high-priority ticket to implement this after MVC, please? |
As I understand it, the DMPTool approach is to have reports pre-generated each month so these don't need to be done on the fly. That would be better, but agree with post-MVP implementation is your users can wait a week or two for full stats @stephaniesimms? |
download buttons are implemented for 2 reports. additional usage dashboard work on post MVP board. closing this issue. |
Looks nice thanks @jollopre We can finesse this post MVP |
Org admins want to know the following (per @sjDCC comments on Edinburgh reports):
The text was updated successfully, but these errors were encountered: