Absorb the README's deep-dive content ahead of the README slim-down
The project README is being reduced to a landing page; every fact it
held that the wiki lacked is merged here first (615 lines across 33
pages): the full email-threading & reply-flow design onto Tickets,
directory layout + module-page pattern + file-locations reference onto
Architecture, per-endpoint tables onto API Reference, MFA login flow +
LDAP subsection + injection/audit notes onto Security, the icon library
and editor internals onto Network Mapper, Branding + landing-page and
help/search internals + debug-tool depth onto System, planned objects
onto CMDB, custody/locations/warranty onto Assets, and more.
Also corrects stale claims found during the audit: the Knowledge
audience table still said customer-visible articles had no reader
(the portal Knowledge section shipped), a pre-#903 Portal-Privacy
ambiguity row, the Workflows trigger-wiring section (catalogue spans
every module now), the superseded System module-access bullet, the
Multi-Tenancy users page marked "Planned" for a shipped feature,
and the locale count (21 languages incl. Ukrainian, not 20).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Portal wiki: bring the four pages up to the redesigned portal
The pages described the pre-redesign portal: a nav with New Ticket and
Request Something in it, a page-per-ticket, an inline recording panel, and a
guide called "Using the portal".
Now documented: the four-destination nav and why raising a ticket is not in
it, the dashboard's four bands including popular articles, the compose screen,
the two-pane My Tickets, ticket.php as a redirect, the recording modal, and
Help's nine sections.
Developer guide gains the rule the popular-articles work produced — a
visibility rule gets written once (portal_reader.php), with the two knowledge
traps demoted to consequences of it — plus ORDER BY allow-listing and the
three layout traps: someone else's stylesheet may own your prefix, full height
is a flex chain not arithmetic, and specificity beats intent.
Self-service: comprehensive, up-to-date wiki with file tables
Self-Service-Portal.md had drifted badly — no mention of the palette or
dark mode, the requester's company, replies, attachments both ways, the
Help Centre, the request catalogue, privacy or reopen-on-reply. Rewritten
as the section hub, keeping the screen-recording and SSO detail that was
still accurate and restoring the help.php and avatar-menu sections.
New pages:
- Portal-Request-Catalogue — offering forms to customers, what happens to
a submission, the version/visibility rules, a worked example, and the
limitations (no per-company catalogue, no uploads, no approvals)
- Self-Service-Developer-Guide — the rules and traps, every one of which
actually bit: the requester/analyst id-space split, server-derived
scope, knowledge's INVERTED tenant rule, published vs archived,
not-found over forbidden, hiding-a-link-is-not-enforcement, and the
fail-closed-on-identity / fail-open-on-visibility asymmetry. Plus the
nowdoc trap that killed a page's JS for two releases, and why rendered
markup is not proof the JS ran.
Every page now carries a colour-keyed table of the PHP/JS files involved
and what each does, per the pattern set in Multi-Tenancy-Developer-Guide
§1a. The tables were built by enumerating the actual repo, not from
memory — all 21 api/self-service endpoints, the 10 pages, the shared
chrome, and the shared logic outside the portal folder.
Verified: every wiki link in these five pages resolves, and every repo
file named in them exists on disk.
Cross-linked from Forms and Knowledge (the two modules whose content the
portal now surfaces) and added to the sidebar.
Portal Help Centre: new page
Covers publishing articles (the Help Centre starts empty by design, since
every article defaults to analysts-only), the three visibility levels and
what is never shown, ticket deflection, and a worked example on a
multi-company system.