Write a ChurchTools forum post about the person-status permission domain (and get the undocumented bits confirmed) #91

#90 added ct.status, which manages ChurchTools' person-status permission domain. Getting there meant working out several things by probing a live instance, because they are not in the API docs. That is worth sharing with the ChurchTools community — and, more importantly, worth getting confirmed by ChurchTools themselves, because we are now relying on behaviour we only inferred.

Why post at all

We depend on three undocumented things. If any is an implementation detail rather than a contract, ct apply could one day write something we did not intend:

1. dataId: -1 as an "all values of this dimension" sentinel. We write it, CT stores it verbatim, and it is expanded only in the derived /permissions/global view. We rely on the round trip being lossless — that is what keeps a declared -1 a no-op instead of churning on every plan. Is -1 a supported public contract?
2. GET /statuses returns a flat [{id, name, …}] catalog of person statuses. It is not in the docs we could find, while the same rows also appear nested under /person/masterdata. Which is the stable one to depend on?
3. GET/PUT/DELETE /permissions/status/<statusId> works exactly like /permissions/group_role/<id> and /permissions/group_type_role/<id>. Also: GET /permissions/masterdata?domainType=… returns all rows for a domain type and its validation error helpfully enumerates the full set (status, group_type_role, group_role, person, group_type, group). Are person, group_type and group real, writable domains too?

Worth sharing (the part other people will care about)

• A structural group grants rights through two independent layers, and CT's per-group "Manage permissions" UI only shows one of them. A group can look completely unpermissioned while its group_type_role grants are present and correct. This surprises everyone who hits it — see docs/permissions.md and eqrm/ct-structure docs/permissions-status.md.
• The legacy churchdb write path (POST /index.php?q=churchauth/ajax with domain_type=groupMemberstatus) writes the same store as the modern /api/permissions/group_role/<id>. Not a separate or legacy database, and no sync problem between them — a question that comes up repeatedly in the forum.
• The person-status domain as the instance-wide lever. Granting per person does not scale and is not something a structure-as-code tool should ever touch; granting per status is the supported way to say "everyone".
• Bereich vs. Standort: churchdb:view alldata (cdb_bereich) gates who you can see; churchdb:view station (cdb_station) only filters what would already be visible. Verified via POST /api/simulate. Documented in eqrm/ct-structure docs/bereiche-und-standorte.md.

Scope of this issue

• Draft the post (German — it is a German-language forum).
• Split it honestly: what we verified on a live instance (with dates and how), vs. what we are assuming. Do not present inferences as documented behaviour.
• Ask the three questions above explicitly, so the thread can produce answers rather than just applause.
• Have someone who is not Claude read it before posting — it describes a real instance's permission model, so check nothing instance-specific or personal leaks (person ids, names, internal group ids where they are not needed to make the point).
• Post it, link the thread back here, and fold any authoritative answer into docs/permissions.md.

Prior art to draw on: docs/permissions.md ("domainId semantics", "Numeric scope escape hatch"), src/permissions/README.md (how the offline right-name catalog was captured), and the live-verification notes in eqrm/ct-structure docs/permissions-status.md.