domma-cms 0.92.1 → 0.94.0

package/admin/js/templates/docs/components-walkthrough.html

@@ -19,13 +19,14 @@
         We'll build one component end-to-end: a <strong>star rating</strong> widget you can drop onto any
         page with <code>[component name="star-rating" max="5" value="3" /]</code>. By the end you'll have
         used every section of a <code>.dmc</code> file, reactive state, an event listener, a custom event,
-        and the live preview. Follow along in a real <strong>New Component</strong> editor.
+        and the live preview. Follow along in a real <strong>New component</strong> editor.
       </p>
 
       <hr>
 
       <h2>Step 1 - Create the component</h2>
-      <p>Open <a href="#/components">Data → Components</a> → <strong>New Component</strong> and name it
+      <p>Open <a href="#/components">Data &gt; Components</a>, click <strong>New component</strong> in the banner
+        and name it
         <code>star-rating</code>. Remember: lowercase + hyphens, and the name is permanent because it
         becomes the element tag <code>&lt;dm-star-rating&gt;</code>. The four source tabs
         (<code>&lt;template&gt;</code>, <code>&lt;props&gt;</code>, <code>&lt;script&gt;</code>,
@@ -47,13 +48,13 @@
 
       <h2>Step 3 - Write the template</h2>
       <p>We render <code>max</code> stars and mark each as filled if its index is below the current rating.
-        Because <code>{{#each}}</code> needs a list, we'll build a <code>stars</code> array in state
+        Because <code>&#123;&#123;#each&#125;&#125;</code> needs a list, we'll build a <code>stars</code> array in state
         (next step) where each item knows whether it's <code>on</code>. For now, the markup:</p>
       <pre class="code-block"><code>&lt;template&gt;
-&lt;div class="dm-stars" role="img" aria-label="{{value}} of {{max}}"&gt;
-  {{#each stars}}
-    &lt;button class="star {{#if on}}on{{/if}}" data-action="rate" data-index="{{n}}"&gt;★&lt;/button&gt;
-  {{/each}}
+&lt;div class="dm-stars" role="img" aria-label="&#123;&#123;value&#125;&#125; of &#123;&#123;max&#125;&#125;"&gt;
+  &#123;&#123;#each stars&#125;&#125;
+    &lt;button class="star &#123;&#123;#if on&#125;&#125;on&#123;&#123;/if&#125;&#125;" data-action="rate" data-index="&#123;&#123;n&#125;&#125;"&gt;★&lt;/button&gt;
+  &#123;&#123;/each&#125;&#125;
 &lt;/div&gt;
 &lt;/template&gt;</code></pre>
       <p>Each star is a button carrying its 1-based position in <code>data-index</code>, so a single click
@@ -68,7 +69,6 @@
       <pre class="code-block"><code>&lt;script&gt;
 export default {
   data() { return { stars: [], value: 0 }; },
-
   methods: {
     // Build the star list for a given rating.
     render(value) {
@@ -86,7 +86,6 @@ export default {
       }));
     }
   },
-
   onMount() {
     this.render(this.props.value);
     this.el.shadowRoot.addEventListener('click', (e) =&gt; {
@@ -119,7 +118,7 @@ export default {
       <h2>Step 6 - Watch the preview, then save</h2>
       <p>As you typed, the editor recompiled and re-mounted the component in the preview iframe. Toggle
         <code>readonly</code> and change <code>value</code> in the <em>Preview props</em> panel to sanity-check
-        both modes. When it looks right, hit <strong>Save Component</strong> - the source compiles before it
+        both modes. When it looks right, press <strong>Save</strong> in the banner (or Ctrl+S) - the source compiles before it
         is written, so a typo surfaces as a clear error rather than a broken page.</p>
 
       <hr>
@@ -127,19 +126,20 @@ export default {
       <h2>Step 7 - Use it on a page</h2>
       <p>Display-only, in any Markdown page:</p>
       <pre class="code-block"><code>[component name="star-rating" max="5" value="4" readonly="true" /]</code></pre>
-      <p>Interactive, reacting to the custom event with a little page script:</p>
-      <pre class="code-block"><code>&lt;dm-star-rating max="5" value="0" id="r1"&gt;&lt;/dm-star-rating&gt;
-&lt;script&gt;
-document.getElementById('r1').addEventListener('rating-change', (e) =&gt; {
+      <p>Interactive, as a raw tag with an id:</p>
+      <pre class="code-block"><code>&lt;dm-star-rating max="5" value="0" id="r1"&gt;&lt;/dm-star-rating&gt;</code></pre>
+      <p>A page's content cannot carry a <code>&lt;script&gt;</code> - the sanitiser strips it - so the code
+        that reacts to <code>rating-change</code> belongs in site-wide JavaScript, such as a plugin's
+        <code>inject.bodyEnd</code> snippet, or in another component that wraps this one:</p>
+      <pre class="code-block"><code>document.getElementById('r1')?.addEventListener('rating-change', (e) =&gt; {
   console.log('User picked', e.detail.value);
-});
-&lt;/script&gt;</code></pre>
+});</code></pre>
 
       <hr>
 
       <h2>Step 8 - Share it</h2>
-      <p>Back on <a href="#/components">Components</a>, the <span data-icon="download"></span> Export button
-        gives you <code>star-rating.dmcomponent.json</code> - import that on another Domma site to reuse the
+      <p>Back on <a href="#/components">Components</a>, right-click the row and choose
+        <span data-icon="download"></span> <strong>Export .dmcomponent.json</strong> - it gives you <code>star-rating.dmcomponent.json</code> - import that on another Domma site to reuse the
         widget verbatim.</p>
 
       <hr>
@@ -147,7 +147,7 @@ document.getElementById('r1').addEventListener('rating-change', (e) =&gt; {
       <h2>What you used</h2>
       <ul>
         <li><strong>Props</strong> with types + defaults, coerced from attributes</li>
-        <li><strong>Template</strong> interpolation, <code>{{#each}}</code> and <code>{{#if}}</code></li>
+        <li><strong>Template</strong> interpolation, <code>&#123;&#123;#each&#125;&#125;</code> and <code>&#123;&#123;#if&#125;&#125;</code></li>
         <li><strong>State</strong> via <code>data()</code> + <code>this.set()</code>, seeded from props in <code>onMount()</code></li>
         <li>A single delegated <strong>shadow-root listener</strong> and <code>data-*</code> dispatch</li>
         <li>A bubbling <strong>CustomEvent</strong> for page-level integration</li>

package/admin/js/templates/docs/tutorial-crud.html

@@ -39,16 +39,17 @@
 
       <div class="alert alert-info">
         <strong>Why not a database?</strong> Collections store as flat JSON files on disk by default -
-        no database to install, no SQL to learn, no migrations. When you outgrow that, switch
-        individual collections to MongoDB without changing any of your pages or forms. The
-        compatibility layer is the point.
+        no database to install, no SQL to learn, no migrations. When you outgrow that, move
+        individual collections to MongoDB (a Pro feature) from the collection's <strong>Storage</strong> tab without
+        changing any of your pages or forms. The move keeps every entry's id, data and dates, so references and
+        ownership still point at the right rows. The compatibility layer is the point.
       </div>
 
       <hr>
 
       <h2>Step 1 - Create the Collection (your data store)</h2>
 
-      <p>Open <a href="#/collections">Collections</a> → <strong>New collection</strong>. You'll give it a
+      <p>Open <a href="#/collections">Data &gt; Collections</a> &gt; <strong>New collection</strong>. You'll give it a
         slug (the URL-safe name we use in shortcodes), a title, and a list of fields.</p>
 
       <p><strong>The slug matters more than you'd think.</strong> It's what every Form, Action, and shortcode
@@ -60,14 +61,18 @@
         just for show - it drives every downstream behaviour:</p>
 
       <ul>
-        <li><code>text</code> renders a text input on forms and is searchable in the Browser</li>
+        <li><strong>Text</strong> (<code>string</code>) renders a text input on forms and is searchable in the Browser</li>
         <li><code>number</code> renders a number input, gets a min/max range filter automatically</li>
-        <li><code>select</code> with options becomes a dropdown both on forms AND in the filter rail</li>
-        <li><code>multiselect</code> becomes a checkbox group AND a filterable tag chip set</li>
+        <li><strong>Dropdown</strong> (<code>select</code>) with options becomes a dropdown both on forms AND in the filter rail</li>
         <li><code>date</code> renders a date picker AND gets a from/to range filter</li>
+        <li><code>multiselect</code> becomes a checkbox group AND a filterable tag chip set</li>
         <li><code>file</code> renders a file upload with mime/size validation</li>
         <li><code>reference</code> stores a link to another collection's entry - auto-renders as a populated dropdown</li>
       </ul>
+      <p>The collection editor's Fields tab offers text, email, phone, number, textarea, dropdown, radio buttons,
+        checkbox, checkbox group, date, time, URL and hidden. <code>multiselect</code>, <code>file</code>,
+        <code>reference</code> and a few others are supported everywhere else but are set by editing the
+        collection's <code>content/collections/&lt;slug&gt;/schema.json</code>.</p>
 
       <p>Pick the right type at design time and you get the right form input, the right filter UI, and the
         right validation, all for free. Pick <code>text</code> for everything and you have to recreate all
@@ -93,7 +98,7 @@
         visitor gets the same instant render. The page is cached per role, so a million visitors viewing
         a public page hit the cache and never touch the data store.</p>
 
-      <p><strong>Five display modes are built in:</strong></p>
+      <p><strong>Eight display modes are built in:</strong></p>
 
       <ul>
         <li><code>display="table"</code> - sortable, paginated, with a search box</li>
@@ -101,16 +106,20 @@
         <li><code>display="list"</code> - vertical stack with title + meta</li>
         <li><code>display="accordion"</code> - expandable rows, title visible, body hidden until clicked</li>
         <li><code>display="timeline"</code> - chronological with dates and statuses</li>
+        <li><code>display="carousel"</code> - one slide per entry</li>
+        <li><code>display="listgroup"</code> - a compact list-group row per entry</li>
+        <li><code>display="block"</code> - each entry through a reusable block template you design</li>
       </ul>
 
-      <p>All five display the same data; you pick the right shape for the page. A directory might use
+      <p>Visitors can right-click any of them to filter, sort, copy or export (export follows the collection's
+        export setting). All eight display the same data; you pick the right shape for the page. A directory might use
         <code>cards</code>; an admin overview might use <code>table</code>; a history page might use
         <code>timeline</code>.</p>
 
       <h3>Make it interactive - flip on the Browser</h3>
 
-      <p>Adding any of <code>searchable</code>, <code>filterable</code>, or <code>sortable</code> upgrades the
-        static list to a full <strong>Collection Browser</strong>:</p>
+      <p>Adding any of <code>searchable</code>, <code>filterable</code>, <code>sortable</code> or
+        <code>paginate</code> upgrades the static list to a full <strong>Collection Browser</strong>:</p>
 
       <pre class="code-block"><code>[collection slug="jobs" display="cards" columns="3"
   searchable
@@ -133,7 +142,7 @@
 
       <h2>Step 3 - Create new records (the Form)</h2>
 
-      <p>Open <a href="#/forms">Forms</a> → <strong>New form</strong>. The slug here is the form's identity -
+      <p>Open <a href="#/forms">Data &gt; Forms</a> &gt; <strong>New form</strong>. The slug here is the form's identity -
         what you embed on a page with <code>[form name="..." /]</code>.</p>
 
       <p>Form fields can mirror the collection fields exactly, or they can be a subset. <strong>You almost
@@ -142,8 +151,11 @@
         <code>internalNotes</code> shouldn't be visible to the submitter at all. The form is your
         audience-facing slice of the collection; design it for who's filling it in.</p>
 
-      <p>Wire the form to the collection in <strong>Actions → Collection</strong>: enable it and pick the
-        target collection slug. Every submission becomes one new entry in that collection. Done.</p>
+      <p>A form stores each submission in the collection with the same slug as the form, and creates that
+        collection from its fields if it does not exist yet. The other way round, every collection you make in the
+        admin gets a matching form of its own - so for <code>jobs</code> you usually open the <code>jobs</code>
+        form and trim it, rather than starting a new one. Every submission becomes one new entry in that
+        collection. Done.</p>
 
       <h3>Identity capture (the small thing that makes everything work)</h3>
 
@@ -160,7 +172,9 @@
 
       <h2>Step 4 - Change records over time (the Action)</h2>
 
-      <p>This is where most no-code platforms top out. An Action is a server-side button: visitors click it
+      <p>This is where most no-code platforms top out. Actions are defined in <a href="#/actions">Data &gt;
+        Actions</a> and are stored in MongoDB, so they need a MongoDB connection (a Pro feature); everything
+        before this step works without one. An Action is a server-side button: visitors click it
         on a page, the server runs a sequence of steps against the entry they clicked on, and the page
         refreshes.</p>
 
@@ -168,7 +182,8 @@
         (remove the entry), <code>createInCollection</code> (write a related entry to another collection
         - this is how "apply for this job" creates an application without losing the job), <code>email</code>
         (send a notification using the entry's fields as template variables), and <code>webhook</code>
-        (POST to an external service).</p>
+        (POST to an external service), <code>moveToCollection</code> and <code>notify</code> (a notification in the
+        admin bell).</p>
 
       <h3>The transition is the magic word</h3>
 
@@ -180,8 +195,9 @@
           and the server refuses with HTTP 409. The illegal move can't happen, even if someone copies
           and edits the URL.
         </li>
-        <li><strong>Per-row UI.</strong> Add <code>transitions</code> to a <code>[collection]</code> block
-          and each row sprouts buttons for exactly the transitions legally available given that row's
+        <li><strong>Per-row UI.</strong> Add <code>transitions</code> to an interactive <code>[collection]</code>
+          block (one with <code>searchable</code>, <code>sortable</code>, <code>filterable</code> or
+          <code>paginate</code>; <code>scope="mine"</code> too) and each row sprouts buttons for exactly the transitions legally available given that row's
           current status AND the viewer's role. A candidate sees "Withdraw" on their pending application;
           an admin sees "Move to reviewing"; a candidate viewing a rejected application sees nothing
           to click. No client-side conditionals; the rules live entirely in the action definitions.
@@ -199,8 +215,10 @@
   ]
 }</code></pre>
 
-      <p>Read that JSON like a sentence: <em>"Anyone with the candidate role can withdraw their own
-        application as long as it's currently submitted or reviewing."</em> The platform enforces every
+      <p>Read that JSON like a sentence: <em>"Anyone with the candidate role (or a more senior one) can
+        withdraw their own application as long as it's currently submitted or reviewing."</em> When an action
+        lists several roles, any one of them is enough. A role name the site does not have admits nobody but the
+        level-0 role, and an action that names no roles is for admins (levels 0 and 1). The platform enforces every
         clause: <code>access.roles</code> for the role check, <code>rowLevel.mode: 'owner'</code> so
         candidates can only touch their own entries, <code>transition.from</code> for the status guard.
         Together they're the whole authorisation policy for this one button.</p>
@@ -209,10 +227,15 @@
 
       <h2>Step 5 - Who sees what (Visibility + scope)</h2>
 
-      <p>Pages have a <code>visibility</code> frontmatter field that decides who can load the page at all.
-        It accepts a single role (<em>"editor and everyone above"</em>) or an array of roles
-        (<em>"candidates OR employers"</em>). Roles are hierarchical - higher-privilege roles inherit
-        access to lower-privilege gated pages without you adding them explicitly.</p>
+      <p>Pages have a <code>visibility</code> setting (in the page editor, stored in the frontmatter) that
+        decides who can load the page at all. It accepts a single role (<code>candidate</code> means <em>"candidate
+        and everyone more senior"</em>) or an array of roles (<em>"candidates OR employers"</em>). Roles are
+        a ladder by level - more senior roles inherit access to less senior gated pages without you adding them
+        explicitly. To keep a page to exactly one role, prefix it with <code>=</code>: <code>=candidate</code>
+        admits only people who hold the candidate role (and the level-0 role), not employers or admins. The same
+        rules apply to menu items. Roles are managed in <a href="#/roles">System &gt; Roles</a>; a site starts
+        with <code>super-admin</code>, <code>admin</code> and <code>user</code>, and plugins can add their
+        own.</p>
 
       <p>For per-user data <em>within</em> a page that mixed-role users share - like a "My applications"
         block on a dashboard that both candidates and employers visit - use <code>scope="mine"</code>:</p>
@@ -222,16 +245,20 @@
   fields="jobId,status,submittedAt"
   empty="You haven't applied yet." /]</code></pre>
 
-      <p>The page itself stays cached per role; the per-user block renders client-side via a small hydration
+      <p>The page itself stays cached per role; the per-user block renders in the browser via a small hydration
         request that injects <code>createdBy = current-user-id</code> server-side (the client can never
         tamper with which user's data they see). Anonymous visitors see a sign-in prompt where the block
-        would render.</p>
+        would render. Make the block interactive (add <code>paginate</code>, <code>searchable</code>,
+        <code>sortable</code> or <code>filterable</code>) and it becomes a Collection Browser of the viewer's own
+        rows, so <code>transitions</code> works on it too; the server refuses a transition on anyone else's
+        row.</p>
 
       <p>For cross-collection scoping - <em>"recruiter sees only applications for jobs they posted"</em> -
         use the <code>reference</code> row-access mode in your action's <code>access.rowLevel</code>. The
-        platform resolves the reference to check ownership on the target. <a
-            href="/docs/configuration.md" target="_blank">Full row-access reference</a> covers all three
-        modes (<code>owner</code>, <code>field</code>, <code>reference</code>) with worked examples.</p>
+        platform resolves the reference to check ownership on the target. The row-access section of
+        <code>docs/configuration.md</code> (in the Domma CMS package) covers all three modes
+        (<code>owner</code>, <code>field</code>, <code>reference</code>) with worked examples. Saved
+        <a href="#/views">Views</a> apply the same row-level rules per viewer.</p>
 
       <hr>
 
@@ -251,12 +278,13 @@
         entries (showing the <code>displayField</code>); the page display resolves to the readable label
         everywhere; with a <code>linkTemplate</code> the label becomes a clickable link to the target's
         detail page. Validation refuses to save an entry pointing at a non-existent target. Dangling
-        references (target deleted later) render as "<em>id</em> (missing)" instead of crashing the page.</p>
+        references (target deleted later) render as "<em>id</em> (missing)" instead of crashing the page. Imports
+        are checked the same way: an imported entry pointing at a missing target is skipped and reported.</p>
 
       <p><strong>Status fields</strong> with <code>options</code> + paired <code>transition</code>-bearing
         actions = a workflow. We covered this in Step 4 but it deserves repeating: the combination of a
         typed status field, a few actions with <code>transition.from</code>, and the <code>transitions</code>
-        attribute on a <code>[collection]</code> shortcode gives you a real state machine that's enforced
+        attribute on an interactive <code>[collection]</code> shortcode gives you a real state machine that's enforced
         everywhere (UI, API, audit) with no JavaScript.</p>
 
       <hr>
@@ -264,7 +292,7 @@
       <h2>Step 7 - The Browser tour (advanced reading UI)</h2>
 
       <p>We touched on the Browser in Step 2. Here's the rest of what it does for free once you turn it
-        on with <code>searchable filterable=... sortable</code>:</p>
+        on with <code>searchable filterable=... sortable</code> (or just <code>paginate</code>):</p>
 
       <ul>
         <li><strong>Faceted filter counts</strong> - every filter chip shows the count of entries that
@@ -281,7 +309,7 @@
         <li><strong>URL state sync</strong> - every change writes to the URL query string, so deep-links
           and the browser back button work.</li>
         <li><strong>Relevance sort during search</strong> - when the search box has a term, results
-          re-order by match count with a 3× boost on matches in the title field.</li>
+          re-order by match count with a 3x boost on matches in the title field.</li>
         <li><strong>Keyboard shortcuts</strong> - <code>/</code> focuses search, <code>←</code>/<code>→</code>
           pages.</li>
         <li><strong>Infinite scroll</strong> - <code>pagination="scroll"</code> replaces the pager with
@@ -303,20 +331,22 @@
         <li>Two collections: <code>jobs</code> (employer posts roles) and <code>applications</code> (candidates apply)</li>
         <li><code>applications</code> has a <code>reference</code> field <code>jobId</code> pointing at <code>jobs</code></li>
         <li><code>applications</code> has a <code>file</code> field <code>resume</code> for the candidate's PDF</li>
+        <li><code>candidate</code> and <code>employer</code> roles, added in System &gt; Roles</li>
         <li>A public <code>[collection slug="jobs"]</code> on <code>/jobs</code> with the Browser turned on</li>
-        <li>An apply form that writes to <code>applications</code> + an action that emails HR</li>
+        <li>An apply form that writes to <code>applications</code> + an action that emails HR (actions need
+          MongoDB)</li>
         <li>A dashboard at <code>/dashboard</code> with <code>visibility: [candidate, employer]</code> and
           two <code>[collection scope="mine"]</code> blocks (one per role)</li>
         <li>Transition actions: <em>start-review</em>, <em>invite-to-interview</em>, <em>make-offer</em>,
           <em>reject</em>, <em>withdraw</em> - each with its own role + state guards</li>
-        <li>The candidate dashboard adds <code>transitions</code> and each row gets the right buttons
-          for its current status</li>
+        <li>The candidate dashboard's <code>scope="mine"</code> block adds <code>paginate transitions</code> and each
+          row gets the right buttons for its current status</li>
         <li>Recruiters get <code>access.rowLevel: { mode: 'reference', field: 'jobId', targetCollection: 'jobs' }</code>
           on their transition actions so they only ever see applications for jobs they posted</li>
       </ol>
 
       <p>That's a complete recruitment platform built in pure JSON + Markdown. The full annotated build
-        lives at <a href="/docs/recruitment-recipe.md" target="_blank">docs/recruitment-recipe.md</a>.</p>
+        is <code>docs/recruitment-recipe.md</code> in the Domma CMS package.</p>
 
       <hr>
 
@@ -330,13 +360,14 @@
 
       <p class="text-muted" style="margin-top:1rem;font-size:.9rem;">
         Recipes are JSON files under <code>server/services/recipes/</code> - copy one as a starting
-        point for your own. The <a href="/docs/scaffolding.md" target="_blank">scaffolding docs</a>
-        cover the recipe format in full.
+        point for your own. <code>docs/scaffolding.md</code> in the Domma CMS package covers the recipe
+        format in full. Applying a recipe whose collection, form, action or menu already exists is refused
+        (HTTP 409) rather than overwriting it.
       </p>
 
       <hr>
       <p class="text-muted" style="font-size:.9rem;">
-        Next: <a href="#/tutorials/plugin">Writing a Plugin →</a>
+        Next: <a href="#/tutorials/plugin">Writing a Plugin</a>
       </p>
 
     </div>

package/admin/js/templates/docs/tutorial-forms.html

@@ -7,28 +7,33 @@
   <div class="col-12">
     <div class="docs-body">
 
-      <p>Every form in Domma CMS can trigger up to four things after a submission is stored:</p>
+      <p>Every form in Domma CMS stores each submission as an entry in a collection first. After that it can do
+        up to four more things:</p>
       <ol>
         <li>Send an <strong>email notification</strong> to one or more recipients</li>
-        <li>POST to a <strong>webhook URL</strong></li>
-        <li>Execute a <strong>CMS Action</strong> (Pro)</li>
-        <li>Redirect the visitor to a <strong>success page</strong> (or show an inline message)</li>
+        <li>Send the submission to a <strong>webhook URL</strong></li>
+        <li>Run a <strong>CMS Action</strong> (needs MongoDB)</li>
+        <li>Show an inline <strong>success message</strong> or redirect the visitor to a <strong>success page</strong></li>
       </ol>
-      <p>These are configured per-form in the admin. Open any form in <a href="#/forms">Forms</a> and go to
-        the <strong>Settings</strong> and <strong>Actions</strong> tabs.</p>
+      <p>These are set per form. Open any form in <a href="#/forms">Data &gt; Forms</a>: the success message and
+        redirect are on the <strong>Settings</strong> tab; email, webhook, CMS Action and spam protection are on the
+        <strong>Actions</strong> tab.</p>
 
       <hr>
 
       <h3>1. Email notification</h3>
-      <p>Go to the <strong>Actions</strong> tab of your form and enable <em>Send email on submit</em>. Enter
-        one or more comma-separated recipient addresses. This uses the SMTP settings configured in
-        <a href="#/settings">Site Settings → Email / SMTP</a>.</p>
+      <p>On the <strong>Actions</strong> tab, in the <em>Email Action</em> card, tick <em>Send email on submit</em>
+        and enter one or more comma-separated recipient addresses. The email goes through the SMTP settings in
+        <a href="#/settings">System &gt; Site Settings &gt; Email</a>; without them nothing is delivered.</p>
 
       <pre class="code-block"><code>Recipients:       admin@example.com, team@example.com
 Subject Prefix:   [Contact Form]</code></pre>
+      <p>The subject reads <em>&lt;prefix&gt; New submission</em>. With no prefix, the form's title in square
+        brackets is used.</p>
 
       <h3>2. Webhook</h3>
-      <p>Enable <em>POST to webhook on submit</em> and enter a URL. Domma will POST the following JSON body:</p>
+      <p>In the <em>Webhook Action</em> card, tick <em>POST to webhook on submit</em>, enter a URL and choose
+        <code>POST</code> or <code>PUT</code>. Domma sends this JSON body:</p>
       <pre class="code-block"><code>{
   "form": "enquiries",
   "data": {
@@ -37,55 +42,66 @@ Subject Prefix:   [Contact Form]</code></pre>
     "message": "Hello!"
   }
 }</code></pre>
-      <p>Use this to integrate with Zapier, Make, Slack, or any HTTP endpoint.</p>
+      <p>Use this to integrate with Zapier, Make, Slack, or any HTTP endpoint. The URL is not kept in the editor's
+        draft, in case it carries a secret token.</p>
 
-      <h3>3. CMS Action (Pro)</h3>
-      <p>Actions are reusable workflow steps defined in <a href="#/actions">Actions</a>. A single action can
-        chain multiple steps: update a field, move an entry to another collection, send an email, call a
-        webhook, or delete an entry.</p>
+      <h3>3. CMS Action (needs MongoDB)</h3>
+      <p>Actions are reusable workflow steps defined in <a href="#/actions">Data &gt; Actions</a>. A single action
+        can chain several steps: update a field, move the entry to another collection, create an entry in another
+        collection, send an email, call a webhook, raise a notification, or delete the entry. Actions are stored in
+        MongoDB, so they need a MongoDB connection.</p>
       <p>To wire an Action to a form:</p>
       <ol>
-        <li>Create an Action in <a href="#/actions">Actions</a> targeting the same collection as your form.</li>
-        <li>Open the form in <a href="#/forms">Forms</a> → <strong>Actions</strong> tab → <strong>CMS
+        <li>Create an Action in <a href="#/actions">Data &gt; Actions</a> targeting the collection your form stores
+          into.</li>
+        <li>Open the form in <a href="#/forms">Forms</a> &gt; <strong>Actions</strong> tab &gt; <strong>CMS
           Action</strong> card.
         </li>
-        <li>Select the Action from the dropdown and save.</li>
+        <li>Pick it under <em>Action on Submit</em> and save.</li>
       </ol>
-      <p>The Action runs server-side, after the entry is saved. If it fails (e.g. MongoDB is not
-        configured), the submission is still stored - the action failure is non-fatal and logged as a
-        warning.</p>
+      <p>The Action runs on the server after the entry is saved, as the signed-in visitor if there is one (so
+        <code>&#123;&#123;user.id&#125;&#125;</code> and <code>&#123;&#123;user.email&#125;&#125;</code> work in its steps). If it fails - for example
+        because MongoDB is not connected - the submission is still stored.</p>
+      <p>A field's <strong>triggers</strong> (Fields tab) can also run an action, notify the admins or redirect
+        after submit, only when the answers meet the trigger's condition.</p>
 
       <h3>4. Success message vs. redirect</h3>
       <p>After a successful submission the visitor sees one of two things:</p>
       <ul>
         <li><strong>Inline success message</strong> - the form is replaced by the text set in
-          <em>Settings → Success Message</em>. Good for simple acknowledgements.
+          <em>Settings &gt; Success Message</em> (default: "Thank you for your submission."). Good for simple
+          acknowledgements.
         </li>
         <li><strong>Page redirect</strong> - the visitor is sent to the URL set in
-          <em>Settings → Success Redirect URL</em>. Good for registration flows, checkouts, or when you
-          want a full thank-you page with additional content. <strong>Takes priority</strong> if both are
-          set.
+          <em>Settings &gt; Success Redirect URL</em>. Good for registration flows or a full thank-you page.
+          <strong>Takes priority</strong> if both are set, and a trigger's "Redirect after submit" takes priority
+          over it. <code>&#123;&#123;entryId&#125;&#125;</code> in the URL is replaced with the new entry's id.
         </li>
       </ul>
       <p>Example: set <em>Success Redirect URL</em> to <code>/thank-you</code> and create a
-        <code>thank-you.md</code> page in the CMS with any content you like.</p>
+        <code>thank-you</code> page in <a href="#/pages">Pages</a> with any content you like.</p>
 
       <h3>Execution order</h3>
       <p>On every submission, the pipeline runs in this fixed order:</p>
       <ol>
-        <li>Validate fields + honeypot + rate limit</li>
-        <li>Store entry to collection</li>
-        <li>Send email (if enabled)</li>
-        <li>Call webhook (if enabled)</li>
-        <li>Execute CMS Action (if set)</li>
-        <li>Return success response → client redirects or shows message</li>
+        <li>Spam checks (honeypot and a too-fast submission are accepted silently and not stored)</li>
+        <li>Triggers: a "Block submission" trigger refuses it; an "End the form here" trigger decides what is kept</li>
+        <li>Field validation (required fields, conditional logic), then the per-minute rate limit</li>
+        <li>Store the entry in the collection - if this fails, the visitor is told and nothing else runs</li>
+        <li>Send the email (if enabled)</li>
+        <li>Call the webhook (if enabled)</li>
+        <li>Run the CMS Action (if set)</li>
+        <li>Run trigger events: run an action, notify the admins, redirect</li>
+        <li>Return success - the browser redirects or shows the message</li>
       </ol>
-      <p>Steps 3-5 are non-fatal: a failure in any of them is logged as a warning but does not prevent the
-        submission from being stored or the success response from being returned.</p>
+      <p>Steps 5-8 cannot lose the submission: a failure is logged and raises a warning in
+        <a href="#/system/notifications">Notifications</a> ("Form ...: webhook failed"), but the entry is already
+        stored and the visitor still sees success. An "End the form here" trigger set not to record stores nothing,
+        so no email, webhook or action runs.</p>
 
       <hr>
       <p class="text-muted" style="font-size:.9rem;">
-        <a href="#/tutorials">← Back to all tutorials</a>
+        <a href="#/tutorials">Back to all tutorials</a>
       </p>
 
     </div>