ZDDC/browse
ZDDC 7c0b66590c feat(server,shared): tell denied users who can — subtly, before wasted effort
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>
2026-06-12 14:58:20 -05:00
..
css ZDDC: document-control tools + zddc-server 2026-06-11 13:32:31 -05:00
js feat(server,shared): tell denied users who can — subtly, before wasted effort 2026-06-12 14:58:20 -05:00
build.sh ZDDC: document-control tools + zddc-server 2026-06-11 13:32:31 -05:00
README.md ZDDC: document-control tools + zddc-server 2026-06-11 13:32:31 -05:00
template.html ZDDC: document-control tools + zddc-server 2026-06-11 13:32:31 -05:00

browse — directory listing tool

Generic file browser for any directory. Designed to work with ZDDC archives but useful for any folder. Single-file HTML, no install.

How it's used

Two modes, auto-detected at page load:

  1. Online (zddc-server backed). When this HTML is served by zddc-server at a folder URL — which it is by default for any directory under ZDDC_ROOT that doesn't have an index.html — the JS queries the same URL with Accept: application/json to load the directory's listing and renders it as a sortable, filterable table.

  2. Local (FileSystemAccessAPI). Click "Select Directory" in the header to pick any folder on your computer. Works in Chromium-based browsers (Chrome, Edge, Brave, etc.). No server required; the directory is read directly from disk.

What it does

  • Lists files and folders with name, size, type (extension), and modified date.
  • Click a folder to expand inline. Children load lazily on first expand.
  • Click a column header to sort by that column. Click again to reverse.
  • Type in the filter to narrow to entries whose name contains the substring.
  • Click any file to open it in a new tab — for server-backed pages, this routes through zddc-server's normal handler (so an .archive redirect, an apps cascade override, etc. all work as expected).

Design notes

  • No ZDDC-specific filtering. This tool is intentionally domain-agnostic. The companion archive tool layers ZDDC parsing (project / status / revision filters, tracking-number resolution) on top of the same listing API. Use archive when you want ZDDC semantics; use browse when you just want to see what's in a folder.
  • Default at directory URLs. zddc-server's directory.go serves the embedded browse.html bytes for any directory request with Accept: text/html and no index.html present. This means a user navigating to any folder under ZDDC_ROOT gets a usable browser without anyone having to drop a file into the archive.
  • Apps cascade override. Like every other ZDDC tool, the served browse.html can be overridden per-folder via a .zddc apps: entry. The default is the embedded copy from the binary; operators can pin a specific version or URL if they want.