Allow editing of aggregated reports for no longer existing age groups [3]

[sergiupacurariu]

Problem Description

The situation happens as follows:

• have data recorded to a disease without ageGroups
• re-configure ageGroups for that disease
• try to edit the data added before the ageGroups were configured which can be seen in reports
• when the edit form is opened the data will not be shown since it does not belong to any ageGroup. Further on it means you cannot edit it anymore.

Proposed Change

When building the list of AggregateReportForm, make sure that it contains entries for all existing data.

• [ ] Any existing data entry for an age group that no longer exists, should still be displayed and editable in the edit form
• [ ] Those entries should be first within the entries for the specific disease
• [ ] Those entries should be highlighted somehow, e.g. putting brackets around the age group name. If there is at least one entry, display an explanation at the bottom of the form "Age groups in brackets are based on existing data for an age group that is no longer used."

Example: We have defined the following age groups for a disease: 0-5, 6-10, 11+. For last week data was created using these. Starting this week we adjusted the age groups to 0-4, 5-9, 10+.

When opening the edit form display existing data entries that don't match a configuration anymore first, then follow-up with the configuration-based entries: 0-5, 6-10, 11+, 0-4, 5-9, 10+

Acceptance Criteria

• [ ] Outdated age group is still shown in the UI

Implementation Details

Additional Information

For the situation of a regular adjustment of age groups (not just a fix of a wrongly defined age group), we actually need a better solution. Ideally each configuration entry should have an optional usage time period, so that an age group can be valid until a specific date and another age group starting at a specific date. A separate issue will be created for this.

[MartinWahnschaffe]

@bernardsilenou Could have a look at this and especially the "to be refined" part, please? Let me know if you need more details.

[roxanamlendea]

I also encountered this issue while testing ticket #9119. When the edit form is opened and the data is not shown since it does not belong to any ageGroup, the user is unable to delete that specific Aggregate Report. If the users click on the Delete button, nothing happens.

[bernardsilenou]

@MartinWahnschaffe @sergiupacurariu

1. Is there a need to differentiate the old entries (for which no configuration exists) from new entries? Yes, there is a need to differentiate them because they are not the same data although the same disease. One configuration may not be possible to sum to get the other, eg old config== (0-5, 6-10) and new == (0-3, 4-6, 7-9)
2. If I understand well, the main issue here is that in the time window that we view the data, two different age groups were used to generate the data. I would vote for Option C == show only data for the active age group by default + allow editing of this data +
3. add a checkbox to show Option B . Allowing users to edit data from non-existing groups is optional, there is no harem preventing them from editing this data since the group is no longer existing. I think it may not good to allow users to edit data for existing and also non-twisting groups at the same time.
4. Users can export the data as points2. or 3.
5. Summary: we can archive data for non-existing groups but add a filter for users to view them and export them if needed
6. Users can also create anew report using the new age group

[MartinWahnschaffe]

@bernardsilenou and me had a meeting on this today and decided that the regular way of changing age groups should be changed with what I put into the additional information:

For the situation of a regular adjustment of age groups (not just a fix of a wrongly defined age group), we actually need a better solution. Ideally each configuration entry should have an optional usage time period, so that an age group can be valid until a specific date and another age group starting at a specific date. A separate issue will be created for this.

Still this issue is needed, because we will most likely not implement this soon and in addition to it, we still need a mechanism to handle wrongly configured age groups that are fixed, but already had some entries created based on the wrong age groups.

[sergiupacurariu]

@bernardsilenou @MartinWahnschaffe Regarding the second request from the requirements I think it is better to keep the actual age groups at the top. They are near the disease name and have better visibility for the user. I attached a screenshot from Aggregate report Edit form. The current "Buruli" disease does not have age groups anymore so moved at the bottom will be less visible that is in the current screenshot.

[roxanamlendea]

The text below the diseases needs to be adjusted accordingly the 'expired' label. The expired age groups are not marked with brackets, so the text is not correct.

[roxanamlendea]

When an aggregate report is created for a disease that does not have any age groups initially configured, when the age groups are configured, the entries that are expired look quite confusing for the user. This way the user might not know to which disease those values belong to..

As discussed with @MateStrysewske , a solution would be to have something like "No age group" or something similar.

[roxanamlendea]

Retested ticket on Sormas 1.76.0-SNAPSHOT (d90ec25) and I'm reopening the ticket because of the following issue:

1. In the db, configure age groups for the Buruli Ulcer disease;
2. In the UI, create an Aggregate Report with values for Buruli Ulcer (age groups configured);
3. From the db, remove the age groups configuration;
4. In the UI, open the Aggregate Report.

-> the 'Expired' label is displayed for the expired age groups, but the name of the disease is missing.

Age groups configured:

Age groups not configured:

[roxanamlendea]

Testing of the mobile app part is still blocked because of the synchronization issues (#10231)

[roxanamlendea]

Tested this ticket also on the Android App (because now the synchronization is working) and I'm reopening it because of a small UI issue.

The 'Expired' label is placed inaesthetically. It should be placed a little more to the right. Also, it would be nice if the 'Expired' label would be bolded, like in the vaadin app.

[roxanamlendea]

Verified ticket on local environment using the latest version of Sormas 1.76.0-SNAPSHOT from the development branch.