Public-facing request portal #6
scottconverse
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Update 2026-04-23 — a minimal public portal shipped in v1.2.0.
The original post in this thread said "v1 is internal-only, a public submission portal is not in the current spec scope and would be Phase 3+ at earliest." That framing is now partially out of date.
What actually shipped in v1.2.0 (T5D, 2026-04-23): an install-time
PORTAL_MODEswitch with exactly three public surfaces when enabled. Nothing more.Private mode (default, unchanged from v1.1.0):
/auth/registerreturns 404UserRole.PUBLICis not assignablePublic mode (new, opt-in via
PORTAL_MODE=public)://register(self-service account creation forUserRole.PUBLIConly)/public/submit, posted toPOST /public/requestsGET /config/portal-modeso the frontend can branch its routing at bootPOST /public/requests— they continue to use the existing/requests/workflowDeliberately still out of scope (Scott-locked in T5D):
records_requests.created_bystays NOT NULL.The three bullets above are what "public portal" means in v1.2.0. Broader public functionality is Phase 3+ and remains unscheduled.
Operator considerations from the earlier thread remain live:
records_requeststable and follow the same lifecycleIf your city would prioritize any of the still-out-of-scope items over connector-framework Phase 3 work, please say so here.
Canonical narrative for what shipped: CHANGELOG T5D entry · UNIFIED-SPEC §8.9 · v1.2.0 release notes.
All reactions