Turning the shared E2E Tests (Playwright) job on (#709) took procest from cancelled at the 45-minute cap after 65 of 122 tests to a completing suite. Most failures were stale test mechanics and are fixed in that PR. These eight are not test bugs — each is a gap in the app or in the CI fixture data, measured on a GitHub runner on 2026-08-04. They are test.fixme referencing this issue.
1-2. The in-app Settings page renders none of its configuration content
pages.spec.ts › Settings page › has schema configuration fields / › has case type management section
/index.php/apps/procest/settings renders only the section chrome — H4:Settings, H2:Settings. Measured: .settings-form count 0, no Case Type Management heading, and no scrollable container, so this is not lazy-mount: the type:"settings" page's section-admin slot (AdminRootView) never renders its body. The same components DO render on the Nextcloud admin page /settings/admin/procest, which is why spec-coverage/admin-settings.spec.ts passes.
The scenario is spec'd as the in-app settings page (admin-settings/spec.md#in-app-settings-page-renders-configuration-sections), so the tests were deliberately NOT retargeted at the admin URL — that would silently change what the scenario proves.
3. Admin "add case type" form never surfaces its Save control
admin-settings.spec.ts › clicking add case type opens creation form — times out even with test.slow() (180s). The admin page mounts fourteen OpenRegister-backed sections and was measured at ~50s to first paint under php -S.
4. Case-email settings expose no "Test connection" control
case-email-integration.spec.ts › settings expose a Test connection control — the button exists in EmailSettings.vue:116 but does not render on the admin page even after all sections are scrolled in. Its sibling test on the same page passes, so the page itself loads.
5. Case list renders neither a table nor cards
deelzaak-support.spec.ts › the case list renders and may show an "N deelzaken" badge. Measured on /cases: table=0, [role=table]=0, .viewTable=0, [class*=card]=0 — the list body renders an empty state, so the assertion is data-dependent on seeded cases.
6. /subsidies falls back to the generic case index
workflow-operations.spec.ts › subsidies index renders the subsidy intake list shell. /index.php/apps/procest/subsidies renders buttons [Settings, Cards, Table, Add Case, Actions] — a generic case list with Add Case, not a subsidy-specific create control. (/subsidieregelingen correctly renders Add Subsidieregeling and its test passes.)
7-8. Case detail never displays the zaaknummer
cases-crud.spec.ts › opening the row shows the case detail with its values and deelzaak-case-email.spec.ts › CaseDetail page renders the case. A case seeded with assigned identifier 2026-0001 renders a detail page containing CASE, the title, Assignee, Case type, Confidentiality — and the identifier is absent from the page text entirely. It DOES render in the case LIST, so the list-view assertions pass.
Each fixme carries the specific reason inline. Removing a fixme should follow from fixing the gap, not from relaxing the assertion.
Turning the shared
E2E Tests (Playwright)job on (#709) took procest from cancelled at the 45-minute cap after 65 of 122 tests to a completing suite. Most failures were stale test mechanics and are fixed in that PR. These eight are not test bugs — each is a gap in the app or in the CI fixture data, measured on a GitHub runner on 2026-08-04. They aretest.fixmereferencing this issue.1-2. The in-app Settings page renders none of its configuration content
pages.spec.ts › Settings page › has schema configuration fields/› has case type management section/index.php/apps/procest/settingsrenders only the section chrome —H4:Settings,H2:Settings. Measured:.settings-formcount 0, noCase Type Managementheading, and no scrollable container, so this is not lazy-mount: thetype:"settings"page'ssection-adminslot (AdminRootView) never renders its body. The same components DO render on the Nextcloud admin page/settings/admin/procest, which is whyspec-coverage/admin-settings.spec.tspasses.The scenario is spec'd as the in-app settings page (
admin-settings/spec.md#in-app-settings-page-renders-configuration-sections), so the tests were deliberately NOT retargeted at the admin URL — that would silently change what the scenario proves.3. Admin "add case type" form never surfaces its Save control
admin-settings.spec.ts › clicking add case type opens creation form— times out even withtest.slow()(180s). The admin page mounts fourteen OpenRegister-backed sections and was measured at ~50s to first paint underphp -S.4. Case-email settings expose no "Test connection" control
case-email-integration.spec.ts › settings expose a Test connection control— the button exists inEmailSettings.vue:116but does not render on the admin page even after all sections are scrolled in. Its sibling test on the same page passes, so the page itself loads.5. Case list renders neither a table nor cards
deelzaak-support.spec.ts › the case list renders and may show an "N deelzaken" badge. Measured on/cases:table=0,[role=table]=0,.viewTable=0,[class*=card]=0 — the list body renders an empty state, so the assertion is data-dependent on seeded cases.6. /subsidies falls back to the generic case index
workflow-operations.spec.ts › subsidies index renders the subsidy intake list shell./index.php/apps/procest/subsidiesrenders buttons[Settings, Cards, Table, Add Case, Actions]— a generic case list withAdd Case, not a subsidy-specific create control. (/subsidieregelingencorrectly rendersAdd Subsidieregelingand its test passes.)7-8. Case detail never displays the zaaknummer
cases-crud.spec.ts › opening the row shows the case detail with its valuesanddeelzaak-case-email.spec.ts › CaseDetail page renders the case. A case seeded with assigned identifier2026-0001renders a detail page containingCASE, the title,Assignee,Case type,Confidentiality— and the identifier is absent from the page text entirely. It DOES render in the case LIST, so the list-view assertions pass.Each fixme carries the specific reason inline. Removing a fixme should follow from fixing the gap, not from relaxing the assertion.