PO-3412 Implementing exact offence code match

[ChrisGarratt122]

Jira link

See PO-3412

Change description

Problem

Entering an offence code that is valid itself but also has related sub-codes could show an incorrect “Offence not found” message in Manual Account Creation.

Example:

• User enters CD71039
• API returns CD71039, CD71039A, CD71039B, CD71039C
• UI shows “Offence not found” even though CD71039 is present in the response and the intended code to display

This created an inconsistent journey because the review screen could still appear to show the correct offence later in the flow.

Cause

The cause of this was the conditional logic on fines-mac-offence-code-hint.component.html set to display the retrieved offence code only when response.count === 1. This means when a code not only pulls itself down from the backend but also all sub-codes the response count is more than 1 and this condition defaults the page to show "No offence found".

In general multiple codes being returned in the response hasn't been accounted and these issues affected a few places:

That affected a few places:

• The shared offence-code listener only populated offence_id when response.count === 1
• The hint panel showed “Offence found” only when count === 1
• Some review components relied on refData[0], which only worked if the exact match happened to be the first returned item

So for multi-result responses containing a valid exact match, we could:

• show the wrong validation state
• leave offence_id unset
• display the correct offence later only by coincidence, depending on response ordering

Solution

The primary fix here is to change the condition that determines between displaying the offence code or error. Instead of checking for the number of responses, we should be looking for an exact match from all codes in a given response.

Fixes:

• find the returned offence whose code exactly matches the entered code
• treat that as the valid offence, even if other related codes are also returned
• populate offence_id from that exact match
• use the same exact-match logic in the hint and review displays

This keeps the behaviour consistent across:

• offence entry
• offence hint panel
• offence review heading
• fixed penalty review offence display

Considerations

• This is intentionally stricter than “any results returned”: if the API returns related codes but not the exact entered code, we still show the offence as not found.
• The review screens now no longer depend on response ordering.
• The exact-match helper was kept inside the shared offence-details service
• Targeted tests were added for the multi-result exact-match scenario and the focused spec run passed.

Testing done

Manual testing

Unit testing
The testing approach focused on the exact-match behaviour across the full offence-code journey: service tests were used to verify that when the API returns multiple related offences, the lookup only succeeds if one record exactly matches the user-entered code, including both the positive case (CD71039 returned alongside CD71039A/B/C) and the negative case where similar results are returned but no exact match exists; targeted component tests then confirmed that the same rule is reflected in the UI, so the offence hint panel and both review displays now show the correct offence title and “Offence found” state for exact matches, and continue to show “Offence not found” where no exact match is present, removing any dependency on response ordering.

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

[iamfrankiemoran]

There is also a P1 issue via codex /review:

• [P1] Reject ambiguous exact-code matches — /Users/iamfrankiemoran/Documents/GitHub/opal-frontend/src/app/flows/fines/fines-mac/fines-mac-offence-details/services/fines-mac-offence-details.service.ts:149-152
  When the lookup response contains the same CJS code more than once (for example, the existing offence ref-data mock already has GMMET001 against multiple business units), findExactOffenceMatch() will return the first row and initOffenceCodeListener()
  will now clear the validation error and persist that row's offence_id. That turns an ambiguous lookup into a seemingly valid selection, and the chosen offence_id is what later gets sent in the MAC account payload, so duplicated codes can be saved
  against the wrong offence record. This should only be treated as a match when the exact code is unique, or after disambiguating by business unit/date.

[iamfrankiemoran]

LGTM