When a user lacks permission, the app should (a) not let them do data entry it
will reject and (b) subtly say who can. General mechanism + the key gates.
Server — compute & expose "who can <verb> here":
- zddc.WhoCan(chain, verb) → Authority{Roles, People}: the acl.permissions
grantees holding the verb across the cascade (roles + their members) plus the
admins (who bypass). New whocan.go + whocan_test.go.
- AccessView gains path_who_can (profilehandler.go), populated only for verbs the
caller LACKS and only when they can read the path (mirrors .zddc readability),
so one cap.at() answers "can I?" and "if not, who?".
- writeForbiddenWho enriches the 403 body with who_can for the missing verb
(errors.go); authorizeAction uses it (fileapi.go) as the safety net for denials
that weren't pre-checked.
Shared — shared/cap.js:
- cap.whoCan(view, verb) + cap.denyHint(view, verb) → {text, title}, role-first
("Only the document controller can create here") with the people in the tooltip.
- handleForbidden appends the hint (from the 403 body, else the cached view), so
every tool that already routes 403s through it (form save, tables save, browse)
now explains who can — for free.
Key gates:
- Browse party-create (the reported bug): pre-check create authority on ssr/ and
the slot BEFORE opening the picker — if the user can do neither, show the hint
instead of the form; if only existing parties are usable, disable "+ New party"
with the who-can hint. The post-hoc 403 catch now names who can too.
- Tables +Add row disabled state shows the who-can hint.
Plus: subtle /_apps/{browse,archive,classifier}.html links in the landing footer.
Tests: Go WhoCan unit test (role/person split, admin bypass, dedupe); cap.spec.js
(denyHint role-first/people/fallback, whoCan, handleForbidden enrichment) — 5
green; Go handler+zddc+policy suites green. (Pre-existing stale browse toolbar
test browse.spec.js:274 unaffected.)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ZDDC
7c0b66590c