Two things surfaced while building the User Directory that are worth a decision
rather than a mention in a handover.
3. server/smoketest.py has no login step, so auth_gate 401s every check after
/api/health. DEPLOYMENT.md presents it as the way to prove the stack works
end-to-end, including a docker compose exec invocation, so the documented
verification path reports failure on a healthy system -- the failure mode most
likely to be believed. Rated Medium for that reason. Predates the login
portal; confirmed unrelated to this branch by stashing it and re-running. The
Admin Console's in-browser smoke test is the working equivalent today.
4. users.js and wp-sidenav.js have never been executed -- no JS engine on the
machine they were written on. Logged as a verification gap, not a defect, with
what WAS checked (server tests, delimiter balance, handler resolution, id
targets) and what only a browser can settle (layout, transitions, focus trap).
Includes the five-step manual pass that closes it, and the hard-reload note,
since sw.js bumped to wp-suite-shell-v6 and a soft reload serves the old
shell.
Both entries follow the file's existing shape: what is wrong, what it costs, why
it is still open, what closing it takes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
User accounts lived in the Admin Console, which is admins-only. Project admins
need to create the accounts on their own jobs without an app admin on the phone,
so accounts move to a new User Directory page and a new role carries the right.
server/auth.py, server/app.py
New permissions role `project_super_user`, between admin and project_admin:
everything a project admin may do, plus user administration SCOPED to the
projects they hold the role on. Four limits make it safe to hand out, all
enforced server-side:
* Scope comes from projects, not the job title. It resolves per membership
(managed_project_ids), so an ordinary account can hold it on one job via
ProjectMember.role, and a super user demoted on one job administers
nobody there. No projects, no authority.
* Account-level changes (password, disable, rename, permissions, delete)
require EXCLUSIVE scope: refused when the target is also on a project the
caller does not administer, because those changes are global. The
directory renders such rows read-only with the reason.
* No admin or super-user targets, and neither role can be granted by a
super user -- that is the line that stops it becoming app-wide control.
* PUT .../projects rebuilds only the caller's own slice; memberships on
projects they do not administer are left untouched. A payload that simply
omits them must not cut someone off a job the caller cannot see.
Creating requires naming at least one of your own projects: an account with
none would be one the creator instantly cannot manage.
/api/auth/users is now scoped rather than admin-only, and carries a per-row
`manageable` verdict plus the reason. Non-managers get a contact card only --
a project user has no business reading colleagues' login history. New
/api/auth/user-scope tells the page what it may offer. Administrative
password resets are now audited; they were the one account change that left
no trace. Settings, feature flags and the auto-add rule stay admin-only.
While here: one definition of "is a user manager", derived from the managed
set. An account-role-only version disagreed with the scoped one and locked
per-project super users out of routes they were entitled to.
html/users.html, html/users.js
The directory: three renderings from one page -- admin (everything), super
user (controls per row, read-only where scope is shared), everyone else (a
read-only directory of the people on their own projects).
html/console.css, html/console-util.js
Extracted from admin.html/admin.js so both console pages share them. A
divergent jsq() is an XSS and a divergent role list offers permissions the
server refuses, so neither may exist twice.
html/wp-sidenav.{js,css}
Global nav drawer, role-gated, carrying ?project= across links. Mounted on
the field view (which had no way to anywhere) plus both console pages.
No migration: users.role is already String(20) and the new value fits.
Verified: 93 scope/gate tests, 29 live HTTP tests through the real dependency
stack, 33 static JS checks. Not verified in a browser -- no JS engine on this
machine -- so users.html and field.html want one manual load.
server/smoketest.py still fails with 401s. Pre-existing: it has no login code,
so auth_gate refuses it. Confirmed unchanged by stashing this work.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
It is a real hole and we are shipping without fixing it, so it needs to be written
down somewhere that outlives the conversation it came up in.
Discipline names are rendered into inline handlers in the WP creator escaped with
esc(), which maps ' to '. That is right for text and wrong here: the browser
decodes entities in an attribute before the JS parser sees it, so the entity
becomes a bare quote and closes the handler's string literal. Escaping for a
handler argument has to go backslash, then quote, then HTML — esc() only does the
last part. Same bug, same ordering, as the two fixed on 2026-08-05 (jsq() in
admin.js, escHandlerArg() in work-package-suite-app.js); this one predates that
work and sits in a file it did not touch.
Left open rather than fixed because the suite is internal, behind a login, with
named employee accounts and no anonymous input path — the likely cost is a
discipline named "Owner's Equipment" silently breaking its own pill, not an attack.
The entry records the conditions that change that judgement (exposure outside the
corporate network, accounts for subcontractors or clients, self-registration), so
the rating cannot go quietly stale if the deployment story changes. Neither CSP nor
the CSRF gate mitigates it, and both are noted so nobody re-derives that hopefully.
Also records the archived-project rough edge from the same day: the server refuses
writes with 409, but the two big apps still present Save and Issue buttons, so the
failure is safe but late. data-wp-archived is already on the document element for
whoever closes it.
Each entry says what closing it takes, and entries get deleted in the commit that
fixes them — otherwise this file becomes a museum instead of a queue.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
