test(e2e): app-role grant helper + the finding that blocks role-scoped coverage - #77
Merged
Merged
Conversation
…d coverage
Groundwork for the role-scoped permission suites (versionRouting 9.2,
schema-access-scopes-rbac). Adds grantAppRoles(), which writes an Application's
`permissions` block through OpenRegister's object API — there is no openbuild
permissions endpoint — carrying the WHOLE record forward, because OR saves are
PUT-semantic and omitted properties are dropped rather than left alone.
It works, and is not enough. Measured on a live instance:
- the grant lands and reads back as {owners:[user:admin],
editors:[group:rbac-editors], viewers:[group:rbac-viewers]};
- rbac-viewer is in rbac-viewers and rbac-editor in rbac-editors per OCS,
and both groups exist;
- PermissionResolver::matchesCaller() classifies `group:` principals and
intersects them against the caller's groups, so the grammar is right;
- yet GET /api/applications returns 200 with an EMPTY list for BOTH users.
Something below openbuild's permission layer filters the object out, most
likely OpenRegister-level object visibility — a separate grant from the manifest
permissions block. Filed as #76.
Committed as groundwork rather than held back: it encodes the verified
permission shape and the PUT-semantics trap, so whoever picks up #76 starts from
measured facts instead of re-deriving them. The role-scoped scenarios stay
skipped until a member can actually see the app.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Groundwork for the role-scoped permission suites, plus the measured reason they remain blocked — see #76.
grantAppRoles()writes an Application'spermissionsblock through OpenRegister's object API (there is no openbuild permissions endpoint), carrying the whole record forward because OR saves are PUT-semantic and omitted properties are dropped.It works, and it is not enough. The grant lands and reads back correctly, group membership is right, and
PermissionResolver::matchesCaller()handlesgroup:principals — yetGET /api/applicationsreturns 200 with an empty list for both the editor and the viewer. Something below openbuild's permission layer filters the object out, most likely OpenRegister-level object visibility. Full evidence in #76 and inline in the file.Committed as groundwork rather than held back: it encodes the verified permission shape and the PUT-semantics trap, so whoever picks up #76 starts from measured facts. The role-scoped scenarios stay skipped until a member can actually see the app.