Bundle upload with no changes and report card updates breaking fresh sync

[mahalakshme]

Issue:

When some bundle upload made, - last_modified_date_time updated or just report card alone updated, then on fresh sync users will face the above issue - Soln: pace up the release

Steps to reproduce:

• Download bundle from an org: tried with JSCS and APF odisha
• note the last_modified_date_time of report cards
• upload the same bundle to the same org from where it was downloaded
• If you notice, the last_modified_date_time is updated from some of the report cards

Need:

New/fresh sync users will face the error on sync: 'card are mandatory for DashboardSectionCardMapping, Keys being saved...' when a bundle from UAT to prod is uploaded

Tech Analysis:

1) One reason is what we insert as standard_report_card_input in migration and what is inserted via bundle import is different

• {"programs": [], "subjectTypes": [], "encounterTypes": []} - via bundle import
• {} - via server migration

AC:

- Do the changes in new release branch forked from 10.0.0 since 10.0.1 server testing will probably take more time

• Block report card saving via bundle upload and via web UI for production organisations. Should be able to save for UAT and other type of organisations.
• show message on UI and bundle upload CSV error file that: 'Cant save new changes to report card. Report card features under maintenance. Please try again after few days.'

[petmongrels]

We cannot avoid last modified date time update as it is done by hibernate.

1. The problem seems to be only in report card.

select last_modified_date_time, age(last_modified_date_time, created_date_time) from dashboard_filter order by last_modified_date_time desc;
select last_modified_date_time, age(last_modified_date_time, created_date_time) from dashboard_section order by last_modified_date_time desc;
select last_modified_date_time, age(last_modified_date_time, created_date_time) from dashboard_section_card_mapping order by last_modified_date_time desc;
select last_modified_date_time, age(last_modified_date_time, created_date_time) from dashboard order by last_modified_date_time desc;
select last_modified_date_time, age(last_modified_date_time, created_date_time) from report_card order by last_modified_date_time desc;

2. Fix the last modified date time for report card to created date time value, if it is greater than our end of life date.
3. Fix the existing database records to to use {"programs": [], "subjectTypes": [], "encounterTypes": []} instead of {}

[mahalakshme]

@petmongrels yeah agreed - we cant avoid the last_modified_date_time update -I had added that as soln when I thought we are updating the last_modified_date_time for some reason, even when there are no changes, later realised the issue after tech analysis

2. How will existing users be able to sync the new changes done to report card.

[mahalakshme]

verified: production organisations are correctly marked as production in Category dropdown.

[himeshr]

Marking this card as 10.0 to be clear on where code changes are to be done, will use 10.0 branch offshot 10.0_hotfix for this.

[mahalakshme]

sure thanks @himeshr

[mahalakshme]

@himeshr dont know if reportDashboard.json will also update report card table in some cases - just sharing the scenarios that striked me.

[himeshr]

@himeshr dont know if reportDashboard.json will also update report card table in some cases - just sharing the scenarios that striked me.

Have handled all locations from where cardRepository.save() is invoked.

[himeshr]

Sample Error Responses as required after fix done in this card:

ReportCardBundleUploadError.csv

[himeshr]

Made additional changes to block Create/Update/Delete for CustomDashboard related entities listed below:

• Custom Dashboards
• DashboardFilter
• DashboardSections
• DashboardSectionCardMappings

[himeshr]

Currently, the only impact due to this issue is that Users Fresh Sync on old client will fail, in-case there is changes to reportCard and related entities after 26Sep2024. To handle this change, the data fix needed is to update lastModifiedDateTime to a value before 26Sep2024.

Not going ahead with the blocking approach, as we are not able to clearly reason out impact points and issues that might arise out of this change. Instead, see the changes being done as part of #802 to mitigate occurence of this error and a action plan to handle all future such errors.