test(e2e): un-fixme form-validation + auth-ui to verify AC7 on staging (PMS-519) #364

Merged

nrupard merged 5 commits from test/PMS-519-unfixme-form-validation into main 2026-06-25 22:58:58 +02:00

Conversation 0 Commits 5 Files changed 2 +82 -41

nrupard commented 2026-06-25 21:59:55 +02:00

Owner

Copy link

What

PMS-519: un-fixme the AC7 form-validation spec (and the auth-ui login canary it shares a login with), so the e2e run against staging empirically verifies the two preconditions.

• form-validation.spec.ts: test.describe.fixme -> test.describe.
• auth.spec.ts: the login + logout round-trip test.fixme -> test.

Why both

The form-validation spec does its own loginViaSpa and runs after the setup project - the exact condition PMS-148 quarantined auth-ui for ("login stalls when run after setup"). PMS-148 is now marked Done, but auth.spec.ts was never re-activated, so the login is not actually proven green in CI. Re-activating both together is the real test of whether PMS-148's fix works.

This is the verification step (read the e2e result)

The e2e workflow runs both against staging:

• Both green -> PMS-148's login fix is real, the staging SPA serves the FormGuard build, and AC7 holds. Flip AC7 on PMS-518 + PMS-515 and close PMS-519 / confirm PMS-148.
• Login stalls -> PMS-148 has regressed (or was closed prematurely). Re-fixme and re-open PMS-148.
• Forms show the old single-error / no-validation behaviour -> the staging SPA has not redeployed the FormGuard build yet (check the [setup] spaBundles diagnostic). Re-fixme form-validation and wait for the redeploy.

Verified locally: npx playwright test --list shows both the auth-ui and form-ui tests as runnable (no longer skipped).

Do not merge until the e2e run is green - this PR exists to surface that result.

## What PMS-519: un-fixme the AC7 `form-validation` spec (and the `auth-ui` login canary it shares a login with), so the e2e run against staging empirically verifies the two preconditions. - `form-validation.spec.ts`: `test.describe.fixme` -> `test.describe`. - `auth.spec.ts`: the `login + logout round-trip` `test.fixme` -> `test`. ## Why both The form-validation spec does its own `loginViaSpa` and runs **after** the `setup` project - the exact condition PMS-148 quarantined `auth-ui` for ("login stalls when run after setup"). PMS-148 is now marked **Done**, but `auth.spec.ts` was never re-activated, so the login is not actually proven green in CI. Re-activating both together is the real test of whether PMS-148's fix works. ## This is the verification step (read the e2e result) The e2e workflow runs both against staging: - **Both green** -> PMS-148's login fix is real, the staging SPA serves the FormGuard build, and AC7 holds. Flip AC7 on PMS-518 + PMS-515 and close PMS-519 / confirm PMS-148. - **Login stalls** -> PMS-148 has regressed (or was closed prematurely). Re-`fixme` and re-open PMS-148. - **Forms show the old single-error / no-validation behaviour** -> the staging SPA has not redeployed the FormGuard build yet (check the `[setup] spaBundles` diagnostic). Re-`fixme` form-validation and wait for the redeploy. Verified locally: `npx playwright test --list` shows both the `auth-ui` and `form-ui` tests as runnable (no longer skipped). > Do not merge until the e2e run is green - this PR exists to surface that result.

nrupard added 1 commit 2026-06-25 21:59:55 +02:00

test(e2e): un-fixme form-validation + auth-ui login to verify on staging (PMS-519) ... 44d7796445

PMS-148 (the post-`setup` browser-login stall) is marked Done, and all the PMS-518 FormGuard work is merged to mokosh-apps main, so the two preconditions for the AC7 form-validation spec are believed met. Un-fixme both:

- form-validation.spec.ts: test.describe.fixme -> test.describe (PMS-519).
- auth.spec.ts: the login + logout round-trip test.fixme -> test. It is the login canary that PMS-148 was about; the form-validation spec shares the same loginViaSpa and runs after `setup` (the exact PMS-148 condition), so re-activating it together confirms the login is actually green.

This is the verify-on-CI step: the e2e workflow runs both against staging. If the login stalls, PMS-148 has regressed (re-fixme + re-open). If the forms show the old single-error / no-validation behaviour, the staging SPA has not redeployed the FormGuard build yet (check the `[setup] spaBundles` diagnostic). Both green flips AC7 to met on PMS-518 + PMS-515 and closes PMS-519.

Verified locally: `npx playwright test --list` now shows both the auth-ui and form-ui tests as runnable.

#PMS-519

nrupard referenced this pull request from a commit 2026-06-25 22:15:47 +02:00

fix(e2e): handle the OIDC consent screen in loginViaSpa (PMS-521)

nrupard referenced this pull request 2026-06-25 22:16:03 +02:00

fix(e2e): handle the OIDC consent screen in loginViaSpa (PMS-521) #365

nrupard added 2 commits 2026-06-25 22:18:54 +02:00

fix(e2e): handle the OIDC consent screen in loginViaSpa (PMS-521) ... 25c1ea390d

The staging OP now routes the post-2FA authorize through /oauth2/consent because the SPA requests the `profile` scope and the E2E account has not granted it. loginViaSpa had no step for the consent screen, so authorize looped (authorize -> consent -> app shell -> authorize -> consent), the token exchange never fired, and `setup` captured no bearer - failing setup and, with it, the entire suite (auth-ui, form-ui, and every api spec depend on setup's login/bearer).

Diagnosed from e2e run #2522 (PR #364): setup's diagnostic showed postLoginUrl=/oauth2/consent?missing=profile, scope=openid+email+offline_access+profile, and "OIDC token exchange never fired".

Fix: in loginViaSpa's post-login navigation wait, click Allow whenever the page lands on /oauth2/consent (the grant POSTs to bunyip-api and persists, so later authorize calls skip consent), and keep treating any /login* path as still-in-flow. Mirrors bunyip's e2e driveConsent and bunyip-web/src/handlers/consent.rs (the Allow control is `button[name="action"][value="allow"]`, with a text/role fallback). Best-effort click + a 30s overall deadline with a clear timeout message naming the consent markup if the selector ever moves.

This un-breaks `setup` (and the always-on api specs); the still-quarantined auth-ui + form-ui specs (PMS-519) can be re-verified once this lands.

#PMS-521

Merge branch 'fix/PMS-521-loginviaspa-consent' into test/PMS-519-unfixme-form-validation 356a9cea3f

nrupard referenced this pull request from a commit 2026-06-25 22:34:35 +02:00

test(e2e): instrument form-validation + isolate from auth-ui (PMS-519)

nrupard added 1 commit 2026-06-25 22:34:35 +02:00

test(e2e): instrument form-validation + isolate from auth-ui (PMS-519) ... b222ff4660

The first un-fixme run (#364 / run 2528) cleared the big blocker - the PMS-521 consent fix means `setup` and the browser specs now log in past the OP consent screen, and all 21 api specs plus the auth-ui LOGIN went green. Two reds remained, both unrelated to the form-validation behaviour under test: the auth-ui LOGOUT lands on the app root `/` instead of `/login` (a logout-redirect question, PMS-148), and the form-ui spec could not find the `Create Ticket` button on `/tickets/new`. The form-ui retry then stalled at `/login` - the 5/min/email login cap, tripped because setup + auth-ui + form-ui (with retries) spent more than five logins in the window.

This isolates and instruments form-ui so the next run is conclusive:

- form-validation.spec.ts now wraps its body in `attachPageDiagnostics` and rethrows with the URL trail + request list folded into the error. fj cannot download the Playwright trace artifact, so without this the failure mode (page bounced to /login after the hard `goto` rebooted the WASM app vs. an older SPA build without FormGuard vs. a button-name mismatch) is invisible in CI logs. A `waitForLoadState('domcontentloaded')` after each hard `goto` lets the WASM app re-auth from the persisted OP cookies before the assertions run.

- auth.spec.ts is re-`fixme`'d. Its login stall (the original PMS-148 symptom) is gone; the leftover logout-redirect red is a separate concern tracked under PMS-148. Dropping it returns the suite to two logins (setup + form-ui), comfortably under the rate-limit cap, so the form-ui result is no longer confounded by a rate-limited retry.

#PMS-519

nrupard added 1 commit 2026-06-25 22:42:27 +02:00

test(e2e): drive form-validation via in-app nav, not hard goto (PMS-519) ... 3d0320edf4

Run 2531's instrumented failure pinned the root cause: `page.goto('/tickets/new')` does a full document load that reboots the WASM SPA and wipes the in-memory bearer. The app then silently re-auths from the persisted OP cookies, and its `/auth/callback` redirects to the DEFAULT route `/dashboard`, discarding the deep-linked `/tickets/new`. The URL trail ended on `/dashboard`, so the `Create Ticket` button never rendered and the click timed out.

Switch both form navigations to in-app router `Link` clicks (sidebar `a[href="/tickets"]` -> list-page `a[href="/tickets/new"]`, and the same for contacts). Clicking a Dioxus `Link` is client-side routing: the single WASM instance stays alive, the bearer survives, and the requested create form actually renders. `.first()` guards the list page rendering the New-X affordance twice (header action + empty-state CTA), and an explicit `waitFor` on each submit button absorbs the client-route transition before the click.

The diagnostic wrapper and the `auth.spec.ts` re-`fixme` from the previous commit stay: form-ui runs alone (two logins, under the rate-limit cap) and folds the URL trail into any thrown error.

The deep-link-drops-route behaviour the trail exposed (a cold load of `/tickets/new` while holding a valid OP session lands on `/dashboard`) is a real SPA bug, but separate from this AC7 spec; tracked apart.

#PMS-519

nrupard added 1 commit 2026-06-25 22:49:22 +02:00

test(e2e): target the visible desktop sidebar, not the hidden drawer (PMS-519) ... bd21d6d442

Run 2534 reached /dashboard and resolved `a[href="/tickets"]` but the click timed out - "element is not visible" x116. The layout (mokosh-apps components/layout.rs) renders the sidebar TWICE: a mobile drawer `aside` (`lg:hidden`, so `display:none` at the Desktop Chrome 1280px viewport) that is DOM-first, and the desktop sidebar `aside` (`hidden lg:flex`, visible at lg+). `.first()` grabbed the hidden drawer.

Scope all four in-app nav locators with `:visible` so they select the desktop sidebar / visible list-page link and skip the display:none drawer. `.first()` still guards the list page rendering the New-X affordance twice (header + empty-state).

#PMS-519

nrupard merged commit 7272270f12 into main 2026-06-25 22:58:58 +02:00

nrupard deleted branch test/PMS-519-unfixme-form-validation 2026-06-25 22:58:58 +02:00

nrupard referenced this pull request from a commit 2026-06-25 22:58:58 +02:00

Merge pull request 'test(e2e): un-fixme form-validation + auth-ui to verify AC7 on staging (PMS-519)' (#364) from test/PMS-519-unfixme-form-validation into main

vas2000-work referenced this pull request from a commit 2026-07-01 07:06:07 +02:00

fix(e2e): handle the OIDC consent screen in loginViaSpa (PMS-521)

vas2000-work referenced this pull request from a commit 2026-07-01 07:06:07 +02:00

test(e2e): instrument form-validation + isolate from auth-ui (PMS-519)

vas2000-work referenced this pull request from a commit 2026-07-01 07:06:07 +02:00

Merge pull request 'test(e2e): un-fixme form-validation + auth-ui to verify AC7 on staging (PMS-519)' (#364) from test/PMS-519-unfixme-form-validation into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

psa-systems/mokosh-server!364

No description provided.