MPDX-9838 Add HR Tools and partner reminders to prod

[kegrimes]

Description

Set to merge on Thursday, July 16th, 2026

Since Ministry Partner Reminders broke in staff web, we want to release this report before HCM go-live. We need to add HR Tools and partner reminders to production.

Production: DISABLE_NEW_REPORTS=true, DEVELOPMENT_ENV=false, user_type_verified="false" (no modal), and us_staff_group=null (no HCM data)

Testing

User type has NOT been verified in the modal (this is what will happen in production)

user_type_verified: 'false'

US staff production test: ✅

• Set DISABLE_NEW_REPORTS to true in your local
• Impersonate: dave.cook@crumilitary.org
• Verify that "HR Tools" is present with only Ministry Partner Reminders
• Go to /hrTools/partnerReminders
• Check that the page is accessible

Non-US staff production test: ✅

• Set DISABLE_NEW_REPORTS to true in your local
• Log in to the test account (it is seen as Global right now)
• Verify that "HR Tools" is NOT present

US staff non-production test: ✅

• Set DISABLE_NEW_REPORTS to false in your local
• Impersonate: dave.cook@crumilitary.org
• Verify that "HR Tools" is present with only Ministry Partner Reminders (user group is null and user type verified is false - no HCM data and no modal)
• Go to /hrTools/partnerReminders
• Check that the page is accessible

User type has been verified in the modal...

user_type_verified: 'true'

... AND HCM data exists (this is similar to what devs should see locally)

US staff non-production test: ✅

• Set DISABLE_NEW_REPORTS to false in your local
• Impersonate: courtney.campbell@cru.org
• Verify that "HR Tools" is present with all eligible reports
• Go to /hrTools/partnerReminders
• Check that the page is accessible

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-9838-add-partner-reminders-to-prod.d3dytjb8adxkk5.amplifyapp.com

[github-actions]

Bundle sizes [mpdx-react]

Compared against 06663d6

Route	Size (gzipped)	Diff
/accountLists/[accountListId]/hrTools/partnerReminders	281.73 KB	+2.08 KB

[kegrimes]

🤖 Multi-Agent Review — PR #1905

Verdict: ✅ APPROVED WITH SUGGESTIONS · 0 blockers · Risk 3/10 (LOW)
Agents: Security, Architecture, Testing, Standards, UX (standard mode)

The refactor is sound: moving the reportsDisabled gate from tab-level to item-level is a net tech-debt reduction (removes duplicated gating between useNavPages and useHrToolsNavItems), dependency arrays are correct, no consumer breaks, and server-side authorization (blockImpersonatingNonDevelopers + API account-list scoping) is unchanged and consistent with all 11 sibling HR Tools pages.

Medium-priority findings (see inline comments)

1. // TODO without a ticket ref — load-bearing: it's the only record that partnerReminders is intentionally un-gated and must be re-gated post-HCM. (Standards, Architecture, Testing, UX)
2. reportsDisabled fails open while the separate UserOption query loads → flash-of-extra-items when reports go live (dormant today under DISABLE_NEW_REPORTS=true); also makes the NavMenu unverified test timing-sensitive. (UX, Testing)
3. Prod kill-switch (DISABLE_NEW_REPORTS=true) is untested, and the "only partner reminders" hook tests use an ineligible user, so deleting the new reportsDisabled || prefixes would still pass them — the gate isn't isolated. (Testing)

Suggestions (non-blocking)

• No colocated tests for useNavPages.tsx and useReportsDisabled.ts (the latter covers finding #3 cheapest at the source).
• Item-level reportsDisabled || diverges from useReportNavItems's conditional-spread — intentional and correct (one item must be exempted); noted so it isn't mistaken for inconsistency.
• hrToolsItems.length === 0 in hideTab is now dead post-load — harmless safety net.

Recommended before merge: the two cheap wins that pay off at HCM launch — add a ticket to the TODO, and make reportsDisabled fail closed (expose loading, treat as disabled until known), which kills both the flash and the test flakiness in one change.

[github-actions]

AI Review Auto-Approval

Risk Level: LOW (3/10)
Verdict: APPROVED_WITH_SUGGESTIONS (suggestions posted, no blockers)

This PR was auto-approved because:

• The multi-agent AI review determined it is low 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.

[kegrimes]

@canac Can you glance over this for me? I think I have everything covered since there are certain things that will always be true in production:

• DISABLE_NEW_REPORTS=true
• DEVELOPMENT_ENV=false
• user_type_verified="false" because there is no modal (although there may be a few people who have it set to true when the modal was out accidentally but it should not matter)
• us_staff_group=null because there is no HCM data

I'm also wondering if we should add the UserTypeAccess gate back on without requiring the staff account id. This way only US staff can see the report which is what is happening in the nav bar anyway.

[canac]

The logic looks great to me! I assume we're not merging this PR until Scott is ready for it to go out.

[kegrimes]

@canac Sorry, did you see this question?

I'm also wondering if we should add the UserTypeAccess gate back on without requiring the staff account id. This way only US staff can see the report which is what is happening in the nav bar anyway.

[canac]

I'm also wondering if we should add the UserTypeAccess gate back on without requiring the staff account id. This way only US staff can see the report which is what is happening in the nav bar anyway.

Sorry, I did miss that question! Yes, I think you can add the UserTypeAccess check back if people's user types are pretty accurate! I know you and Justin were working on fixing some issues with that on the backend. This would mean global staff would see the menu item, but when they go to the page, they will get a limited access message, right?

[kegrimes]

This would mean global staff would see the menu item, but when they go to the page, they will get a limited access message, right?

@canac Actually I've made it where global and non-Cru staff won't see the HR tools tab. Ministry Partner Reminders will only be available to US and hybrid staff members!