An explicit editors: ['user:rbac-editor'] grant does not make an Application visible to that editor in /api/applications

[rubenvdlinde]

Surfaced by #169, which made automations-rbac.spec.ts build its own fixture instead of assuming one that only ever existed on a developer's container. With the fixture now genuinely created in CI, the two REQ-AUTD-008 tests run for the first time — and stop one layer deeper.

Measured

Run 31402629015, job 93501746124. beforeAll succeeds: the app is created through POST /api/applications/wizard with two versions, and grantAppRoles() then writes

permissions: { owners: ['user:admin', 'user:rbac-owner'], editors: ['user:rbac-editor'], viewers: [] }

grantAppRoles() throws on a non-OK response, so the grant landed. Then, logged in as rbac-editor:

the rbac-automations-app fixture application must be listed for this user;
refused requests so far: ["GET 403 http://localhost:8080/apps/openbuild/api/setup/status",
                          "GET 404 http://localhost:8080/index.php/apps/hermiq/api/chat/health"]

.automations-page mounts, so the SPA is fine. AutomationsPage.fetchApplications() reads /apps/openbuild/api/applications — the role-filtered list — and that endpoint is not in the refusal list, i.e. it answered 200 with a list that does not contain the app.

So this is not an auth refusal and not a routing problem. A user named explicitly in permissions.editors does not get the Application back from the endpoint whose whole job is to return the Applications they hold a role on.

Why this is not #76 again

#76 was the layer below: every openbuild schema declared {create, update, delete: ["admin"]} and no read, so OpenRegister's SQL gate discarded grants that had landed correctly. That was fixed with read: ["authenticated"] on all 15 schemas and verified 0 → 21. This one is different in two ways: the grant is a user: principal rather than group:, and the app is wizard-created rather than seeded — so the wizard's own permissions block is what grantAppRoles() merges into.

Worth checking in that order:

1. Does the wizard write a permissions shape that the merge preserves? (OR's saveObject() is PUT-semantic — grantAppRoles() re-PUTs the whole record and deletes @self, but if the wizard stores permissions somewhere else on the row the merge would be writing a field nothing reads.)
2. Does PermissionResolver::matchesCaller() treat a user: principal the same as group: on this path?
3. Does the list endpoint filter on the same block the grant writes?

Two collateral findings from the same failure message

Both come from the collectFailedResponses() reporter added in #169, which attaches every ≥400 response to the assertion instead of leaving them as unattributable console lines.

• GET 404 /index.php/apps/hermiq/api/chat/health — on every page. A probe for an optional ExApp that is installed on the dev container and absent in CI. Harmless here, but it is exactly the shape that makes local screening green and CI red for reasons nobody can name.
• GET 403 /apps/openbuild/api/setup/status for a non-admin. Group-based app grants do not make an Application visible to its editors/viewers #76's own follow-up notes recorded this: nc-vue's useSetupStatus used to read that 403 as "setup unfinished" and show every non-admin a first-time-setup wizard they cannot complete, instead of the app — fixed in fix(setup): a 403 from setup/status is an answer, not a failure nextcloud-vue#574, which openbuild picks up only via a published nc-vue bump. The page does mount here, so the fix appears to be in; the 403 itself is still worth removing rather than relying on a client-side workaround.

[rubenvdlinde]

Auto-closed by #177 — a note on what that does and does not establish

#177 carried Closes #171 in its description, and this repo's default branch is
development, so merging it closed this issue automatically. Recording the
reasoning so the close is not mistaken for a measurement it isn't.

What is established. The two automations-rbac.spec.ts scenarios whose failure
surfaced this issue now pass — ordinals 20 and 21, on two separate runs against
two different trees (31547464168 and 31572337414). #177 rebuilt the RBAC e2e
fixture (tests/e2e/support/appFixture.ts, appRoles.ts) alongside the write-path
change, so the symptom this issue was filed for is gone.

What was separately established, and matters more. The underlying claim here —
that a user named explicitly in permissions.editors does not get the Application
back from /api/applications — was refuted by direct measurement: OpenRegister
returns the rows and listMine returns the app for the editor and the owner after
the grant. The original evidence was a Playwright locator timing out, and a locator
timeout says nothing about the endpoint underneath it.

That refutation is the more durable half. This issue was a real test failure
attached to an incorrect diagnosis of its cause, and both the failure and the
diagnosis are now resolved, by different means.

⚠️ One caveat, so nobody over-reads a corroboration. The Newman collection on
PR #156 contains assertions that a viewer and an editor do see the app, and they
pass — which looks like independent confirmation. It is weak: there is evidence in
that same run (a CSRF check failed response, which Nextcloud only raises when a
session cookie is present) that the collection may be executing every request as
admin, in which case those assertions pass regardless of role. Details on #156.
Do not cite them as proof of this behaviour until the identity is pinned.

Closed correctly; just not for the reason the title asserts.