MPDX-9129 - MHA Eligibility check for new requests #1546

zweatshirt · 2025-12-11T18:15:12Z

Description

Determines MHA eligibility based on grahpql data.
Related API PR: https://github.com/CruGlobal/mpdx_api/pull/3090

Testing

Go to reports/housingAllowance
Test that the MHA EIT value is correctly pulled from the mock service on the backend
Check that the conditionals work as expected in the UI.
You may need to remove the current request that's set in the UI to check the New Request functionality.

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 · 2025-12-11T18:15:52Z

Preview branch generated at https://MPDX-9129.d3dytjb8adxkk5.amplifyapp.com

github-actions · 2025-12-11T18:25:06Z

Bundle sizes [mpdx-react]

Compared against cfa6ff2

No significant changes found

…odify tests

…nents

…thing helpful.

Copilot

Pull request overview

This pull request implements MHA (Minister Housing Allowance) eligibility checking based on GraphQL data from the backend. The feature adds a new mhaEit field with mhaEligibility boolean to HCM data and enforces eligibility checks when users attempt to create or update MHA requests.

Changes:

Added mhaEit.mhaEligibility field to GraphQL schema and mock data
Implemented eligibility state management in the context provider
Added eligibility checks to all MHA request mutations with user feedback via snackbar notifications
Updated display logic to show appropriate messages for ineligible users and spouses

Reviewed changes

Copilot reviewed 18 out of 18 changed files in this pull request and generated 13 comments.

Show a summary per file

File	Description
src/components/Reports/Shared/HcmData/HCMData.graphql	Added mhaEit field with mhaEligibility boolean to GraphQL query
src/components/Reports/Shared/HcmData/mockData.ts	Added mock data for various eligibility scenarios (single/married, eligible/ineligible combinations)
src/components/Reports/MinisterHousingAllowance/Shared/Context/MinisterHousingAllowanceContext.tsx	Added userEligibleForMHA, spouseEligibleForMHA, hcmLoading, and hcmError to context
src/components/Reports/MinisterHousingAllowance/MinisterHousingAllowance.tsx	Added eligibility check to new request creation with canAccessMHA logic
src/components/Reports/MinisterHousingAllowance/MainPages/IneligibleDisplay.tsx	Updated to show conditional messages based on user and spouse eligibility status
src/components/Reports/MinisterHousingAllowance/Steps/StepTwo/RentOwn.tsx	Added eligibility check to block updates when user is ineligible
src/components/Reports/MinisterHousingAllowance/Steps/StepThree/Calculation.tsx	Added eligibility check to updateCheckbox function
src/components/Reports/MinisterHousingAllowance/Shared/AutoSave/useSaveField.ts	Added eligibility check to saveField callback
Multiple test files	Added SnackbarProvider wrapper and test cases for eligibility scenarios

...components/Reports/MinisterHousingAllowance/Shared/AutoSave/AutosaveCustomTextField.test.tsx

Copilot · 2026-01-12T21:03:08Z

src/components/Reports/MinisterHousingAllowance/MainPages/IneligibleDisplay.tsx

+                  Once approved, when you calculate your salary, you will see
+                  the approved amount that can be applied to {preferredName}
+                  &apos;s salary. If you believe this is incorrect, please
+                  contact Personnel Records at 407-826-2236 or{' '}


The phone number in this error message (407-826-2236) differs from the phone number used in the earlier message on line 28 (407-826-2252). This inconsistency could confuse users. Verify which phone number is correct for Personnel Records and ensure it's used consistently throughout the component.

Suggested change

contact Personnel Records at 407-826-2236 or{' '}

contact Personnel Records at 407-826-2252 or{' '}

Already reached out to Ryan to find out what the correct number is. Awaiting a response.

src/components/Reports/MinisterHousingAllowance/Shared/AutoSave/useSaveField.ts

src/components/Reports/MinisterHousingAllowance/MinisterHousingAllowance.tsx

Copilot · 2026-01-12T21:03:10Z

src/components/Reports/MinisterHousingAllowance/MainPages/IneligibleDisplay.tsx

+        {!hcmLoading &&
+          ((isMarried && !spouseEligibleForMHA) || !userEligibleForMHA) && (
+            <Box mt={2} data-testid="user-ineligible-message">
+              <Trans i18nKey="userNotEligibleMha" values={{ preferredName }}>
+                <p style={{ lineHeight: 1.5 }}>
+                  Once approved, when you calculate your salary, you will see
+                  the approved amount that can be applied to {preferredName}
+                  &apos;s salary. If you believe this is incorrect, please
+                  contact Personnel Records at 407-826-2236 or{' '}
+                  <a href="mailto:MHA@cru.org">MHA@cru.org</a>.
+                </p>
+              </Trans>
+            </Box>
+          )}


The condition for displaying the user-ineligible-message has a logic issue. The current condition ((isMarried && !spouseEligibleForMHA) || !userEligibleForMHA) will show the user-ineligible message even when the user IS eligible if they're married and the spouse is ineligible. This doesn't match the intended behavior based on the test cases and the message content.

The condition should be checking if the user is NOT eligible, or if both are married and both are ineligible. Consider simplifying to just !userEligibleForMHA since this message is specifically about the user's eligibility status and when they can see approved amounts.

Suggested change

{!hcmLoading &&

((isMarried && !spouseEligibleForMHA) || !userEligibleForMHA) && (

<Box mt={2} data-testid="user-ineligible-message">

<Trans i18nKey="userNotEligibleMha" values={{ preferredName }}>

<p style={{ lineHeight: 1.5 }}>

Once approved, when you calculate your salary, you will see

the approved amount that can be applied to {preferredName}

's salary. If you believe this is incorrect, please

contact Personnel Records at 407-826-2236 or{' '}

<a href="mailto:MHA@cru.org">MHA@cru.org</a>.

</p>

</Trans>

</Box>

)}

{!hcmLoading && !userEligibleForMHA && (

<Box mt={2} data-testid="user-ineligible-message">

<Trans i18nKey="userNotEligibleMha" values={{ preferredName }}>

<p style={{ lineHeight: 1.5 }}>

Once approved, when you calculate your salary, you will see

the approved amount that can be applied to {preferredName}

's salary. If you believe this is incorrect, please

contact Personnel Records at 407-826-2236 or{' '}

<a href="mailto:MHA@cru.org">MHA@cru.org</a>.

</p>

</Trans>

</Box>

)}

Keeping this as is to match the criteria of the Figma doc. Can change if needed.

zweatshirt · 2026-01-12T21:32:17Z

@kegrimes You know MHA far more than I do. Before I ask Bizz for a review would you be up for looking through this quickly in case I missed something? Thanks Katelyn!

I am mostly looking to know if I have applied if statements to all MHA mutations, and if the state for IneligibleDisplay.tsx is correct.

I haven't actually been able to test this PR properly yet since we need to test an ineligible user.

zweatshirt · 2026-01-15T14:29:23Z

@dr-bizz I was going to ask Katelyn to review this since she knows MHA well but since she's sick I've added you. We can get her review when she comes back.

dr-bizz

This is looking good. I think we might need to add some functionality that works out who the MHA is for, the user or the spouse, but apart from that, it's looking great.

dr-bizz · 2026-01-15T14:49:31Z

...mponents/Reports/MinisterHousingAllowance/Shared/Context/MinisterHousingAllowanceContext.tsx

+  const userEligibleForMHA = useMemo(
+    () => userHcmData?.mhaEit?.mhaEligibility ?? false,
+    [userHcmData],


Do you think we should default to true while HCM is loading? So if HCM takes a while to load, it doesn't tell the user they can't create a MHA and then says it can.

This may be my preference, but I would prefer it to tell the user they can create an MHA, then tell them they can't, as this will affect less users.

dr-bizz · 2026-01-15T14:51:02Z

src/components/Reports/MinisterHousingAllowance/MinisterHousingAllowance.tsx

+    spouseEligibleForMHA,
  } = useMinisterHousingAllowance();

+  const canAccessMHA = userEligibleForMHA || spouseEligibleForMHA;


I thought they would have to switch screens to be a ble to see if their spouse is eligible?

What. if the primary user is not Eligible but the spouse is?

@dr-bizz I asked Katelyn about this and neither of us are sure what the intended behavior there is. I assumed that the form should only apply to the user if eligible, or both if both eligible. If it's true the form can still be filled out for the spouse when the user is ineligible, I'll change that.

I'll reach out to Ryan as well to get better understanding.

Refer to comment in IneligibleDisplay! I already heard from Ryan.

dr-bizz · 2026-01-15T14:52:28Z

src/components/Reports/MinisterHousingAllowance/MinisterHousingAllowance.tsx

+                {hasNoRequests || !canAccessMHA ? (
                  <IneligibleDisplay />


This code reads as if they have no requests they get the same message as users who are not eligilble for MHA

dr-bizz · 2026-01-15T15:03:02Z

src/components/Reports/MinisterHousingAllowance/Steps/StepTwo/RentOwn.tsx

  } = useMinisterHousingAllowance();

  const updateRequest = (id: string, rentOrOwn: MhaRentOrOwnEnum) => {
+    if (!userEligibleForMHA) {


What if they are filling it out for their spouse?

dr-bizz · 2026-01-15T15:05:01Z

src/components/Reports/MinisterHousingAllowance/Steps/StepThree/Calculation.tsx


-  const updateCheckbox = (value: boolean) =>
+  const updateCheckbox = (value: boolean) => {
+    if (!userEligibleForMHA) {


Again here, what if the user is filling the MHA out for their spouse whi is eligible?

dr-bizz · 2026-01-15T15:05:58Z

src/components/Reports/MinisterHousingAllowance/Shared/AutoSave/useSaveField.ts

      if (!requestData?.id) {
        return;
      }
+      if (!userEligibleForMHA) {


Do we need to work out who the MHA is for before saying the user is eligible

dr-bizz · 2026-01-15T15:07:27Z

src/components/Reports/MinisterHousingAllowance/MainPages/IneligibleDisplay.tsx

+        {!hcmLoading &&
+          isMarried &&
+          userEligibleForMHA &&
+          !spouseEligibleForMHA && (


What is the user is not eligible, but the spouse is?

I checked with Ryan and he said to display the same text that you would for a person who is eligible and has a spouse who is ineligible. The only difference would be flipping the names around! He is thinking that the request would be created for the person who is eligible.

kegrimes

This looks great Zach, thank you for doing this! I had a few comments, but overall this looks good. Ryan got back to me with the missing case (user ineligible, spouse eligible) so hopefully you can implement that easily!

kegrimes · 2026-01-16T18:32:31Z

src/components/Reports/MinisterHousingAllowance/MainPages/IneligibleDisplay.tsx

+        {!hcmLoading &&
+          isMarried &&
+          userEligibleForMHA &&
+          !spouseEligibleForMHA && (


I checked with Ryan and he said to display the same text that you would for a person who is eligible and has a spouse who is ineligible. The only difference would be flipping the names around! He is thinking that the request would be created for the person who is eligible.

kegrimes · 2026-01-16T18:43:04Z

src/components/Reports/MinisterHousingAllowance/MainPages/IneligibleDisplay.tsx

+        {!hcmLoading &&
+          ((isMarried && !spouseEligibleForMHA) || !userEligibleForMHA) && (


These checks feel like a lot in one place. Would we be able to extract these checks into a single variable instead? Even then, !hcmLoading and isMarried can possibly be it's own variable too.

const showSpouseIneligibleText = !hcmLoading && isMarried && userEligibleForMHA && !spouseEligibleForMHA

kegrimes · 2026-01-16T18:44:13Z

src/components/Reports/MinisterHousingAllowance/MinisterHousingAllowance.tsx

+    spouseEligibleForMHA,
  } = useMinisterHousingAllowance();

+  const canAccessMHA = userEligibleForMHA || spouseEligibleForMHA;


Refer to comment in IneligibleDisplay! I already heard from Ryan.

kegrimes · 2026-01-16T18:45:45Z

src/components/Reports/MinisterHousingAllowance/MinisterHousingAllowance.tsx

+    if (!userEligibleForMHA) {
+      enqueueSnackbar(t('You are not eligible to create a new MHA request.'), {
+        variant: 'error',


One thing I noticed in MHA is that a lot of the backend logic already had errors set up, so I was getting a double snackbar sometimes. I'm not sure if you did that in the backend, but if not, this is great!

We would probably want some form of frontend validation to avoid making uneccessary requests. Maybe it's best to disable fields if they are ineligible instead, but I'm wondering what the best way to notify the user of their ineligibility might be (assuming they manage to get this far)

Yeah, I think with eligibility, it would be best to disable "New Request" button and maybe have an information alert box on the main page. This is what Ryan and I did with edit access and the new component I created was a safety net incase a user saved the edit page but their access changed.

I plan to do that, but a user can technically bypass that right? I don't know enough about MHA. I assume disabling the fields will be sufficient in this case.

kegrimes · 2026-01-16T18:50:19Z

src/components/Reports/MinisterHousingAllowance/Shared/AutoSave/useSaveField.ts

      if (!requestData?.id) {
        return;
      }
+      if (!userEligibleForMHA) {


I am not sure if this logic will ever execute since #1539 adds two new components: no edit access and no request access. If a user does not have edit access (status is not in_progress or action_required), they will get a blank page explaining that. If a user is not eligible for mha, they will get a blank page explaining that as well.

Should I rebase onto that branch?

You could, I just might have some changes on that branch since it has not been reviewed yet!

kegrimes · 2026-01-16T18:52:40Z

src/components/Reports/MinisterHousingAllowance/Steps/StepThree/Calculation.tsx


-  const updateCheckbox = (value: boolean) =>
+  const updateCheckbox = (value: boolean) => {
+    if (!userEligibleForMHA) {


Same here, I don't think this logic will ever execute since they won't have access to this component.

kegrimes · 2026-01-16T18:53:45Z

src/components/Reports/MinisterHousingAllowance/Steps/StepTwo/RentOwn.tsx

  } = useMinisterHousingAllowance();

  const updateRequest = (id: string, rentOrOwn: MhaRentOrOwnEnum) => {
+    if (!userEligibleForMHA) {


zweatshirt self-assigned this Dec 11, 2025

zweatshirt added the Preview Environment Add this label to create an Amplify Preview label Dec 11, 2025

zweatshirt added the Staging API Run GraphQL codegen against the staging API label Dec 11, 2025

zweatshirt force-pushed the MPDX-9129 branch from 0eab8a6 to 8343163 Compare December 11, 2025 21:23

zweatshirt changed the title ~~MPDX-9129 - MHA Eligibility check~~ MPDX-9129 - MHA Eligibility check for new requests Dec 11, 2025

kegrimes mentioned this pull request Jan 8, 2026

MPDX-9176 Final tasks for MHA #1557

Open

6 tasks

zweatshirt added 7 commits January 12, 2026 10:18

Initial commit to integrate MHA eligibility: add HCM EIT checks and m…

1b0df9f

…odify tests

Fix eligibility display logic for spouse in IneligibleDisplay component

993e021

Add defensive check to stop mutations when ineligible

cf60178

Refactor eligibility checks for MHA requests and updates across compo…

d3e2df2

…nents

Add eligibility checks and update tests for MHA request components

5945ba5

Favor snackbar over disabling UI since this doesn't tell the user any…

bb8eacb

…thing helpful.

Add loading state and change IneligibleDisplay

e66290a

zweatshirt force-pushed the MPDX-9129 branch from ae08b9b to e66290a Compare January 12, 2026 20:33

zweatshirt removed the Staging API Run GraphQL codegen against the staging API label Jan 12, 2026

zweatshirt added 2 commits January 12, 2026 14:48

Fix IneligibleDisplay message logic again..

8d0681c

Run prettier

8f7a664

zweatshirt requested a review from Copilot January 12, 2026 20:57

Copilot started reviewing on behalf of zweatshirt January 12, 2026 20:58 View session

Copilot AI reviewed Jan 12, 2026

View reviewed changes

CruGlobal deleted a comment from Copilot AI Jan 12, 2026

Remove unused 'values' variable from useSaveField dependencies

9ca3d9c

CruGlobal deleted a comment from Copilot AI Jan 12, 2026

zweatshirt added 2 commits January 12, 2026 15:17

Update snackbar message for MHA request eligibility

64a45d0

Update test

20dd8d0

zweatshirt marked this pull request as ready for review January 12, 2026 21:30

zweatshirt requested a review from kegrimes January 12, 2026 21:31

zweatshirt requested a review from dr-bizz January 15, 2026 14:28

dr-bizz requested changes Jan 15, 2026

View reviewed changes

kegrimes requested changes Jan 16, 2026

View reviewed changes

	contact Personnel Records at 407-826-2236 or{' '}
	contact Personnel Records at 407-826-2252 or{' '}

		{!hcmLoading &&
		((isMarried && !spouseEligibleForMHA) \|\| !userEligibleForMHA) && (

MPDX-9129 - MHA Eligibility check for new requests #1546

Are you sure you want to change the base?

MPDX-9129 - MHA Eligibility check for new requests #1546

Uh oh!

Conversation

zweatshirt commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing

Checklist:

Uh oh!

github-actions bot commented Dec 11, 2025

Uh oh!

github-actions bot commented Dec 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bundle sizes [mpdx-react]

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Copilot AI Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

zweatshirt Jan 12, 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!

Uh oh!

Uh oh!

Copilot AI Jan 12, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zweatshirt commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zweatshirt commented Jan 15, 2026

Uh oh!

dr-bizz 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!

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!

Choose a reason for hiding this comment

Uh oh!

kegrimes 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zweatshirt commented Dec 11, 2025 •

edited

Loading

github-actions bot commented Dec 11, 2025 •

edited

Loading

zweatshirt Jan 12, 2026 •

edited

Loading

zweatshirt commented Jan 12, 2026 •

edited

Loading