story/FCT2-22092- Unauthorised page by renjithabby · Pull Request #241 · CPS-Innovation/Case-Management-Register-a-Case

renjithabby · 2026-09-21T18:48:51Z

https://cpsgovuk.atlassian.net/browse/FCT2-22092

sonarqubecloud · 2026-09-22T16:18:53Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
No data about Coverage
0.4% Duplication on New Code

See analysis details on SonarQube Cloud

HasanCPS

LGTM!

* tracking of events using journey id (#234) * tracking of events using journey id * pr comments * Story/FCT2-22040 - Added a TelemetryLogger Service for ui (#233) * added a TelemetryLogger Service for ui * clean up and refactor and added unit tests * updated the test * Task/FCT2-19358 integrate e2e test suite into cicd (#237) * telemetry tracking properties (#240) * telemetry tracking properties * pr comment fixes * Story/FCT2-22041 : implemented ui tracking page views and few custom events (#239) * implemented ui tracking page views and few custom events * added journeyId and areaOrDivisionText for caseregistration request * fixed the pull request comments * minor refactor * update pipelines with development branch triggers * add src/tests directory to backend PR pipeline trigeer paths * update parameter empty string value option * story/FCT2-22092- Unauthorised page (#241) * handled 401 error on initial page load * added unit tests * fixed the pr comments * minor refactor * test(e2e): assert the Repealed tag on offence search results (#245) The tag itself shipped in #229; this covers it against the real /api/v1/offences response, where previously only the MSW integration suite asserted it. Expectations come from the search response rather than hardcoded codes: the offences are split into repealed (an "effective to" date is present) and active, and the rendered table is checked against that split, so the test holds as the reference data changes. It fails loudly if a search returns only one kind, rather than passing vacuously. Covers all three acceptance criteria - a tag for every offence with an "effective to" date, no tag for any without one, and the tag sitting in the Description column beneath the description text, carrying the GOV.UK warning styling that distinguishes it. Each was falsified before being kept: treating active offences as repealed fails the tag count (expected 19, received 1), looking for the tag in the Statute column fails on visibility, and expecting the description without the tag appended fails the cell text. * fix stage dependency --------- Co-authored-by: Rhys Bridges <bridgesrhys@gmail.com> Co-authored-by: Renjith Abby <renjithabby@gmail.com> Co-authored-by: kmshrajcps <KameshRaj.Rajendran@cps.gov.uk>

…page (#251) Covers FCT2-22092 (#241) against the deployed SPA and real gateway API, where previously only the MSW integration suite asserted it. Two scenarios, each keeping the Entra SSO cookies so the SPA still signs in and only the gateway API rejects the request: - Scenario 23 removes the Cms-Auth-Values cookie. - Scenario 24 keeps the cookie but replaces its value with an invalid one. Both load the home page and assert the units API returns 401, the user lands on /unauthorised with the "You cannot access this service" heading and the CMS Classic relaunch text, and the Register a case form is never shown. Falsified by running a copy with the valid cookie left intact: it fails the status check (expected 401, received 200).

* Task/fct2 22065 revise cicd for new branching strategy (#244) * tracking of events using journey id (#234) * tracking of events using journey id * pr comments * Story/FCT2-22040 - Added a TelemetryLogger Service for ui (#233) * added a TelemetryLogger Service for ui * clean up and refactor and added unit tests * updated the test * Task/FCT2-19358 integrate e2e test suite into cicd (#237) * telemetry tracking properties (#240) * telemetry tracking properties * pr comment fixes * Story/FCT2-22041 : implemented ui tracking page views and few custom events (#239) * implemented ui tracking page views and few custom events * added journeyId and areaOrDivisionText for caseregistration request * fixed the pull request comments * minor refactor * update pipelines with development branch triggers * add src/tests directory to backend PR pipeline trigeer paths * update parameter empty string value option * story/FCT2-22092- Unauthorised page (#241) * handled 401 error on initial page load * added unit tests * fixed the pr comments * minor refactor * test(e2e): assert the Repealed tag on offence search results (#245) The tag itself shipped in #229; this covers it against the real /api/v1/offences response, where previously only the MSW integration suite asserted it. Expectations come from the search response rather than hardcoded codes: the offences are split into repealed (an "effective to" date is present) and active, and the rendered table is checked against that split, so the test holds as the reference data changes. It fails loudly if a search returns only one kind, rather than passing vacuously. Covers all three acceptance criteria - a tag for every offence with an "effective to" date, no tag for any without one, and the tag sitting in the Description column beneath the description text, carrying the GOV.UK warning styling that distinguishes it. Each was falsified before being kept: treating active offences as repealed fails the tag count (expected 19, received 1), looking for the tag in the Statute column fails on visibility, and expecting the description without the tag appended fails the cell text. * fix stage dependency --------- Co-authored-by: Rhys Bridges <bridgesrhys@gmail.com> Co-authored-by: Renjith Abby <renjithabby@gmail.com> Co-authored-by: kmshrajcps <KameshRaj.Rajendran@cps.gov.uk> * test(e2e): assert unauthenticated users are sent to the unauthorised page (#251) Covers FCT2-22092 (#241) against the deployed SPA and real gateway API, where previously only the MSW integration suite asserted it. Two scenarios, each keeping the Entra SSO cookies so the SPA still signs in and only the gateway API rejects the request: - Scenario 23 removes the Cms-Auth-Values cookie. - Scenario 24 keeps the cookie but replaces its value with an invalid one. Both load the home page and assert the units API returns 401, the user lands on /unauthorised with the "You cannot access this service" heading and the CMS Classic relaunch text, and the Register a case form is never shown. Falsified by running a copy with the valid cookie left intact: it fails the status check (expected 401, received 200). * fix(e2e): recover from URN collisions instead of timing out (#253) The police force, unit and year in a generated URN are fixed, so the 5-digit reference is the only thing keeping it unique - a space of 100,000 shared with every case already registered in the environment. When the reference is already taken the page stays on case-details showing "URN already exists", nothing handles it, and the test times out waiting for the next screen. Rather than pre-checking (which would mean obtaining a gateway token outside the browser), read the boolean the page itself acts on: GET /api/v1/urns/{urn}/exists, called on every submit once client-side validation passes. CaseDetailsPage.saveAndContinueWithFreeUrn submits, reads that response, and on a collision swaps in a new reference and submits again - up to 5 attempts before failing with the URN it tried. Reading the response rather than the rendered error matters: the error summary from the previous attempt stays on screen, so a screen-based check would keep reporting a collision that had already been resolved. refreshUniqueReference updates the URN in place so the summary and confirmation assertions downstream check the URN the case was actually registered under. enterAreasAndCaseDetails covers 13 journeys; longPathValidation and the recovery URN in shortPathDuplicateUrn submit case-details directly and now use the same helper. The two journeys that want a duplicate on purpose keep asserting it, via the new expectDuplicateUrn option and the existing submitAndExpectExistingUrnError. Verified with a throwaway spec that registered a case and then re-used its URN: the journey recovered and submitted under the new URN, while the same journey with the retry opted out reproduced the stranding. Full suite: 24 passed. * test(e2e): assert the Add action is the first offence results column (#252) The column move itself shipped in #229; this covers it against the real /api/v1/offences response, where previously only the MSW integration suite asserted the order. Scenario 21 drives a suspect journey to the offence search page and checks the rendered table: one ordered comparison over the header cells covers both halves of the acceptance criteria - Actions is first, and it comes before CJS code, Description, Statute name and section and Effective dates. Header order alone would still pass with the Add link moved to another cell, so it also asserts the link is in the first column and the CJS code is the column that follows it. Both assertions were falsified before being kept: expecting CJS code first fails on the header comparison, and looking for the Add link in the second cell fails with the element not found. * test(e2e): assert the case registration carries the journey id and area (#254) The CaseRegisteredEvent enrichment shipped in #234; this covers it against the deployed SPA and real gateway API. Scenario 25 completes a short-path registration while recording every POST /api/v1/telemetry, and asserts: - exactly one JourneyStarted event is sent, with a v4 UUID journeyId - every page view carries that same journeyId - the POST /api/v1/cases payload carries that same journeyId, so the backend CaseRegisteredEvent correlates with JourneyStarted - areaOrDivisionText is the area chosen on the areas page * test(e2e): assert journey start, step page views and cancellation tel… (#256) * test(e2e): assert journey start, step page views and cancellation telemetry The journey tracking shipped in #239; this covers it against the deployed SPA and real gateway API. Scenario 26 saves the Home screen, moves through Case Areas to Case Details, then cancels the registration, recording every POST /api/v1/telemetry. It asserts: - exactly one JourneyStarted event is sent, with a v4 UUID journeyId, and it is not sent again later in the journey - the page views are exactly Home, Case Areas, Case Details and Cancel Case Registration Confirmation, each with its step name, path and the same journeyId - JourneyCancelled carries that journeyId and cancelledFrom /case-registration/case-details, and the backend accepts it even though the page leaves the SPA straight after The Home page view is only sent once the user leaves Home, because that is when the journeyId is created, so it is asserted as the first view. Request order is not asserted: trackEvent waits for a token before sending, so JourneyStarted and the first page view can arrive either way. * test(e2e): fail clearly on bad telemetry bodies and ignore page view arrival order * Subtask/FCT2-22142 add separate test flow for PRs from development to main (#258) --------- Co-authored-by: Lilach <Lilach.Davis@cps.gov.uk> Co-authored-by: Rhys Bridges <bridgesrhys@gmail.com> Co-authored-by: Renjith Abby <renjithabby@gmail.com> Co-authored-by: kmshrajcps <KameshRaj.Rajendran@cps.gov.uk>

renjithabby added 2 commits September 21, 2026 19:46

handled 401 error on initial page load

a24048d

added unit tests

74b3fc4