-
-
Notifications
You must be signed in to change notification settings - Fork 220
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
Fix standard_hq_report #35753
base: master
Are you sure you want to change the base?
Fix standard_hq_report #35753
Conversation
This combines the UCR version of getStandardHQReport, which the breaking change caused to no longer get called, into the logic in standard_hq_report.js. It sets up a js_options dictionary to use in UCR, which was previously using initial page data. It also eliminates the old block for handling custom reports, which should be irrelevant now that all custom reports use external js files and hqDefine, instead of ineline js and global variables.
This isn't necessary for UCRs. It's only used in getReportBaseUrl, which is used in getReportRenderUrl (which UCR overrides) and sendEmail (which doesn't currently matter because UCR emailing is broken for other reasons).
@orangejenny Hi Jenny, do you mind showing me the code that prove this? I trust you, I'm just curious. I searched
Also, I saw you're adding another |
Want to ask about this lint error too. It is unrelated to your change. Just curious what is it. I noticed we have migrated |
The reports class hierarchy is extensive. There isn't a single line that proves that all standard reports inherit from GenericReportView - each standard report is its own class, so you need to look at each of them. But to take one example, the Worker Activity report, you can trace the class hierarchy: GenericReportView > GenericTabularReport > WorkerMonitoringReportTableBase > WorkerMonitoringCaseReportTableBase > WorkerActivityReport. For others the hierarchy is shallower, like for the Project Performance report it's just: GenericReportView > ProjectReport > ProjectHealthDashboard Plus there are pages that aren't exactly reports but still use the same basic UI, which also typically inherit from GenericReport, like the Reassign Cases page (GenericReportView > DataInterface > BulkDataInterface > CaseReassignmentInterface). If you added About |
Product Description
https://dimagi.atlassian.net/browse/SAAS-16512
Fixes a bug where UCRs could not be saved as saved reports.
Technical Summary
Introduced in #35599, specifically the removal of the block here that handled UCRs by calling out to the UCR version of
getStandardReport
.getStandardReport
was split into a UCR version and a standard reports version many years ago, because UCRs were migrated to requirejs and standard reports were not. Now that all reports are on webpack, this PR merges the two sets of logic back into one. The UCR version included some UCR-specific analytics code that's staying in the UCR module.This means updating UCRs to use one big
js_options
object for report options, the way standard reports do, instead of passing the report options as individual pieces of data. Becausejs_options
is built in python, this highlighted that several of these options have never done anything in UCRs. Additional context on this...Standard reports all derive from
GenericReportView
, which sets up areport
object in the context here.In UCRs, the
report
in the context is the view itself (see here), which has some inconsistencies withGenericReportView
.Expressions like
report.filter_set
, which don't exist in the UCR view class, were previously failing silently when they got called during template rendering and are now removed. This also made it apparent that although UCRs haveemailable
set to True, the initial page data incorrectly referencedreport.is_emailable
and therefore the functionality wasn't working. I started to implement emailability for UCRs, since clearly that was the original intention, but I backed out after realizing that it would be more involved than expected.This PR does, however, turn on the export all functionality, which was similarly previously broken but now should work because
isExportAll
is now based on the realexportable_all
view attribute, instead ofis_export_all
which exists in the context of standard reports (see here) but doesn't exist in UCRs.This PR has made me much less fond of renames like this where the name changes but the meaning does not. Not that I was fond of them in the first place.
Feature Flag
UCRs
Safety Assurance
Safety story
I'm testing on staging. I'm leaning towards requesting QA to make sure I didn't break any other basic reports interaction in either standard reports or UCRs.
I've tested the inddex reports on staging.
Automated test coverage
No
QA Plan
https://dimagi.atlassian.net/browse/QA-7456
Rollback instructions
Labels & Review