Repository navigation
ct adopt grants tells you to adopt CT's -1 "alle" sentinel as if it were a resource id #115
Description
What happens
A grant scoped to "alle" comes back from ChurchTools with dataId: -1. ct adopt grants treats that like any other unmanaged scope id and emits an adoption hint for it:
ct.groupRole({
key: "…",
group: "…",
role: "Leiter",
grants: [
// NOTE: "churchdb:view alldata" scopes by "cdb_bereich" (department). -1 is not managed, so
// it stays a host-specific number(s) — run `ct adopt department -1` and re-adopt to make it portable.
{ right: "churchdb:view alldata", scope: [-1] },
// NOTE: "churchdb:view station" scopes by "cdb_station" (campus). -1 is not managed, so
// it stays a host-specific number(s) — run `ct adopt campus -1` and re-adopt to make it portable.
{ right: "churchdb:view station", scope: [-1] },
// NOTE: "churchdb:security level person" scopes by "cc_securitylevel" (security-level). -1 is not managed, so
// it stays a host-specific number(s) — run `ct adopt security-level -1` and re-adopt to make it portable.
{ right: "churchdb:security level person", scope: [-1] },
],
});ct adopt department -1 cannot work — there is no such resource. And the premise of the note is wrong twice over: -1 is not host-specific, and it is not a number that needs portablizing. It means "every Bereich" / "every Standort" / "every security level" on whatever host reads it, which is exactly as portable as a typed ref.
Why it costs more than it looks
In a real adoption run this fires on most of the interesting grants — the ones that scope broadly — so the emitted block is three-quarters advice that has to be recognised as wrong before it can be deleted. Someone who trusts it goes looking for a resource that does not exist; someone who does not trust it now has to decide, per NOTE, whether this one is real.
Suggestion
Special-case dataId === -1 in the note-emitting path: no hint, and either no comment at all or a one-liner saying what it is, e.g.
// scope -1 is ChurchTools' "alle" sentinel — every Bereich; host-independent.
{ right: "churchdb:view alldata", scope: [-1] },The plan/apply side already handles -1 correctly; this is only about what adopt grants prints.
ct-cli 1.7.0.
Activity
2000game commentedon Aug 14, 2026
Same root cause, worse consequence, on a different dimension — worth folding into whatever fixes this.
For
cdb_gruppe(group-scoped rights),-1is not merely annotated with a bad hint; the grant is dropped from the emitted block entirely:and
--groupbulk mode then refuses the whole domain:So a 116-grant role instance is undeclarable, and the tool's own advice to
ct adopt group -1cannot be followed. The four grants arechurchgroup:view group/edit group/ etc. scoped to "alle Gruppen" — a perfectly ordinary thing for an implementation-admin role to hold.The consequence is also sharper than a misleading comment:
adopt grantsexplicitly warns that anything left as a comment will be revoked if the block is applied. So the failure mode for someone who does not read carefully is not "wasted time", it is "four live grants silently revoked on the next apply".Recognising
dataId === -1as CT's "alle" sentinel across every dimension —cdb_bereich,cdb_station,cc_securitylevel,cdb_gruppentyp,cdb_gruppe— fixes both halves at once: no bogus hint, and the grant stays in the block.Merge pull request #129 from eqrm/fix/milestone-2-adoption-portability