First full e2e execution: 15 of 80 root-suite tests fail — including a non-admin Create CTA that answers 400

[rubenvdlinde]

What was measured

Run 31367057618 executed all 80 root-suite Playwright tests against the CI fixture for the first time. CI had been running a four-test subset (tests/e2e/ci/), so none of these had ever executed here.

65 passed, 15 failed. The 15 are concentrated in eight files, which #85 excludes from the gated suite by name — each testIgnore entry cites this run. This issue is the backlog those entries point at: every file below is a coverage claim we are currently declining to make.

One of them is a product finding, not a test problem

runtime-shell-canEdit.spec.ts:302 — ADR-023: fresh install is usable by non-admins › the empty-state Create CTA it is offered actually works

Error: the Create CTA the app itself offers must not be forbidden
Expected value: 400
Received array: [200, 201]

The app offers an ordinary non-admin user a "Create dashboard" CTA in the empty state, and the POST behind it answers 400. Two things are wrong independently of each other:

1. an affordance is rendered for an action the caller cannot perform;
2. the refusal is a 400, not the 403 personal_dashboards_disabled that REQ-ASET-003 describes. A 400 says "your request was malformed"; the request was fine and the feature was off. Anything downstream that distinguishes "bad input" from "not allowed" — a retry, an error message, a client-side guard — gets the wrong answer.

Seven of the eight tests in that file pass. It is excluded only because testIgnore is file-granular.

The other 14

File	Verdict	Notes
dashboard-sharing.spec.ts	0 of 4 pass	Needs a recipient account to be the share target (LAUNCHPAD_E2E_SHAREE, default recipient). The CI seed (tests/e2e/seed.sh) creates e2e-grantee and nothing else, so the recipient-side scenario has no second user to be. Fixable in the seed.
add-widget-modal.spec.ts	0 of 4 pass	All four time out at 47s; the modal never reaches the state the close-discipline assertions need.
active-dashboard-resolution.spec.ts	1 of 3 passes	Two time out at 24s.
allow-personal-dashboards-flag.spec.ts	0 of 2 pass	Sidebar Add-Dashboard button assertions, 14.6s.
image-widget.spec.ts	2 of 3 pass	REQ-IMG-003 click-through: the cell resolves, then Playwright reports "element is outside of the viewport" through 23 click retries and the popup wait times out. Reads like a scroll-container problem, not a product one.
label-widget.spec.ts	2 of 3 pass	"right-click Edit opens the content editor pre-filled, and edits round-trip".

image-widget (8 annotations) and label-widget (3, net of overlap with spec-coverage) are the whole of the honest gate-19 increase in #85: 258 → 269 before new tests were added. Fixing those two tests is worth exactly 11 scenarios of real coverage.

Not on this list, deliberately

• api-direct/** — asserts raw /api responses, not rendered UI; Newman owns that contract. group-shared-dashboards.spec.ts additionally needs member / nonmember / group e2e-test-group, which CI has not got.
• docs-screenshots.spec.ts — a capture job, not a regression suite. Moved to playwright.docs.config.ts.
• groupfolder-storage-backend (35 gate-19 findings) — not e2e-testable at all while DashboardService::readDashboardContent() / writeDashboardContent() / deleteDashboardContent() have zero callers anywhere in lib/ or src/ (verified on 895bfcea), so no HTTP or UI path reaches the backend. CI also does not install groupfolders. See groupfolder-storage-backend is unreachable: read/write/delete all have zero callers, while migrate --prune-source already NULLs the DB column #80 — and note this is not dead code: migrate-to-groupfolder --prune-source writes to that backend and NULLs the DB column.

How to clear an entry

Get the file green against a CI-like instance, then delete its glob from testIgnore in playwright.config.ts and from testMatch in playwright.excluded.config.ts — those two lists are complements. Confirm the test names appear with a ✓ in the run list; a green job is not the check.

[rubenvdlinde]

Addendum: a second class of finding from the same measurement

The table in the issue body lists specs that fail. This is about three that passed, and should not have counted.

Once CI actually ran the suite, use.storageState (the admin session global-setup.ts harvests) turned out to be inherited by contexts created inside a test — including request.newContext(...) built for a different user. Nextcloud prefers the session cookie over an Authorization: Basic header, so:

• ci/manifest-grants.spec.ts — the "recipient" was admin. Caught, because the recipient could see dashboards nobody had granted them.
• ci/public-share-lifecycle.spec.ts non-owner test — the "grantee" was admin. Caught, because a 403 assertion got a 201 whose body read "createdBy":"admin".
• ci/public-share.spec.ts — the "anonymous visitor" was a logged-in administrator, and the test stayed green, because token gating does not depend on who the caller is. Every assertion in it survived the premise in its name being false.

The first two were caught only because they assert absence of permission, which is the one shape that breaks when the caller is silently upgraded. Any test whose assertions hold for an admin as well as for its nominal user would pass exactly as it does today with the identity wrong. That is worth a sweep, not just three fixes: grep for request.newContext( and browser.newContext( in tests/e2e/ and check each one either wants the admin session or explicitly says storageState: undefined.

Fixed in #85 for the three above, with the reason written next to each so the next person does not delete the line as boilerplate.

Related, same run: spec-coverage.spec.ts reached the admin API through page.request, which authenticates by session and does not attach Nextcloud's requesttoken. GET /api/admin/settings answered NOT OK and the code read that as "personal dashboards are enabled" — a settings check that returned the permissive answer precisely when it could not see the setting.