Skip to content

Hdpi 3764 income expenditure frontend#989

Open
arun-hmcts wants to merge 25 commits intomasterfrom
HDPI-3764-income-expenditure-frontend
Open

Hdpi 3764 income expenditure frontend#989
arun-hmcts wants to merge 25 commits intomasterfrom
HDPI-3764-income-expenditure-frontend

Conversation

@arun-hmcts
Copy link
Copy Markdown
Contributor

@arun-hmcts arun-hmcts commented Mar 25, 2026

Jira link

https://tools.hmcts.net/jira/browse/HDPI-3764

Change description

Testing done

image

Security Vulnerability Assessment

CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?

  • Yes
  • No

Checklist

  • commit messages are meaningful and follow good commit message guidelines
  • README and other documentation has been updated / added (if needed)
  • tests have been updated / new tests has been added (if needed)
  • Does this PR introduce a breaking change

const possessionClaimResponse: PossessionClaimResponse = {
defendantResponses: {
householdCircumstances: {
shareIncomeExpenseDetails: toYesNoEnum(provideFinanceDetails),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field uses backend YesOrNo not VerticalYesNo type, so can we send canonical values ("Yes" / "No") instead of "YES" / "NO" for consistency with the API contract?

* toYesNoEnum('NO') // returns 'NO'
*/
export function toYesNoEnum(value: 'yes' | 'no'): YesNoValue {
return value.toLowerCase() === 'yes' ? 'YES' : 'NO';
Copy link
Copy Markdown
Contributor

@AlexBuzea AlexBuzea Mar 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we align the frontend type for this field to match backend YesOrNo values ("Yes" / "No"), so payload and types stay in sync? We could use separate converters for different enum families (YesOrNo vs VerticalYesNo) to avoid mixing formats across steps

* fromYesNoEnum('NO') // returns 'no'
* fromYesNoEnum(null) // returns undefined
*/
export function fromYesNoEnum(value: YesNoValue | string | undefined): 'yes' | 'no' | undefined {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fromYesNoEnum currently accepts many casings, which is useful, but can we keep to... output canonical ("Yes" / "No") so writes are consistent?

}

export interface HouseholdCircumstances {
shareIncomeExpenseDetails?: YesNoValue;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These HouseHoldCirumstances fields should match the backend entity/domain and match the "Yes"/"No" values. I've changed this on my PR already here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved now

@AlexBuzea
Copy link
Copy Markdown
Contributor

Few comments left to address, also would be good to have the details of all the changes introduced in the PR description along with screenshots of all screens introduced

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants