feat(#10318): display previous month's targets when selected

[Edwin-Rugoogamu]

Description

Closes #10318

Core Functionality Implemented

Analytics Targets Component (analytics-targets.component.ts):

• Created an Angular component that displays health targets/metrics (e.g., births, registrations, visits)
• Integrated with the rules engine to fetch and display configured targets
• Added support for filtering by reporting period (current month vs. previous month)
• Implemented proper state management for loading, error handling, and disabled states
• Added performance tracking for analytics load times

Dynamic UI (analytics-targets.component.html):

• Built a responsive targets dashboard with sidebar filtering
• Implemented conditional rendering for different states (disabled, loading, no targets, errors)
• Added progress visualization for percentage-based targets and count displays for numeric targets
• Created dynamic subtitles that change based on selected reporting period:
  • "Current month" for current period
  • "All time" for previous period
  • Added contextual note "📅 Data up to the previous month" when viewing previous period data

Rules Engine Integration (rules-engine.service.ts):

• Extended the rules engine service to support target fetching with reporting period filtering
• Added fetchTargets() method that accepts 'current' or 'previous' reporting periods
• Integrated calendar interval logic to determine correct time ranges for target calculations
• Maintained existing task and emission monitoring functionality

Calendar Interval Service (calendar-interval.service.ts):

• Implemented utility methods for calculating calendar-based intervals
• Added getPrevious() method specifically for previous month reporting periods
• Ensured proper month boundary calculations for accurate target periods

Internationalization (messages-en.properties):

• Added comprehensive translation keys for target-related UI elements
• Included contextual messages for different reporting periods
• Added goal-related translations and error states

Key Features Delivered

1. Reporting Period Filtering: Users can switch between current month and previous month targets
2. Progress Tracking: Visual progress bars for percentage targets, numeric displays for count targets
3. Goal Achievement Indicators: Visual styling when targets meet or exceed goals
4. Error Handling: Graceful handling of disabled rules engine, loading states, and API errors
5. Performance Monitoring: Built-in performance tracking for target loading operations
6. Responsive Design: Sidebar integration with proper layout handling
7. Accessibility: Proper ARIA attributes and semantic HTML structure

[mrjones-plip]

Thanks for your submission @Edwin-Rugoogamu ! While I'll leave the larger, more formal code review to the previous performance squad, you can get a jump on improving this PR by fixing the failing CI with the linting and build errors. Please click into the failing checks to see the specific errors and ask questions here if you get stuck!

[Edwin-Rugoogamu]

Thanks for your submission @Edwin-Rugoogamu ! While I'll leave the larger, more formal code review to the previous performance squad, you can get a jump on improving this PR by fixing the failing CI with the linting and build errors. Please click into the failing checks to see the specific errors and ask questions here if you get stuck!

Hi @mrjones-plip The fixes for the eslint have been worked on. as reflected in the new commit (eslint fixes)

[mrjones-plip]

Thanks @Edwin-Rugoogamu ! That's helpful to smooth out before a formal code review.

Your new challenge is to resolve the conflicts in this branch 😅 As with the linting - please let us know if you need a hand! This too will be nice to smooth out before a formal code review.

[Edwin-Rugoogamu]

Thanks @Edwin-Rugoogamu ! That's helpful to smooth out before a formal code review.

Your new challenge is to resolve the conflicts in this branch 😅 As with the linting - please let us know if you need a hand! This too will be nice to smooth out before a formal code review.

Thanks @mrjones-plip . I have accepted all the incoming changes and adjusted variable(relevantInterval). Am also looking into the linting. Which had failled in the github actions pipeline

[mrjones-plip]

Nice work - thank you @Edwin-Rugoogamu ! It looks like just the title of the PR needs to pass lint now. Can you look into fixing that?

As well, I'll reach out back on Slack for someone to look at the actual code itself.

[Edwin-Rugoogamu]

Nice work - thank you @Edwin-Rugoogamu ! It looks like just the title of the PR needs to pass lint now. Can you look into fixing that?

As well, I'll reach out back on Slack for someone to look at the actual code itself.

Well noted

[jkuester]

Okay, so when this is all boiled down, it seems possible that the only real change will be to pass the param through in the analytics-targets component. That is pretty much expected given the other sub-issues that we have. 👍

---

@Edwin-Rugoogamu I think you said that Timothy was working on the test changes. Is he going to add those in a commit to this PR or in a separate PR? (Would be best for them to end up in this PR before we merge to the base branch just so we can keep everything straight...)

We can update the unit tests in analytics-targets.component.spec.ts:

• In the existing tests, assert the value of the parameter passed to the fetchTargets function (it is stubbed with sinon, so it should be easy to assert the args).
  • Would be nice to update one of the existing tests (if there is not one already) to set the reportingPeriodFilter value on the component and then assert that value is passed to fetchTargets.
• Add another test that calls getTargets directly with a reporting period param and assert that value is passed to fetchTargets and is set as the reportingPeriodFilter.

In the e2e tests, we can expand the filter test in analytics.wdio-spec.js to actually select the previous month and assert the targets display the expected values for the previous month. In the test setup, we will probably need to write some docs for the previous month so it gives us some target values.

---

Regarding the tests that are currently failing in the CI, I think that rolling back the UI changes (as I suggested) will resolve the problems in the ci-webdriver-default-workflows CI job. I think the ci-webdriver-default-core-minimum-browser test is just flaking out for some reason. 🤷 I cannot come up with any way your changes here would cause that test to fail. 🤔 I have triggered a re-run and will keep an eye on things and see if it ends up passing...

[jkuester]

Lets roll this back for now and wait for #10439 to make any changes to the UI.

Suggested change

	<!-- 🔹 Show “Current month” when current filter is selected -->
	<ng-container *ngIf="reportingPeriodFilter === 'current'; else previousSubtitle">
	{{ 'targets.this_month.subtitle' | translate }}
	</ng-container>
	<!-- 🔹 Show “All time” when previous month is selected -->
	<ng-template #previousSubtitle>
	{{ 'targets.all_time.subtitle' | translate }}
	<!-- Inline note: only show when previous period -->
	</ng-template>
	{{ target.subtitle_translation_key | translate }}

[Edwin-Rugoogamu]

Due to the label being static, The filtering does the sorting by date but leaves the labels constant. So when you click this month or last month the labels remain constant. So we decided to change the label according to what has been chosen . Though now differently as indicated in the new PR.

[jkuester]

As discussed at the squad meeting this week, we want to go ahead and leave this html as it is for now. We are continuing to discuss what the best approach will be for the UI changes. These will be implemented in r #10439.

[Edwin-Rugoogamu]

Am changing it first think tomorrow. Just got abit engaged.