Workflow

HomeWorkflow → Portal

Portal

Every program on Ironmark ships with a customer-facing portal — the surface a reader uses to browse the technical manual without an authoring seat. It reads the same source-of-record modules as the IETP viewer; separation is at the auth boundary, not the content boundary.

Portal programs list — a customer's landing view. Only the programs they have access to appear.
Portal landing — a customer sees only the programs they've been granted access to.
Portal program detail — TOC, applicability filter, download and redline actions on a customer-facing view of the manual.
Program detail on the portal — TOC, per-asset applicability filter, download + redline actions.

What portal users see

Auth separation

Portal readers hold the customer role on the same auth stack the authors use — the same enabled providers (local, LDAP, OIDC, CAC, WebAuthn) are available to them, and the separation is at the role + project-membership boundary, not a distinct portal IdP.

What this means in practice:

Redlines triage — portal-filed line-level markups landing in a queue for reviewer triage, with source-DM and portal-user provenance.
Redlines triage — where portal-filed markups land for the internal team. Each row keeps source-DM, portal user, and asset-filter context.

Feedback flow

Portal redlines and CRs flow into the same review queue the internal team uses. Reviewers see redline provenance (which portal user, which asset filter was active) alongside the markup. Redline resolution updates the underlying DM through the normal change-cycle path — no separate "portal-triggered" write path.

Portal is not a static-site export. The reader sees the current published state of the source modules, with applicability filtering applied at read time. Update the DM + issue → the portal reflects it on the next publish cycle.

Related

← Back to Workflow