Repository navigation
feat(permissions): manage the person-status grant domain (ct.status) - #90
Merged
Merged
Conversation
CT's `status` permission domain grants a right to every person carrying that
person status — the only instance-wide lever available, since per-person
domains are permanently out of scope (engine/guard.ts). Until now it could
only be clicked in the admin UI, so eqrm's instance-wide grants lived entirely
outside the config.
- DomainType gains "status"; `ct.status({ key, personStatus | id, grants })`.
- New `person-status` ref kind resolving against `GET /statuses` (a flat
`[{id, name}]` catalog — live-verified on eqrm prod). Distinct from the GROUP
status dimension, which still has no catalog at all (#67) and stays numeric.
- The numeric-scope guard accepted only positive integers. It now accepts 0 (a
real dataId — campus "Mainz" is id 0 on eqrm prod) and -1 (CT's "all values of
this dimension" sentinel, e.g. every external system for
`churchcore:login to external system`). CT reads -1 back verbatim, so a
declared -1 diffs to a no-op instead of churning.
- `ct adopt grants status <id>` emits a paste-ready `ct.status` block.
Plan/apply needed no changes — both are domain-type agnostic and already
address `/permissions/<domainType>/<domainId>`.
Verified against eqrm prod: `ct adopt grants status 6 --env prod` round-trips
the live `churchcore:login to external system` grant (scopeField `oauth_client`,
dataId -1).
Claude-Session: https://claude.ai/code/session_01VDTyxvXYSAUSSZi8ceT6zs
5 tasks
…buch issue The `status` domain work is PR #90 / issue #91; #89 is the unrelated docs-publishing issue. Claude-Session: https://claude.ai/code/session_01KPxjSEkqMiU7WE3vg6C3am
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
1 participant
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.
Why
ChurchTools'
statuspermission domain grants a right to every person carrying that person status. It is the only instance-wide lever CT offers — per-person domains are permanently out of scope (src/engine/guard.ts) — but until now it could only be clicked in the admin UI, so eqrm's instance-wide grants lived entirely outside the config.Concretely:
churchcore:login to external system(authId 18) is what lets someone sign in to a connected OAuth client with their ChurchTools account. Equippers wants that for everyone who holds a login, which means grants on three person statuses. There was no way to declare them.What
DomainTypegains"status"; new DSL functionct.status({ key, personStatus | id, grants }).person-statusref kind resolving againstGET /statuses— a flat[{id, name}]catalog, live-verified on eqrm prod. This is a different dimension from GROUP status (groupStatusId), which still has no catalog at all (bug(refs): group-status sugar resolves against /group/memberstatus — the wrong dimension (member statuses, string ids); no REST group-status catalog exists #67) and stays numeric; both the code and the docs say so at every touch point.-1— CT's "all values of this dimension" sentinel (here: every OAuth client). CT reads it back verbatim, so a declared-1diffs to a no-op rather than churning.0— a real dataId on several dimensions; campus "Mainz" is id0on eqrm prod.ct adopt grants status <id>emits a paste-readyct.statusblock.planandapplyneeded no changes — both are domain-type agnostic and already address/permissions/<domainType>/<domainId>.Verification
0), the-1sentinel round-trip, an end-to-endstatus-domain plan that reconciles to a no-op, and thepersonStatuseval-time guards.ct adopt grants status 6 --env prodround-trips the live grant, confirmingscopeField: "oauth_client"anddataId: -1.ct planreportsNo permission changes. Desired grants match ChurchTools.for the three declared statuses.Follow-up
Consumers need a published version before they can use
ct.status—@eqrm/ct-cli1.3.2 fails withct.status is not a function. eqrm/ct-structure has a companion PR that depends on this release.https://claude.ai/code/session_01VDTyxvXYSAUSSZi8ceT6zs