feat(#10240): hide target counts past goal by cliftonmcintosh · Pull Request #10772 · medic/cht-core

cliftonmcintosh · 2026-03-27T21:40:48Z

Description

Outdated goals

This original approach has been superseded. See the Updated goals immediately below. For more context, please read the discussion.

Layout overlap: When a count number is large, it overlapped with the "Goal X" label. Fixed by converting the .count block to a flex column layout so the goal label and count number stack vertically instead of colliding.
Hide count past goal: Adds a new permission can_hide_target_count_past_goal. When a user has this permission, the count number is hidden on any target where pass >= goal. The goal label remains visible. This behavior is off by default (empty roles array in the default config).

Updated goals

Fix the layout overlap by centering the goal.
Add a field to the target object that allows people to specify that when the target is reached or exceeded, the UI is limited to showing the goal as the big number. For example if the target goal is 5000 and a user has reached a target count 10000, the UI for that target would show "Target 5000" in the small text at the top and "5000" in the larger text in the tile.
Any target data structure that does not have this field or does not have it set to true will default to the existing behavior -- the target count will be displayed even when it reaches or exceeds the goal.
No feature flag.

Closes #10240

Companion PRs

CHT-CONF: medic/cht-conf#800
CHT-DOCS: medic/cht-docs#2176

Questions

Layout overlap fix — approach feedback

I fixed the overlap by replacing the absolute-positioned goal label with a stacked flex layout (.count becomes display: flex; flex-direction: column; align-items: center, with the goal label above the count number, both centered). An alternative I considered was keeping the goal label in the top-right corner and adding right padding to .number when .has-goal is present (e.g., .has-goal .count .number { padding-right: 80px; }), which would be a smaller change but would offset the count number from true center. The padding approach would keep the count number visually off-center — it would be centered over the remaining space after reserving room for the goal label, not centered over the full card width. So on a wide card with a goal label, the big number would appear shifted left rather than truly centered. This approach is also fragile — it's a magic number that works for typical cases but can't guarantee no overlap for arbitrarily large numbers. Does the centered stacked layout work for you, or would you prefer the top-right approach?

Here is an example of the centering approach

Here is an example of the padding approach

What to hide

First off, if we center the goal, then do we need hiding? I've included it, but I want to raise the possibility that it might not be needed if we center the goal. I'm not sure what the use cases are, so I defer to you.

In one of @dianabarsan's comments, she said we should be

adding a setting to not display the goal OR target count past the goal

I chose to not display the target count because that was what I understood the suggestion to be. The example feature flag (can_hide_target_count_past_goal) mentioned in the issue points to that as the approach that was wanted, but it feels to me like having an empty target makes it look like the data is missing or the person has not met the goal.

What is preferred? Hiding the target? Hiding the goal? Something else? Here are some screenshots with different options. I think Option 2 works best.

I also wonder if maybe this isn't needed if we center both the goal and the target.

Option 1: Currently implemented -- hide only the target when goal is met or exceeded

Option 2: Hide only the goal when goal is met or exceeded

Option 3: Hide both the target and the goal when goal is met or exceeded

Option 4: Include a visual element showing the goal is met

AI Disclosure

I used Claude Code to help navigate the codebase, plan the approach, and write tests. I made all design decisions, reviewed all code, and verified the solution manually in the browser. I attributed Claude as a co-author on all commits that included the use of Claude Code.

If you would like to see them, I can provide a copy of the directions I gave Claude Code when starting the planning.

Code review checklist

UI/UX backwards compatible: Test it works for the new design (enabled by default). And test it works in the old design, enable can_view_old_navigation permission to see the old design. Test it has appropriate design for RTL languages.
Readable: Concise, well named, follows the style guide
Documented: Configuration and user documentation on cht-docs
Tested: Unit and/or e2e where appropriate
Internationalised: All user facing text
Backwards compatible: Works with existing data and configuration or includes a migration. Any breaking changes documented in the release notes.
AI disclosure: Please disclose use of AI per the guidelines.

Visual alignment fix for count widgets

I adjusted the alignment of the target tiles to aligns the count number display across count widgets that have a goal and those that do not.
Previously, the number position differed between the two variants, causing visual inconsistency
when both types appeared on the same Targets tab. Fixed by adding a minimum height to the number
container and using content justification to keep the number vertically centered regardless of
whether a goal is present.

Testing done

Unit tests

14 unit tests cover the AnalyticsTargetsComponent in
webapp/tests/karma/ts/modules/analytics/analytics-targets.component.spec.ts.
The following cases are specifically tested for the limit_count_to_goal behavior:

limit_count_to_goal: true, pass > goal → displays goal as the count number
limit_count_to_goal: true, pass === goal (boundary case) → displays goal
limit_count_to_goal: true, pass < goal → displays actual pass value
limit_count_to_goal absent → displays actual pass value even when goal is exceeded
limit_count_to_goal: true, goal: -1 (no goal) → displays actual pass value

All 14 tests pass.

Browser verification with dummy data

A dummy target (Earned Points, goal: 20000) was temporarily added to the component
to visually verify behavior in the browser under the following conditions:

Condition	`limit_count_to_goal`	`pass`	`goal`	Displayed
Count exceeds goal, field set	`true`	50,000	20,000	20,000 ✓
Count exceeds goal, field not set	absent	50,000	20,000	50,000 ✓
Count below goal, field set	`true`	19,999	20,000	19,999 ✓
Count equals goal (boundary), field set	`true`	20,000	20,000	20,000 ✓

Screenshots from testing

Screenshot: limit when target exceeds goal

Screenshot: no limit enforced when target exceeds goal

Screenshot: limit when target less than goal

Screenshot: limit when target equals goal

Screen recording: mobile-device-sized view

mobile-device-view-when-target-exceeds-goal.mov

End-to-end verification with real config data

The active-pregnancies target in config/default/targets.js was temporarily modified
to goal: 20, limit_count_to_goal: true and uploaded to the running local instance using
the local cht-conf build (which includes the companion schema and parse-targets changes).

After logging in as a CHW user with 33 active pregnancies, the target card correctly
displayed 20 (the goal) instead of 33 (the actual count), confirming the full data flow:

targets.js → cht-conf compile → CouchDB → rules-engine → target-state.js → component → UI

Screenshot: testing limit in view with active pregnancies

License

The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.

cliftonmcintosh · 2026-03-27T21:41:14Z

@dianabarsan or @mrjones-plip

Who should I ask to review this?

Replace absolute positioning of goal label with flex column layout to prevent overlap with large count numbers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…ssion Add can_hide_target_count_past_goal permission to control whether the count number is hidden for targets where pass >= goal. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…ion and goal combinations Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…default config Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh · 2026-03-27T21:44:25Z

webapp/src/css/targets.less

+        display: flex;
+        flex-direction: column;
+        align-items: center;


Centering the goal seems cleaner than trying to pad it in an absolute position in the top right corner. See my question about this in the PR description.

mrjones-plip · 2026-03-27T23:27:27Z

She's offline already, but @dianabarsan should be able to pick this up next week - thanks for reaching out!

FYI we're working with a bunch of new community members who are submitting a big collection of PRs - might be a hot minute but we'll get to this!

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

dianabarsan

Thanks for the quick work. I think the central alignment is the best (but I'm not a UX expert).

As for hiding the target count when it exceeds the goal, I believe we weren't trying to hide the actual number (like in your screenshots), rather just show the goal number instead of the actual target number. It's possible using a permission is not the best approach, maybe only some targets need their goals hidden?

I believe the context for hiding the exceeding number past the goal was in the cases where the target counts provided remuneration, in some cases once the "ceiling" (goal) was reached, not additional remuneration was offered.
for example, the chw would get paid:

$50 for a score of 500,
$100 for a target score of 1000 (the goal / ceiling)
$100 for a target score of 1500

Users would sometimes expect to be paid $200 if their target showed 2000. So then, these targets specifically would not show the actual number if it exceeded the goal.

For other targets, for example for pregnancy or delivery targets, i see absolutely no reason to hide the actual target number.

dianabarsan · 2026-03-30T12:41:00Z

webapp/src/ts/modules/analytics/analytics-targets.component.ts

+    this.authService.has(HIDE_COUNT_PAST_GOAL_PERMISSION).then(has => {
+      this.hideCountWhenGoalMet = has;
+    });


can this be simplified as ?

Suggested change

this.authService.has(HIDE_COUNT_PAST_GOAL_PERMISSION).then(has => {

this.hideCountWhenGoalMet = has;

});

this.hideCountWhenGoalMet = await this.authService.has(HIDE_COUNT_PAST_GOAL_PERMISSION);

Applied. I had to define ngOnInit as async, so I made a commit locally and pushed it

cliftonmcintosh · 2026-03-30T18:07:04Z

As for hiding the target count when it exceeds the goal, I believe we weren't trying to hide the actual number (like in your screenshots), rather just show the goal number instead of the actual target number.

Ahhh. That makes sense.

I should be able to adjust it so that when the flag is set and the goal is exceeded, we show the goal instead of the target count.

For other targets, for example for pregnancy or delivery targets, i see absolutely no reason to hide the actual target number.

Is there a way to distinguish which targets should not be hidden?

It's possible using a permission is not the best approach, maybe only some targets need their goals hidden?

Given the possiblity that some targets might not be hidden (like pregnancy or delivery targets) while some might be, what about an alternative approach like this:

Add a new field to the target data structure that allows people to say the target can't exceed the goal. Once the goal is reached, either the app stops incrementing the data or, if it does increment, we use that new field to decide to limit the target count in the UI to the goal amount.

Co-Authored-By: Diana Barsan <35681649+dianabarsan@users.noreply.github.com> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

dianabarsan · 2026-03-31T05:00:03Z

I believe adding a field to the target configuration is the way to go. There is no such field at the moment (hence the feature request :D :D )

either the app stops incrementing the data

I think this will have more implications. I think we should just manifest this setting in the UI and have the target document still register the actual number.

cliftonmcintosh · 2026-03-31T11:40:08Z

I believe adding a field to the target configuration is the way to go.

@dianabarsan Thanks. Based on the feedback so far, can I state what I think the goals are?

Fix the overlap by centering the goal (like in the screenshots I've provided)
Add a field to the target object that allows people to specify that when the target is reached or exceeded, the UI is limited to showing the goal as the big number. For example if the target goal is 5000 and a user has reached a target count 10000, the UI for that target would show "Target 5000" in the small text at the top and "5000" in the larger text in the tile.
Any target data structure that does not have this field or does not have it set to true will default to the existing behavior -- the target count will be displayed even when it reaches or exceeds the goal.
No feature flag

Does that capture what we're thinking?

dianabarsan · 2026-03-31T13:51:50Z

@cliftonmcintosh nailed it!!

This reverts the changes made in the following commits: - da8c6a3 - 13d2919 - 5b305d3 - 95e1d0f - e2ef816 - 8247ce0

…al is set Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

… goals Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…et aggregation Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh · 2026-03-31T20:15:33Z

webapp/src/css/targets.less

+        justify-content: flex-end;
        text-align: center;
+        min-height: 74px;


The change for justify-content and min-height aligns the count number display across count widgets that have a goal and those that do not.
Previously, the number position differed between the two variants, causing visual inconsistency
when both types appeared on the same Targets tab. Fixed by adding a minimum height to the number container and using content justification to keep the number vertically centered regardless of whether a goal is present.

Before

See how the big number sits down lower whenever there is a goal?

After

Now the big numbers stay at the same height in targets that have goals and targets that don't have goals.

Yea, I don't like the big number offset either. I'm wondering whether the best visual solution is to move the goal underneath the number and conditionally display it. Then we won't have all this extra padding.

I'm wondering whether the best visual solution is to move the goal underneath the number and conditionally display it. Then we won't have all this extra padding.

I can work up that as an option and provide a screenshot. Or if you are confident that is a change to make, I can go ahead and do it. Let me know, please.

I've moved the goal so it is below. Here is a screenshot. Tell me what you think, please.

cliftonmcintosh · 2026-03-31T20:18:53Z

Updated based on our revised approach.

I've added a "Testing done" section to the description. It has screenshots of various scenarios.

I've also opened companion PRs for cht-conf and cht-docs.

shared-libs/rules-engine/src/target-state.js

cliftonmcintosh · 2026-04-01T13:30:33Z

Will the test at tests/e2e/visual/targets/targets-overview.wdio-spec.js need any adjustment? It ends with a call to generateScreenshot('targets', 'overview'). Is there some sort of reference screenshot that we will need to update to go with the visual changes?

cliftonmcintosh · 2026-04-01T13:36:27Z

As I understand it, if we want an e2e test for the new field, we will depend on the cht-conf PR being
merged and the cht-conf package version bumped in cht-core before we can write a successful e2e test for a target that has limit_count_to_goal: true and a goal lower than the count. Is that accurate?

If so, I think that means we would pause this until a new version of cht-conf is published and can be brought in as a dependency in cht-core.

dianabarsan · 2026-04-01T16:06:44Z

I didn't end up having space for this today. I'll check on it tomorrow.

dianabarsan · 2026-04-03T11:42:19Z

Will the test at tests/e2e/visual/targets/targets-overview.wdio-spec.js need any adjustment? It ends with a call to generateScreenshot('targets', 'overview'). Is there some sort of reference screenshot that we will need to update to go with the visual changes?

No, you can safely ignore those. They haven't been introduced in our CI suite and not run regularly.
As for reference screenshot! Yes, we will need to update our docs site, but that can come before releasing.

dianabarsan · 2026-04-03T11:43:59Z

As I understand it, if we want an e2e test for the new field, we will depend on the cht-conf PR being merged and the cht-conf package version bumped in cht-core before we can write a successful e2e test for a target that has limit_count_to_goal: true and a goal lower than the count. Is that accurate?

If so, I think that means we would pause this until a new version of cht-conf is published and can be brought in as a dependency in cht-core.

Not necessarily. You can install a branch cht-conf version instead of the latest release in this branch, and then the property will be available to use.

npm install github:cliftonmcintosh:feat/10240-hide-target-counts-past-goal

We would, indeed, need to publish the cht-conf package before merging this PR, as reverting to the latest released cht-conf will be required.

dianabarsan

So far excellent work, as usual!
I added one question about alternative styling and replied to the e2e questions.

dianabarsan · 2026-04-03T11:50:40Z

webapp/src/css/targets.less

+        justify-content: flex-end;
        text-align: center;
+        min-height: 74px;


Yea, I don't like the big number offset either. I'm wondering whether the best visual solution is to move the goal underneath the number and conditionally display it. Then we won't have all this extra padding.

dianabarsan · 2026-04-03T11:52:30Z

webapp/src/ts/modules/analytics/analytics-targets.component.ts

  }
+
+  getDisplayCount(target: any): number {
+    if (target.limit_count_to_goal && target.goal >= 0 && target.value?.pass >= target.goal) {


Awww, negative goals are out? is the goal positive check necessary?

ah I see, it's in case someone creates a target without a goal and then sets limit_count_to_goal to true?

it's in case someone creates a target without a goal and then sets limit_count_to_goal to true

Yes!

cliftonmcintosh · 2026-04-03T12:24:06Z

You can install a branch cht-conf version instead of the latest release in this branch, and then the property will be available to use.

If it makes it easier to review, I can go ahead and do this and then we can revert to the latest after the cht-conf change is merged. Please let me know if you prefer that or prefer to wait until the cht-conf changes are merged.

dianabarsan · 2026-04-03T12:42:19Z

If it makes it easier to review, I can go ahead and do this and then we can revert to the latest after the cht-conf change is merged. Please let me know if you prefer that or prefer to wait until the cht-conf changes are merged.

We have done this numerous times, I prefer it and suggest it. No reason to block on the other work.

…support

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…across target cards Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh · 2026-04-03T18:55:58Z

If it makes it easier to review, I can go ahead and do this and then we can revert to the latest after the cht-conf change is merged. Please let me know if you prefer that or prefer to wait until the cht-conf changes are merged.

We have done this numerous times, I prefer it and suggest it. No reason to block on the other work.

I've added e2e tests with the cht-conf dependency set to my branch.

cliftonmcintosh · 2026-04-03T18:56:46Z

package.json

    "chai-shallow-deep-equal": "^1.4.6",
    "chai-things": "^0.2.0",
    "chokidar": "^4.0.3",
-    "cht-conf": "^6.0.2",


Reminder that this needs to be changed before merging.

cliftonmcintosh · 2026-04-03T18:57:46Z

package-lock.json

The changes in this file are because of the temporary change to the cht-conf dependency. They should be reverted when we update that dependency again.

cliftonmcintosh and others added 5 commits March 27, 2026 16:42

fix(medic#10240): fix count target layout overlap with goal label

35e80e2

Replace absolute positioning of goal label with flex column layout to prevent overlap with large count numbers. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(medic#10240): hide count number when goal is exceeded with permi…

da8c6a3

…ssion Add can_hide_target_count_past_goal permission to control whether the count number is hidden for targets where pass >= goal. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(medic#10240): test count number visibility for different permiss…

13d2919

…ion and goal combinations Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(medic#10240): assert permission string when hiding count past goal

5b305d3

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(medic#10240): add can_hide_target_count_past_goal permission to …

95e1d0f

…default config Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh force-pushed the feat/10240-hide-target-counts-past-goal branch from bb658e7 to 95e1d0f Compare March 27, 2026 21:42

cliftonmcintosh commented Mar 27, 2026

View reviewed changes

mrjones-plip requested a review from dianabarsan March 27, 2026 23:26

feat(medic#10240): test that count is shown when target has no goal

e2ef816

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh changed the title ~~Feat/10240 hide target counts past goal~~ feat(#10240) hide target counts past goal Mar 28, 2026

cliftonmcintosh changed the title ~~feat(#10240) hide target counts past goal~~ feat(#10240): hide target counts past goal Mar 28, 2026

dianabarsan requested changes Mar 30, 2026

View reviewed changes

feat(medic#10240): use async/await for permission check in ngOnInit

8247ce0

Co-Authored-By: Diana Barsan <35681649+dianabarsan@users.noreply.github.com> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh and others added 4 commits March 31, 2026 12:55

Revert feature flag additions

123bb09

This reverts the changes made in the following commits: - da8c6a3 - 13d2919 - 5b305d3 - 95e1d0f - e2ef816 - 8247ce0

feat(medic#10240): cap displayed count at goal when limit_count_to_go…

9c6aa21

…al is set Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix(medic#10240): align count numbers across targets with and without…

b0347ca

… goals Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(medic#10240): pass limit_count_to_goal through rules engine targ…

fc76773

…et aggregation Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

This was referenced Mar 31, 2026

feat(#10240): allow limit_count_to_goal in target configuration schema medic/cht-conf#800

Open

feat(#10240): add limit_count_to_goal field to targets reference medic/cht-docs#2176

Open

cliftonmcintosh commented Mar 31, 2026

View reviewed changes

cliftonmcintosh requested a review from dianabarsan March 31, 2026 20:16

cliftonmcintosh commented Mar 31, 2026

View reviewed changes

shared-libs/rules-engine/src/target-state.js Outdated Show resolved Hide resolved

fix(medic#10240): fix line length linting error in target-state.js

588de79

dianabarsan reviewed Apr 3, 2026

View reviewed changes

cliftonmcintosh and others added 3 commits April 3, 2026 13:38

chore(medic#10240): install cht-conf branch with limit_count_to_goal …

a0c6c04

…support

feat(medic#10240): add e2e test for limit_count_to_goal target display

470c115

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

fix(medic#10240): move goal text below count number to align display …

e7a8831

…across target cards Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

cliftonmcintosh commented Apr 3, 2026

View reviewed changes

cliftonmcintosh requested a review from dianabarsan April 3, 2026 19:48

Uh oh!

Conversation

cliftonmcintosh commented Mar 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Outdated goals

Updated goals

Companion PRs

Questions

Layout overlap fix — approach feedback

What to hide

AI Disclosure

Code review checklist

Visual alignment fix for count widgets

Testing done

Unit tests

Browser verification with dummy data

Screenshots from testing

End-to-end verification with real config data

License

Uh oh!

cliftonmcintosh commented Mar 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrjones-plip commented Mar 27, 2026

Uh oh!

dianabarsan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cliftonmcintosh commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianabarsan commented Mar 31, 2026

Uh oh!

cliftonmcintosh commented Mar 31, 2026

Uh oh!

dianabarsan commented Mar 31, 2026

Uh oh!

cliftonmcintosh Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cliftonmcintosh commented Mar 31, 2026

Uh oh!

Uh oh!

cliftonmcintosh commented Apr 1, 2026

Uh oh!

cliftonmcintosh commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianabarsan commented Apr 1, 2026

Uh oh!

dianabarsan commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianabarsan commented Apr 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dianabarsan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cliftonmcintosh commented Mar 27, 2026 •

edited

Loading

cliftonmcintosh commented Mar 30, 2026 •

edited

Loading

cliftonmcintosh Mar 31, 2026 •

edited

Loading

cliftonmcintosh commented Apr 1, 2026 •

edited

Loading

dianabarsan commented Apr 3, 2026 •

edited

Loading

dianabarsan commented Apr 3, 2026 •

edited

Loading