CodamAIDocs
Topicdone

Templates shipped with a build

Templates that ship with a build get into the system the same way as any other: as a draft, submitted by a platform administrator. Shown with the hub's reports.

Variants
First startStart with an unchanged templateStart with a changed templateSYSTEM scope with approval stages

What this is about

Some templates belong to a build. They live in an application’s source code, are reviewed and tested with it, and should simply be there after the start. CRMS has no special path for this: no template folder it reads by itself, and no template that bypasses the chain.

The flow

Seeding at start
  1. 1
    Application→CRMS
    acts as a platform administrator: a fixed id as author, the administrator roles from CIAS, no tenant
  2. 2
    Application→CRMS
    creates the system edition if it does not exist yet, and the variant for each language
  3. 3
    Application→CRMS
    reads the published revision of the variant
  4. 4
    Application
    Is its source the same as the one from the build?
  5. 5
    Application
    the same → do nothing, no new revision
  6. 6
    Application→CRMS
    different, or nothing published yet → save the draft and submit it with a reason
  7. 7
    CRMS
    the approval chain of the scope SYSTEM decides, as for every template
    Result: without stages PUBLISHED at once, otherwise IN_REVIEW

Because the application only submits when there is a difference, a start with an unchanged build changes nothing in the chain. A changed template in a new build becomes exactly one new revision.

What a start does

When: the template does not exist yet

Edition and variants are created, and every variant gets its first revision.

Result: revision 1 per language, PUBLISHED without approval stages

When: the source in the build equals the published revision

The application submits nothing.

Result: no new entries

When: a new build brings a different source

Only the changed variant gets a new revision. The others stay as they are.

Result: new revision, the previous one becomes SUPERSEDED

When: the project has an approval chain for SYSTEM

The submitted revision waits in IN_REVIEW until people approve it. Until then the previous revision renders. As long as a revision is in review, another submit ends with 409 template-review-pending.

Result: approval as for every system template

The example: the hub’s reports

The hub renders its project documents with an embedded CRMS: the arc42 architecture documentation, the data classification and the operations runbook. The templates are part of the build under crms-templates/.

ReportKey DOCUMENT (PDF, HTML)Key WORD (DOCX)Languages
arc42arc42arc42-wordde (default), en
Data classificationprivacyprivacy-wordde (default), en
Operations runbookrunbookrunbook-wordde (default), en

Every report is two keys, because the output type decides the formats. The files are called <key>/<language>.xhtml.ftl for DOCUMENT and <key>-word/<language>.xml.ftl for WORD.

The chain names hub-backend as author and “Template shipped with the hub-backend build” as reason. The hub defines no approval stages for SYSTEM. So its templates are published right after they are submitted. How the hub then renders them is described in Example: the hub’s reports.

Pitfalls

Next

Search