My earlier create-project flow wrote per-role verb grants (project_team: rwc,
…) at the PROJECT ROOT, which cascaded create/write across the whole project —
wrong. The project root is structurally locked to canonical peers
(rejectProjectRootMkdir), and the embedded defaults already grant each role its
per-FOLDER permissions ("None gets `c` here — create is granted only at the
specific peers below").
Project-create now writes role MEMBERSHIP only (document_controller /
project_team / observer) plus admins + created_by. Membership unions across the
cascade, so naming members at the project root makes the embedded per-peer
grants apply to them. No acl.permissions is seeded (the advanced field is still
an escape hatch). The dialog's "Guests" maps to the defaults' read-only
`observer` role (was a non-existent `guest` role that hooked no grants).
Per decision, MDL & RSK are now collaboratively editable: defaults grant
project_team rwc (create + edit, no delete) at mdl/ and rsk/ alongside
document_controller rwcd — the history: audit on both covers every change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Projects are always created at the deployment root, so the "Parent" dropdown
(and populateParentChoices) is gone — the client always POSTs parent:"/".
The Create-new-project dialog now collects members for the four project roles
— admins, document controllers, project team, guests — as simple email lists.
Server-side, each non-empty list becomes a roles:<name> entry plus a base
acl.permissions grant (document_controller→rwcd, project_team→rwc, guest→r);
an explicit advanced acl.permissions entry for the same key still wins.
The new project's .zddc now always records the creator: zf.CreatedBy = creator
email, and the creator is always included in admins: (deduped, first) so they
administer their own project from birth.
Tests: creator recorded + roles/permissions seeded; explicit permission
overrides the role default. Existing create tests still pass (creator-in-admins
is compatible with the explicit-admins-list case).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The /.profile/projects endpoint previously refused anyone without
hasAnyAdminScope. Now it runs the standard decider with ActionCreate
on the parent directory — super-admins still pass via the
IsActiveAdmin bypass branch, and anyone the root .zddc grants `c`
to (e.g. `*@example.com: c`) can self-service a project without
needing an existing admin grant.
Other changes in this commit:
- The new project's .zddc is seeded with the creator's email in
admins: when the request body doesn't supply one — they become
subtree admin of their own project at birth. .zddc edits in
deeper subfolders flow through their authority; strict-ancestor
rule still prevents them from editing /<project>/.zddc itself.
- AccessView gains can_create_project, computed by the same decider
call the endpoint uses — UI and server agree on visibility with
no daylight.
- Profile page splits the subtree-admin template from the create-
project template so the latter mounts on can_create_project,
independent of has_any_admin_scope. Non-admin grantees see the
form; admins keep seeing both.
- Lock-in tests cover the five interesting cases: cascade-granted
user succeeds and becomes subtree admin; stranger gets 404;
elevated super-admin auto-defaults admins; explicit admins list
wins over the default; duplicate-name 409.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
