Skip to content

Access editor: lock-out warning fires for group MEMBERS too — prefixed vs bare gids #83

Description

@rubenvdlinde

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions