EPIC: View previous reporting period in aggregate targets

[michaelkohn]

Users with access to Aggregate Targets can now view data from the previous reporting period. This includes the high level aggregates (in the list view) as well as the detail view (each CHW's individual contribution). This capability is only for aggregate targets, not personal targets.

1. When viewing Aggregate Targets Page | List View, users know which reporting period they are looking at because a second line has been added under each list view row that indicates whether it is this month or last month
2. Users can choose which reporting period to view by tapping on a new filter icon, they are familiar with this icon because it is the same icon that is on the reports page
3. When a user taps on the filter icon, they see a menu drawer appear from the right side of the screen
4. The menu drawer contains an option to view the current month or last month
5. Current Month is always defaulted
6. In the detail view, the filter icon is no longer visible but the user knows which reporting period they are looking at because the column headers for the data field clearly indicates which reporting period is being viewed
7. From telemetry, it is possible to know how often users view the previous month's data

Figma mockups

[Benmuiruri]

There are two parts to accomplishing the feature as mentioned above:

Displaying Sidebar Filter

• We can have a button in webapp/src/ts/components/filters/analytics-filter/analytics-filter.component.html that emits an event.
• The event is handled in webapp/src/ts/modules/analytics/analytics.component.ts and forwarded to webapp/src/ts/modules/analytics/analytics-target-aggregates.component.ts
• We create a webapp/src/ts/modules/analytics/analytics-target-aggregates-sidebar-filter.component.html filter with the radio buttons that determine the aggregate targets displayed by webapp/src/ts/modules/analytics/analytics-target-aggregates.component.ts

Filtering the Aggregate Targets

• In the created sidebar filter, we have the two radio buttons to choose this month or last month.
• clicking the radio button fires onPeriodChange() which updates a value this.selectedPeriod and calls getTargetAggregates() code
• Update this.targetAggregatesService.getAggregates() code to accept and forward the selectedPeriod value (default being current month).
• Add a getPreviousIntervalTag similar to the existing getCurrentIntervalTag method that gets the data for previous month.
• Update fetchLatestTargetDocs to receive the selectedPeriod flag and either fetch current or previous month records.
• display the text this month or last month text depending on the value of selectedPeriod

@michaelkohn Overall I would say it's a weeks worth of work (If I have not overlooked something)

@latin-panda Please share your thoughts on my conceptual plan and whether I may have overlooked anything.

@ralfudx Heads up on what I may be working on soon, once I start I will share my testing plan and get your thoughts on it.

[latin-panda]

Overall I would say it's a weeks worth of work (If I have not overlooked something)

I would add 1 extra week for test coverage (mobile and desktop devices) and UI fixes for device resolution

@Benmuiruri, Can you try hardcoding a previous period in fetchLatestTargetDocs and see if CHT can generate the targets of previous months? Because if CHT doesn't generate accurate targets, we need to fix it, and it will increase the development timeline

This feature needs data from previous months, so app builders need to consider that when configuring purging.

This filter is only for target aggregates, right?

[Benmuiruri]

@latin-panda I was able to hardcode the previous period.

I got the results I expected -> 2 death reports. In the console, I see the data I expect -> 2 death reports fetched for (05 - May) Period

And in this second screenshot I see the data I expect -> 3 death reports fetched for (06 - June) Period

[latin-panda]

That's good news, thanks @Benmuiruri!

The first deliverable of this work will be:

• Add the filter sidebar and the filter by users' assigned facilities.
• We will try to make the label of that filter based on the first assigned facility's contact type.
  • If it's too hard, then we add a default translation key that later projects can customize
• The default filter is the first user's assigned facility

@Benmuiruri Can you please split the task into smaller tickets? You can create a add-filters-aggregte-targets branch for this feature, and then we merge smaller PRs into that branch. When the work is 100% ready, we merge add-filters-aggregte-targets into master for release.

@ralfudx how can you best support us on this work? Ideas:

• Code e2e in parallel with Ben - taking as reference existing test in Reports's filter sidebar.
• _____? What else?

[michaelkohn]

• I've created https://github.com/medic/care-teams/issues/136 for filtering by facility_id.
• We can keep https://github.com/medic/care-teams/issues/123 for filtering by reporting period.
• I'd love if both of those tickets get broken down into individual components like we did for https://github.com/medic/care-teams/issues/120

[Benmuiruri]

I have broken down the EPIC: Filter aggregate targets by facility_id into its 4 deliverables.

Once that EPIC is complete, most of the work will have been done. The remaining component to complete EPIC: View previous reporting period in aggregate targets will be:

• [ ] https://github.com/medic/care-teams/issues/141

[ralfudx]

@latin-panda thanks for initiating ideas around this - I'll have a deeper look at the epic and sync with @Benmuiruri to better understand the deliverables