[Bug] frontend/tests/e2e/rbac.spec.ts:89 ("admin can access user management page without 403 or login redirect") is failing consistently in CI as of recent runs against main

[bg-playground]

Description

Summary

frontend/tests/e2e/rbac.spec.ts:89 ("admin can access user management page without 403 or login redirect") is failing consistently in CI as of recent runs against main. The test failed all three retries on PR #324, and the failure pattern (admin navigates to /admin/users, page renders text matching /403|forbidden|access denied/i) is reproducible.

Affected test

test('admin can access user management page without 403 or login redirect', async ({ page }) => {
  await page.goto('/admin/users');
  await page.waitForLoadState('networkidle');
  expect(page.url()).not.toMatch(/\/login/);
  const isForbidden = await page.getByText(/403|forbidden|access denied/i).isVisible().catch(() => false);
  expect(isForbidden).toBe(false);  // <-- fails here, isForbidden=true
});

Observed in

• PR Accept reporter-supplied requirement external IDs on external case result creation #324 — Playwright run on 1182626e... (3 retries, all failed identically)
• (manual verification needed for main HEAD ac5dd0b...)

Not observed in

• PR Add Projects API and enforce project_id existence for External Results sessions #322 (f56af4f) — all CI checks green at merge time

Suspected causes (any of)

1. Broad regex matching incidental text — the page may render benign text containing "access denied" (e.g. a tooltip, a sub-feature note) that was added recently. Tighten the assertion to look for a specific 403 hero element / heading / page-level error component.
2. Admin user seed regression — though admin login itself works (other admin-required tests pass), the admin seed may have lost the role permission specifically gating /admin/users. Check the test-data bootstrap.
3. API call during page render returns 403 and the page renders an error component. Inspect the trace zip for failing network calls.

Recommended fix

Tighten the assertion in rbac.spec.ts:97 to target a specific selector (data-testid or role) rather than a regex on visible text. The current regex catches anything containing 403, forbidden, or access denied — far too broad for a real RBAC assertion.

References

• Trace zip from PR Accept reporter-supplied requirement external IDs on external case result creation #324 retry Add comprehensive software testing framework with 6-phase methodology #1: test-results/rbac-RBAC-…-chromium-retry1/trace.zip
• Playwright workflow run: https://github.com/bg-playground/BGSTM/actions/runs/25577003222

Location

docs/phases/

Expected Behavior

Recommended fix

Tighten the assertion in rbac.spec.ts:97 to target a specific selector (data-testid or role) rather than a regex on visible text. The current regex catches anything containing 403, forbidden, or access denied — far too broad for a real RBAC assertion.

Actual Behavior

frontend/tests/e2e/rbac.spec.ts:89 ("admin can access user management page without 403 or login redirect") is failing consistently in CI as of recent runs against main. The test failed all three retries on PR #324, and the failure pattern (admin navigates to /admin/users, page renders text matching /403|forbidden|access denied/i) is reproducible.

Affected test

test('admin can access user management page without 403 or login redirect', async ({ page }) => {
  await page.goto('/admin/users');
  await page.waitForLoadState('networkidle');
  expect(page.url()).not.toMatch(/\/login/);
  const isForbidden = await page.getByText(/403|forbidden|access denied/i).isVisible().catch(() => false);
  expect(isForbidden).toBe(false);  // <-- fails here, isForbidden=true
});

### Additional Context

_No response_