fix: [DHIS2-20898] re-enable and de-flake BreakingTheGlass Cypress test

[karolinelien]

What

Re-enables the BreakingTheGlass.feature scenario (User with search scope access tries to access an enrollment in a protected program), disabled via @skip since March 2024, by fixing the actual causes of the failure rather than leaving it disabled (https://dhis2.atlassian.net/browse/DHIS2-20898).

Why

1. The user switch drove the login form directly

The scenario switched users mid-test via the raw login form (cy.visit('/') + fill + submit) instead of the cy.session()/cy.loginByApi() pattern every other test in the suite uses. On the current standalone/prod Cypress build, an unauthenticated visit hard-redirects to the backend's own hosted login page on a different origin, which Cypress can't interact with without cy.origin():

CypressError: Timed out retrying after 25000ms: The command was expected to run against origin
`http://localhost:3000` but the application is at origin `https://<backend>`.

This looks like the same underlying regression as https://dhis2.atlassian.net/browse/DHIS2-20638 (also disabled, also driving the login form directly, its own code comment blames "login form is not working for v42 currently") — both likely trace back to the App Platform v12 upgrade (https://dhis2.atlassian.net/browse/DHIS2-18801). Unlike that ticket, this scenario doesn't need to test the login form UI itself, so switching the user-switch step to cy.loginByApi() sidesteps the problem entirely instead of needing a cy.origin()-based fix.

The switched-user session also gets a validate callback asserting /api/me is the expected user, mirroring the house pattern in cypress/support/tagUtils/login.js. Without it, a stale cached session — or a login that silently kept the previous user — surfaces as a confusing missing-widget failure several steps later instead of failing at the switch, which matters because "the second user is genuinely a different, less-privileged user" is the whole premise of the scenario.

2. The scenario leaked its tei into another spec's assertions

Re-enabling the scenario alone turned TrackerWorkingListsUser.feature red — 6 failures on Expected to find content: 'Filona'/'Johnny'/'Donald' within the element: <tr>, on every instance version, while master's shard 5 was green.

Cause: this scenario creates a tei enrolled in Child programme at Ngelehun and only cleared it on the way in (Given the tei created by this test is cleared from the database), so the tei outlived the run. That is the same working list TrackerWorkingListsUser asserts on by row position — a positional array of first names matched row-by-row — so one extra row shifted every pagination and ordering assertion. The clincher: "Show teis ordered ascendingly by first name" expected Donald, and the leaked tei's first name is Breaking, which sorts ahead of it.

Fixed by adding a tag-scoped After hook following the house pattern (@with-...-cleanup, as in WidgetProfile, TrackerBulkActions, EditEventPageForm), re-authenticating as the default user first because the scenario ends logged in as the search-scope-only one, which cannot delete the tei.

Verification

Local, before the session fix: 4/5 runs failed with the cross-origin error above. After: 7/8 clean passes, zero recurrences.

In CI, BreakingTheGlass.feature itself passes on all four targets — dev (2.44-SNAPSHOT), 2.41, 2.42 and 2.43 — confirming the tracker2 user still has the search-scope-but-not-capture-scope access the scenario depends on. The spec runs in shard 3; the shard-5 TrackerWorkingListsUser failures described above are what the After hook addresses.

Unrelated to this PR: the 2.42 instance is currently unhealthy — all five of its shards fail with cy.request() failed on: across specs this branch does not touch.

AI Assisted

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud