Symptom
In the Schema Designer's Access editor, scoping read to a specific group always shows
Saving this read scope will make this schema's records invisible to you…
even when the caller is a member of the selected group. REQ-OBDSA-004's second scenario ("a member editor sees no warning for the same scope") cannot pass.
Cause — two shapes that never meet
SchemaDesigner.vue:
-
availableGroups builds the dropdown from the Application's permissions buckets and filters out only user: entries, so the values keep their group: prefix:
const groups = all.filter((p) => typeof p === 'string' && !p.startsWith('user:'))
→ ["group:rbac-editors", "group:rbac-viewers"]
-
authorLockedOut compares the selected values against getCurrentUserGroups(), which returns bare gids:
const userGroups = getCurrentUserGroups()
return !groups.some((g) => userGroups.includes(g))
Measured on a live instance:
| source |
value |
permissions.editors (stored) |
["group:rbac-editors"] |
currentUserGroups initial state (base64-decoded from the page) |
["rbac-editors"] |
"group:rbac-editors" !== "rbac-editors", so .some() is always false and authorLockedOut is always true whenever a group scope is chosen.
Note on the wider shape problem
useRole.js:94-95 documents that permission buckets carry user:<uid>, group:<gid> or a bare gid. So normalising in one place is the fix, not special-casing authorLockedOut — whatever lands should strip a group: prefix when present and cope with the bare form, and the same normalisation should feed the value that gets saved into the access rule (OpenRegister's read rules take bare gids).
Verification owed
This is the exact scenario in tests/e2e/schema-access-scopes-rbac.spec.ts (REQ-OBDSA-004). That suite is currently skipped on a separate blocker — the schema designer is unreachable for non-admins until ConductionNL/nextcloud-vue#574 is published and openbuild bumps to it. Both should be closed out together, with the member-sees-no-warning case as the assertion that proves this fix.
Found while re-measuring #76; not fixed there to keep that change to the OpenRegister read grant.
Symptom
In the Schema Designer's Access editor, scoping
readto a specific group always showseven when the caller is a member of the selected group. REQ-OBDSA-004's second scenario ("a member editor sees no warning for the same scope") cannot pass.
Cause — two shapes that never meet
SchemaDesigner.vue:availableGroupsbuilds the dropdown from the Application'spermissionsbuckets and filters out onlyuser:entries, so the values keep theirgroup:prefix:→
["group:rbac-editors", "group:rbac-viewers"]authorLockedOutcompares the selected values againstgetCurrentUserGroups(), which returns bare gids:Measured on a live instance:
permissions.editors(stored)["group:rbac-editors"]currentUserGroupsinitial state (base64-decoded from the page)["rbac-editors"]"group:rbac-editors" !== "rbac-editors", so.some()is always false andauthorLockedOutis always true whenever a group scope is chosen.Note on the wider shape problem
useRole.js:94-95documents that permission buckets carryuser:<uid>,group:<gid>or a bare gid. So normalising in one place is the fix, not special-casingauthorLockedOut— whatever lands should strip agroup:prefix when present and cope with the bare form, and the same normalisation should feed the value that gets saved into the access rule (OpenRegister's read rules take bare gids).Verification owed
This is the exact scenario in
tests/e2e/schema-access-scopes-rbac.spec.ts(REQ-OBDSA-004). That suite is currently skipped on a separate blocker — the schema designer is unreachable for non-admins until ConductionNL/nextcloud-vue#574 is published and openbuild bumps to it. Both should be closed out together, with the member-sees-no-warning case as the assertion that proves this fix.Found while re-measuring #76; not fixed there to keep that change to the OpenRegister read grant.