Landing page: new wiki pair for discussion #63
New pages (app commit f1673644):
- Landing-Page (user)
- Landing-Page-Developer-Guide
The dev guide leads with the constraint that shaped the whole design: the
decision happens before authentication and before anything renders, so
user_preferences cannot hold it on its own (analyst_id is NOT NULL) and
localStorage cannot hold it at all (PHP cannot see it). The cookie is a cache
of the preference, not the setting.
Also records, for whoever touches this next:
- the stored value is a KEY and never a path, with the attack tests that
prove it, because this drives a redirect on the most-visited URL
- an endpoint writing several rows without a transaction must finish
validating before it starts writing (save_branding blanked the header
and footer on a rejected request)
- when a server-side upload rule is tightened, grep for the client-side
restatements of it (the accept attribute and the help text both still
recommended SVG after the server stopped taking it)
Cross-linked from Self-Service-Portal, Home and the sidebar. Every named file
verified to exist; every link verified to resolve.
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: recording on reply, and the second write-it-once rule
Screen Recordings now covers both entry points (raise and reply), the shared
component behind them (screen-recorder.js + record-modal.php + $needsRecorder),
the two deliberately opposite unclaimed-recording behaviours (cancel discards,
send blocks), and ticket_recordings.email_id — which message a recording came
with, NULL meaning the opening one.
Developer guide gains 2e: the claim ownership guard as a second instance of the
2c argument, generalised to "if the two copies disagree, does anything break?
if one merely permits more, write it once". Later sections re-lettered.
Noted the analyst reading pane still ignores email_id — nothing hidden, but a
reply's video shows on the original message too.
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 privacy: new page explaining the three options with worked examples
A ticket carries correspondence that isn't the requester's — forwards to
suppliers, copied-in colleagues, and their replies. The new Tickets ->
Settings -> Privacy tab decides how much of that the self-service portal
shows, and the rule has edge cases (chat channels exempt, ambiguity
resolves to visible) that are hard to hold in your head, so this walks
through six worked examples.
Cross-linked from Self-Service-Portal, Tickets and the sidebar.
Document 2026-06-27 work: portal SSO, multi-tenant SSO, System tools, Trash
- Single-Sign-On: self-service portal SSO (portal-aware callback, user_sso_identities,
auto-claim), multi-company company-owned providers + email-domain routing, providers
Company column.
- Self-Service-Portal: SSO sign-in for requesters.
- System: Help, Topology, Orphaned tickets, Debug Tools restructure + D003/D004.
- Tickets: manual-ticket send-from mailbox, Trash with restore (+ drag/right-click/empty).
- API-Reference: new endpoints.
- Multi-Tenancy-Progress: per-company SSO done; admin visibility tools.
Refresh Help sections in Tickets + add Help section to Self-Service-Portal
Document analyst-side user CRUD + screen recordings
Initial wiki: home, 18 module pages, installation, architecture, security, API reference, browser extension, sidebar