MPDX-9327, MPDX-9670 - Fix MHA "Update Current MHA" button visibility and taken/approved amounts displays

[zweatshirt]

Description

• Fixes an issue where the Update MHA button renders when it shouldn't, ensuring a runtime error doesn't occur.
• Fixes the current approved overall amount and the taken amount to be grabbed from HCM where the actual values correctly reside. Prior to this, the UI would only display $0 amounts.
• Hides the 'Create New MHA' button if the current request has been finalized (board approved)

Testing

• Go to MHA Calculator impersonating Linda Sparkman
• Check that the amounts render correctly. She should not have a taken MHA amount unless she has filled out a Salary Request form, so $0 is correct here.
• Ensure that the Update MHA button hides appropriately, and renders appropriately.
• Ensure that the 'Create New MHA' button doesn't render when a board approved MHA exists.

Checklist:

• I have given my PR a title with the format "MPDX-(JIRA#) (summary sentence max 80 chars)"
• I have applied the appropriate labels (Add the label "Preview" to automatically create a preview environment)
• I have run the Claude Code /pr-review command locally and fixed any relevant suggestions
• I have requested a review from another person on the project
• I have tested my changes in preview or in staging
• I have cleaned up my commit history

[github-actions]

Preview branch generated at https://MPDX-9327-disable-update-mha.d3dytjb8adxkk5.amplifyapp.com

[github-actions]

Bundle sizes [mpdx-react]

Compared against 2cedf39

No significant changes found

[zweatshirt]

🤖 Multi-Agent Code Review — ✅ APPROVED WITH SUGGESTIONS

Mode: standard · Agents: 5 (Financial Reporting, Architecture, Testing, Standards, UX) · Risk: 4/10 (MEDIUM)

Solid, well-tested refactor: the MHA board-approved dashboard now reads authoritative per-person amounts from HCM (mhaRequest.currentApprovedOverallAmount / currentTakenAmount) via the context, instead of the never-populated request fields that rendered $0. It also fixes the same-value-for-both-rows bug and gates the "Request New MHA" / duplicate buttons. Net tech-debt reduction. No blockers. One Medium item flagged independently by 3 agents.

Medium (5.0) — null HCM amount renders $0.00 instead of an "unknown" state

The new amount cells are number | null; currencyFormat(Number(null)) → $0.00. On the same card, missing dates render a MUI <Skeleton>, so missing money showing a concrete $0.00 is inconsistent and — per this repo's Financial rule ("zero-state that looks like real data") — potentially misleading. It's a net improvement over prior behavior (which showed $0 for everyone) and is crash-safe (Number(null) = 0, no $NaN), so it's non-blocking. Consider rendering a Skeleton/em-dash when the value is null. Worth a one-line product confirmation on whether a board-approved MHA can legitimately be null. See inline comment.

Suggestions (informational, non-blocking)

• Add a null-amount test to pin the empty-state behavior (inline).
• The previous-approved card shows the current HCM snapshot, not the historical request's amount — correct today but a latent coupling; add a clarifying comment (inline).
• Test mocks use as unknown as HcmData — consistent with existing convention, informational.

Explicitly cleared (not issues)

• onError: () => {} on the duplicate mutation — acceptable; documented, and the global Apollo error link surfaces the failure.
• userHcmData?.mhaRequest.current* optional chaining — type-safe (mhaRequest is non-nullable in the schema) and matches 6+ existing usages. No $NaN path.
• Per-person wiring verified — no staff/spouse cross-wiring; locked by the new distinct-amounts test.

---

Findings on Related Files / Pre-existing (not line-anchored)

[Pre-existing · informational] CurrentBoardApproved.tsx:204 — spousePreferredName ? spousePreferredName : 'N/A' renders a hard-coded, non-localized 'N/A'. Predates this PR; not in a changed hunk. Consider a follow-up to wrap in t().

---

Agent	Critical	High	Important	Suggestions	Confidence
Financial Reporting	0	0	0	3	High
Architecture	0	0	0	1	High
Testing	0	0	0	3	High
Standards	0	0	0	2	High
UX	0	0	1	2	High
Total (deduped)	0	0	1	~4	High

Generated by /quality:agent-review (standard mode). Agents converged — no severity ≥7 findings and no conflicts, so the debate round was unnecessary.

[zweatshirt]

[Medium] Null HCM amount renders `$0.00` rather than an "unknown" state. These amounts are `number | null`, and `currencyFormat(Number(null))` → `$0.00` (applies to all four cells: 141, 174, 213, 249). On this same card, missing *dates* render a MUI ``, so missing *money* showing a concrete `$0.00` is inconsistent and can mislead staff about their approved/claimed MHA (the repo's Financial rule flags "zero-state that looks like real data"). Net improvement over the prior behavior and crash-safe (no `$NaN`), so non-blocking. Consider:

{userApprovedOverallAmount == null
  ? <Skeleton width={80} variant="text" />
  : currencyFormat(userApprovedOverallAmount, currency, locale, { showTrailingZeros: true })}

If a board-approved MHA can never legitimately be null, this is lower priority — worth a quick product confirmation. Flagged by UX, Financial, and Testing agents.

[zweatshirt]

This is usually preferred than an empty string

[zweatshirt]

[Suggestion] Add a test pinning the null-amount behavior, since this is a money display. A fixture already exists (HCM amounts can be `null`). Example:

it('renders $0.00 when HCM approved/claimed amounts are null', () => {
  // contextValue with userApprovedOverallAmount: null, userTakenAmount: null
  // assert the intended rendering (currently $0.00; or a dash if the Medium finding is adopted)
});

This locks whatever the chosen empty-state behavior is.

[zweatshirt]

[Suggestion] `CurrentBoardApproved` now sources its amounts from the HCM *current* snapshot (via context), not from the `request` prop it's handed. For this previous-approved card that's correct **today** — it only renders while the newer request is still pending, so the "previous" approval is the in-effect MHA that HCM's `current*` values describe. But it's an implicit coupling: if the `previousApprovedRequest` filter ever changes to show an older/superseded approval, the amounts would silently be wrong. A one-line comment noting "amounts intentionally reflect the in-effect approved request from HCM, not this row" would prevent a future footgun.

[github-actions]

AI Review Auto-Approval

Risk Level: MEDIUM (4/10)
Verdict: APPROVED_WITH_SUGGESTIONS (suggestions posted, no blockers)

This PR was auto-approved because:

• The multi-agent AI review determined it is medium risk
• No blocking issues were found
• All suggestions have been posted as review comments for the developer to consider

If you believe this PR needs human review, dismiss this approval and request a review manually.