@ebitex/content-mcp 1.0.220 → 1.0.238
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -66,7 +66,7 @@ export const HELP_TOPICS = [
|
|
|
66
66
|
{
|
|
67
67
|
"slug": "content-workflow",
|
|
68
68
|
"title": "Editorial workflow",
|
|
69
|
-
"body": "# Editorial workflow\n\nA workflow adds a review step in front of publishing: assign one to a folder or a section of your\nExperience tree, and content there can't go live until someone carries it through the review states\nyou've defined. Nothing changes anywhere you haven't assigned a workflow — publishing works exactly\nas it always has.\n\n## Creating a workflow\n\nOpen **Workflow** under **Configure** in the app navigation and choose **New workflow**. First pick\nthe workflow's **kind** — what this workflow governs. It can't be changed after creation:\n\n- **Publishing workflow** — governs a Component or page: Draft → your review steps → Approved,\n where Approved is the only state publishing is allowed from.\n- **Translation workflow** — governs a translation job's proposed values before they're written\n into the Component. See [Translation jobs](translation-jobs.md) for how to kick one off and\n review its results.\n- **Proposal review** — governs content offered from outside your organization, by a form or by\n another system, before any of it becomes a Component. See [Proposals](proposals.md).\n\nA workflow's states come from its kind, and each state's meaning is fixed — shown on the node as\nbadges and a one-line description, never as switches you configure:\n\n- **Anchor states** (marked STATE · ANCHOR) are placed for you and can't be deleted or renamed —\n for a publishing workflow, **Draft** (where authors work freely) and **Approved** (locked, and\n the one publishable state).\n- **Step templates** are the states you add yourself, as many as you need: a **Review step**\n (content is locked while the reviewer decides) or a **Rework step** (back with the author,\n editable again). The name is yours — add two Review steps called \"Editorial review\" and \"Legal\n review\" for a two-stage approval, each with its own approver role on its transition.\n\nGive the workflow a name, then wire the graph:\n\n- **Add a step**: **+ Add node**, pick a step template, and type its name on the node.\n- **Connect two states into a transition**: every state has a small connector on each of its four\n sides — click one, then click a connector on the state you want to connect it to (or drag from\n one to the other). Click the new transition's label to name it and, optionally, restrict who may\n fire it to specific role ids (find a role's id on Hub's Roles page) — leave it blank to let any\n organization member fire it. A state without any wiring simply never occurs — there's no way to\n reach it. A state whose outcome ends the flow — a translation workflow's **Approved** and\n **Rejected** — still shows all four of its connectors, but only to receive an *incoming*\n transition: there's nothing to drag or click to start one from it, since it can never be the\n source of an outgoing transition. (A publishing workflow has no such state — even **Approved**\n can have an outgoing transition, such as a \"Revert to draft\" step, if you wire one.)\n- Every state shows how many items are **currently sitting in it** — a live count that updates as\n people submit, approve, and reject.\n\nOpen an existing workflow from the list to edit its graph the same way. A structural change (adding\nor removing states or transitions) is blocked while any item has an active review in progress — the\nerror explains this; renaming the workflow and editing attached actions (below) are always allowed\nregardless.\n\n## Attaching a Notify or Webhook to a state or transition\n\nBeyond states and transitions, the canvas offers two action node kinds via the same **+ Add node**\nmenu:\n\n- **Notify** — tell people in the app. Choose **In-app**, then who to tell: the person who took the\n move, or any role or member (`role:<id>` or `user:<id>`). Content items have no owner, so **The\n owner** skips them. They get a notification on the bell in the top bar, and the attempt is recorded\n (see Activity Log below). Email is not available yet: a Notify set to email is kept and sends\n nothing. See [Notifications](../hub/notifications.md).\n- **Webhook** — a URL your own system controls. This one is real: it actually `POST`s the transition\n details to that URL. A URL that resolves to a private or internal address is rejected when you try\n to save it. You can also set a **signing secret**, so the system receiving the request can prove it\n came from us — see **Making sure a webhook really came from us**, below.\n\nAttach either one to a **state** (fires the moment an item enters that state — click one of the\naction's own connectors, then one of the state's) or to a **transition** (fires the moment that\ntransition is used — click the action's connector, then the transition's own label). An action must\nbe attached to something before you can save. A Notify or Webhook never blocks the review itself —\neven if a webhook fails, the transition still goes through; the failure is just recorded.\n\n\"Enters that state\" means however it got there, including when nobody was involved. A review that\nstarts on its own — a translation job finishing, or a proposal arriving from a form or another\nsystem — fires whatever is attached to the state it starts in, and anything attached to a step the\nworkflow takes automatically after that. That is usually the point of attaching one: nobody is\nwatching when a proposal arrives, which is exactly why you want to be told. A Webhook fired this way\nsays so in two places: its event type is `content.workflow.runStarted` rather than\n`content.workflow.transitioned`, and `\"runStarted\": true` appears in the payload — because there was\nno transition and no previous state to name.\n\n## Making sure a webhook really came from us\n\nA webhook is an ordinary `POST` to a URL you chose, so anyone who learns that URL could send one.\nSetting a **signing secret** on the Webhook node closes that: we sign every request with it, and your\nsystem can check the signature before trusting anything in the body.\n\nLeave the secret blank and requests are sent unsigned, exactly as before — nothing you have already\nset up changes.\n\nThe secret is write-only. Once saved, the node shows **Configured** rather than the value, and we\nnever send it back to your browser. To change it, select **Replace** and enter a new one; to stop\nsigning, select **Replace** and save with the field empty. Editing anything else about the workflow\nleaves the secret alone.\n\nChanging the destination URL does **not** carry the secret over, deliberately — a different URL is a\ndifferent system, and it should get its own secret rather than inheriting one silently.\n\nEvery request carries two headers:\n\n```\nX-Ebitex-Signature: v1,t=1790000591,s=<signature>\nX-Ebitex-Delivery: whd_0123456789abcdef0123456789abcdef\n```\n\nYour system should recompute the signature over the exact bytes it received and compare. The full\nrecipe, with a worked example, is on our developer site — see\n[developers.ebitex.io](https://developers.ebitex.io). Two things that catch people out: sign the raw\nbody you received rather than re-encoding it first, and compare using a constant-time comparison\nrather than `==`.\n\n`X-Ebitex-Delivery` identifies one delivery. If we retry after a failure, the retry carries the same\nid, so your system can recognise it as a repeat rather than a second event. Use it to ignore\nduplicates.\n\n## Assigning a workflow to a branch\n\nOpen a folder's (or an Experience node's) **governance panel** — the same place you manage access\nrules — and find the **Editorial workflow** section. Choose a workflow from the dropdown, or:\n\n- **Inherit from ancestor** — use whatever the nearest parent branch has assigned (or nothing, if\n none does). This is the default for every branch.\n- **None (explicit)** — opt this branch and everything beneath it out of review, even if a parent\n branch has a workflow assigned. Useful for a sub-folder that should publish freely while the rest\n of the section stays gated.\n\n### One assignment per kind\n\nA branch carries a separate assignment for each kind, so a folder can be gated for publishing,\ngated for proposals, and ungoverned for translation all at once. Each has its own picker, and each\ninherits down the tree independently:\n\n- **Editorial workflow** — on folders and on Experience nodes.\n- **Proposal review** and **Translation review** — on folders only, since both are resolved from\n the folder an item lives in and neither has anything to do with a page's address.\n\nA kind's picker only appears once you have at least one workflow of that kind, which is why a folder\nyou have never used proposals on shows just the one section.\n\n**What \"none\" means differs by kind**, and each picker says which:\n\n| Kind | With no workflow assigned |\n|---|---|\n| Editorial workflow | Content publishes without review |\n| Proposal review | Offers to that folder are **refused** — there would be nobody to review them |\n| Translation review | Translation jobs apply their translations without review |\n\n## Submitting and reviewing\n\nOpen a Component or an Experience node under a governed branch and you'll see its current state. In the\nComponent editor it is in the status strip under the name, on the **Content** tab. If it's still in a\nnon-publishable state the strip reads **Can't be published yet** and offers the next step right there.\n**Publish…** stays available, because the publish panel explains the block and still lets the rest of what you are\npublishing go out, but it is no longer the highlighted button and its tooltip gives the reason. The full panel,\nwith its comment box and **Cancel run**, is on the **Settings** tab.\n\nSelect an available transition (e.g. **Submit for review**), optionally add a comment, and confirm.\nWhile an item sits in a **Review step** or in **Approved**, its content is locked — what was\nreviewed is exactly what publishes. If a reviewer sends it to a **Rework step**, it's editable\nagain while the review stays open; the review tracks the version you submitted, and if you edit\nduring rework, the panel tells you the item has moved past the reviewed version.\n\nOnce it reaches a publishable state, **Publish** works as normal — it publishes the reviewed\nversion and marks the review complete. If someone edited the item after submission, it will show as\n\"Modified since publish\" immediately, since the head and the published version now differ — that's\nexpected, not an error.\n\nA reviewer sees the same panel with **Approve**/**Reject** buttons (only the transitions their role\nis allowed to perform are enabled). Rejecting sends it back to the start with the reviewer's comment\nattached, and it can be resubmitted. Resubmitting while a review is already in progress starts a\nfresh one, pinned to your latest version.\n\nYou (or anyone with access-management permission) can cancel an in-progress review from the same\npanel.\n\n## Saving and deleting a workflow\n\nThe bar at the foot of the editor lists what you changed; **Save** applies it and **Discard** drops it.\nMoving a node around does not count as a change. Leaving with unsaved changes asks first. **Delete**\nasks you to confirm: Components already running keep their current review, and no new review can start.\n\n## Permissions\n\nCreating, renaming, and deleting workflow definitions requires its own \"Manage Content workflows\"\npermission. Assigning a workflow to a branch is governed by the same permission as access rules\n(\"Manage access\"), since it's branch governance, not workflow authoring. Submitting for review\nrequires edit access on the branch; approving/rejecting is limited to whichever role(s) the\ntransition names (or anyone, if none are named) — an access-management holder can always advance a\nstuck review.\n\n## Activity Log\n\nEvery submission, approval, rejection, and cancellation appears in Hub's Activity Log with the\nactor and any comment attached — the review trail is part of your organization's audit history.\nAttached Notify and Webhook actions appear there too, one entry per attempt: a Webhook shows the URL\nand the response it got back (or that it failed); a Notify shows how many people it told\n(\"delivered to 2 recipients\") and who it skipped, or \"not delivered\" with the reason.\n"
|
|
69
|
+
"body": "# Editorial workflow\n\nA workflow adds a review step in front of publishing: assign one to a folder or a section of your\nExperience tree, and content there can't go live until someone carries it through the review states\nyou've defined. Nothing changes anywhere you haven't assigned a workflow — publishing works exactly\nas it always has.\n\n## Creating a workflow\n\nOpen **Workflow** under **Configure** in the app navigation and choose **New workflow**. First pick\nthe workflow's **kind** — what this workflow governs. It can't be changed after creation:\n\n- **Publishing workflow** — governs a Component or page: Draft → your review steps → Approved,\n where Approved is the only state publishing is allowed from.\n- **Translation workflow** — governs a translation job's proposed values before they're written\n into the Component. See [Translation jobs](translation-jobs.md) for how to kick one off and\n review its results.\n- **Proposal review** — governs content offered from outside your organization, by a form or by\n another system, before any of it becomes a Component. See [Proposals](proposals.md).\n\nA workflow's states come from its kind, and each state's meaning is fixed — shown on the node as\nbadges and a one-line description, never as switches you configure:\n\n- **Anchor states** (marked STATE · ANCHOR) are placed for you and can't be deleted or renamed —\n for a publishing workflow, **Draft** (where authors work freely) and **Approved** (locked, and\n the one publishable state).\n- **Step templates** are the states you add yourself, as many as you need: a **Review step**\n (content is locked while the reviewer decides) or a **Rework step** (back with the author,\n editable again). The name is yours — add two Review steps called \"Editorial review\" and \"Legal\n review\" for a two-stage approval, each with its own approver role on its transition.\n\nGive the workflow a name, then wire the graph:\n\n- **Add a step**: **+ Add node**, pick a step template, and type its name on the node.\n- **Connect two states into a transition**: every state has a small connector on each of its four\n sides — click one, then click a connector on the state you want to connect it to (or drag from\n one to the other). Click the new transition's label to name it and, optionally, restrict who may\n fire it to specific role ids (find a role's id on Hub's Roles page) — leave it blank to let any\n organization member fire it. A state without any wiring simply never occurs — there's no way to\n reach it. A state whose outcome ends the flow — a translation workflow's **Approved** and\n **Rejected** — still shows all four of its connectors, but only to receive an *incoming*\n transition: there's nothing to drag or click to start one from it, since it can never be the\n source of an outgoing transition. (A publishing workflow has no such state — even **Approved**\n can have an outgoing transition, such as a \"Revert to draft\" step, if you wire one.)\n- Every state shows how many items are **currently sitting in it** — a live count that updates as\n people submit, approve, and reject.\n\nOpen an existing workflow from the list to edit its graph the same way. A structural change (adding\nor removing states or transitions) is blocked while any item has an active review in progress — the\nerror explains this; renaming the workflow and editing attached actions (below) are always allowed\nregardless.\n\n## Attaching a Notify or Webhook to a state or transition\n\nBeyond states and transitions, the canvas offers two action node kinds via the same **+ Add node**\nmenu:\n\n- **Notify** — tell people in the app, by email, or both. Choose **In-app**, **Email** or **In-app and email**, then who to tell: the person who took the\n move, or any role or member (`role:<id>` or `user:<id>`). Content items have no owner, so **The\n owner** skips them. They get a notification on the bell in the top bar. The attempt is recorded (see Activity Log below), and each member chooses how they are emailed. See [Notifications](../hub/notifications.md).\n- **Webhook** — a URL your own system controls. This one is real: it actually `POST`s the transition\n details to that URL. A URL that resolves to a private or internal address is rejected when you try\n to save it. You can also set a **signing secret**, so the system receiving the request can prove it\n came from us — see **Making sure a webhook really came from us**, below.\n\nAttach either one to a **state** (fires the moment an item enters that state — click one of the\naction's own connectors, then one of the state's) or to a **transition** (fires the moment that\ntransition is used — click the action's connector, then the transition's own label). An action must\nbe attached to something before you can save. A Notify or Webhook never blocks the review itself —\neven if a webhook fails, the transition still goes through; the failure is just recorded.\n\n\"Enters that state\" means however it got there, including when nobody was involved. A review that\nstarts on its own — a translation job finishing, or a proposal arriving from a form or another\nsystem — fires whatever is attached to the state it starts in, and anything attached to a step the\nworkflow takes automatically after that. That is usually the point of attaching one: nobody is\nwatching when a proposal arrives, which is exactly why you want to be told. A Webhook fired this way\nsays so in two places: its event type is `content.workflow.runStarted` rather than\n`content.workflow.transitioned`, and `\"runStarted\": true` appears in the payload — because there was\nno transition and no previous state to name.\n\n## Making sure a webhook really came from us\n\nA webhook is an ordinary `POST` to a URL you chose, so anyone who learns that URL could send one.\nSetting a **signing secret** on the Webhook node closes that: we sign every request with it, and your\nsystem can check the signature before trusting anything in the body.\n\nLeave the secret blank and requests are sent unsigned, exactly as before — nothing you have already\nset up changes.\n\nThe secret is write-only. Once saved, the node shows **Configured** rather than the value, and we\nnever send it back to your browser. To change it, select **Replace** and enter a new one; to stop\nsigning, select **Replace** and save with the field empty. Editing anything else about the workflow\nleaves the secret alone.\n\nChanging the destination URL does **not** carry the secret over, deliberately — a different URL is a\ndifferent system, and it should get its own secret rather than inheriting one silently.\n\nEvery request carries two headers:\n\n```\nX-Ebitex-Signature: v1,t=1790000591,s=<signature>\nX-Ebitex-Delivery: whd_0123456789abcdef0123456789abcdef\n```\n\nYour system should recompute the signature over the exact bytes it received and compare. The full\nrecipe, with a worked example, is on our developer site — see\n[developers.ebitex.io](https://developers.ebitex.io). Two things that catch people out: sign the raw\nbody you received rather than re-encoding it first, and compare using a constant-time comparison\nrather than `==`.\n\n`X-Ebitex-Delivery` identifies one delivery. If we retry after a failure, the retry carries the same\nid, so your system can recognise it as a repeat rather than a second event. Use it to ignore\nduplicates.\n\n## Assigning a workflow to a branch\n\nOpen a folder's (or an Experience node's) **governance panel** — the same place you manage access\nrules — and find the **Editorial workflow** section. Choose a workflow from the dropdown, or:\n\n- **Inherit from ancestor** — use whatever the nearest parent branch has assigned (or nothing, if\n none does). This is the default for every branch.\n- **None (explicit)** — opt this branch and everything beneath it out of review, even if a parent\n branch has a workflow assigned. Useful for a sub-folder that should publish freely while the rest\n of the section stays gated.\n\n### One assignment per kind\n\nA branch carries a separate assignment for each kind, so a folder can be gated for publishing,\ngated for proposals, and ungoverned for translation all at once. Each has its own picker, and each\ninherits down the tree independently:\n\n- **Editorial workflow** — on folders and on Experience nodes.\n- **Proposal review** and **Translation review** — on folders only, since both are resolved from\n the folder an item lives in and neither has anything to do with a page's address.\n\nA kind's picker only appears once you have at least one workflow of that kind, which is why a folder\nyou have never used proposals on shows just the one section.\n\n**What \"none\" means differs by kind**, and each picker says which:\n\n| Kind | With no workflow assigned |\n|---|---|\n| Editorial workflow | Content publishes without review |\n| Proposal review | Offers to that folder are **refused** — there would be nobody to review them |\n| Translation review | Translation jobs apply their translations without review |\n\n## Submitting and reviewing\n\nOpen a Component or an Experience node under a governed branch and you'll see its current state. In the\nComponent editor it is in the status strip under the name, on the **Content** tab. If it's still in a\nnon-publishable state the strip reads **Can't be published yet** and offers the next step right there.\n**Publish…** stays available, because the publish panel explains the block and still lets the rest of what you are\npublishing go out, but it is no longer the highlighted button and its tooltip gives the reason. The full panel,\nwith its comment box and **Cancel run**, is on the **Settings** tab.\n\nSelect an available transition (e.g. **Submit for review**), optionally add a comment, and confirm.\nWhile an item sits in a **Review step** or in **Approved**, its content is locked — what was\nreviewed is exactly what publishes. If a reviewer sends it to a **Rework step**, it's editable\nagain while the review stays open; the review tracks the version you submitted, and if you edit\nduring rework, the panel tells you the item has moved past the reviewed version.\n\nOnce it reaches a publishable state, **Publish** works as normal — it publishes the reviewed\nversion and marks the review complete. If someone edited the item after submission, it will show as\n\"Modified since publish\" immediately, since the head and the published version now differ — that's\nexpected, not an error.\n\nA reviewer sees the same panel with **Approve**/**Reject** buttons (only the transitions their role\nis allowed to perform are enabled). Rejecting sends it back to the start with the reviewer's comment\nattached, and it can be resubmitted. Resubmitting while a review is already in progress starts a\nfresh one, pinned to your latest version.\n\nYou (or anyone with access-management permission) can cancel an in-progress review from the same\npanel.\n\n## Saving and deleting a workflow\n\nThe bar at the foot of the editor lists what you changed; **Save** applies it and **Discard** drops it.\nMoving a node around does not count as a change. Leaving with unsaved changes asks first. **Delete**\nasks you to confirm: Components already running keep their current review, and no new review can start.\n\n## Permissions\n\nCreating, renaming, and deleting workflow definitions requires its own \"Manage Content workflows\"\npermission. Assigning a workflow to a branch is governed by the same permission as access rules\n(\"Manage access\"), since it's branch governance, not workflow authoring. Submitting for review\nrequires edit access on the branch; approving/rejecting is limited to whichever role(s) the\ntransition names (or anyone, if none are named) — an access-management holder can always advance a\nstuck review.\n\n## Activity Log\n\nEvery submission, approval, rejection, and cancellation appears in Hub's Activity Log with the\nactor and any comment attached — the review trail is part of your organization's audit history.\nAttached Notify and Webhook actions appear there too, one entry per attempt: a Webhook shows the URL\nand the response it got back (or that it failed); a Notify shows how many people it told\n(\"delivered to 2 recipients\") and who it skipped, or \"not delivered\" with the reason.\n"
|
|
70
70
|
},
|
|
71
71
|
{
|
|
72
72
|
"slug": "contracts",
|
|
@@ -141,7 +141,7 @@ export const HELP_TOPICS = [
|
|
|
141
141
|
{
|
|
142
142
|
"slug": "visitor-access",
|
|
143
143
|
"title": "Members-only pages (visitor access)",
|
|
144
|
-
"body": "# Members-only pages (visitor access)\n\nYou can keep a whole site, a section or a single page for the members of an **audience**. Everyone else is served an **unlock page** instead, and the restricted page's content, title and address are not sent to them at all. The restriction is enforced by the server, not by the page, so it holds whatever your website does.\n\nThis is different from [personalization](content-personalization.md), which changes what a page *says* for a visitor. A personalized page is still sent to everyone; a restricted page is not.\n\nThe **Visitor access** card appears only when your organization has visitor access turned on. If you do not see it, ask an organization Owner. Changing a rule needs the **Manage visitor access** permission; anyone who can see a page can read who may see it.\n\n## Setting a rule\n\nOpen a page, a section or the site's top page in **Composer** and find the **Visitor access** card. Choose one of three:\n\n- **Follow the parent.** The page is restricted if the closest page above it with a rule is. On the site's top page this reads **Follow the default** and means public.\n- **Open to everyone.** Overrides a restriction above, so one page in a members-only section can be public.\n- **Restrict to an audience.** Choose the audience. Only its members are served the page, and everything under it that follows it.\n\nThe card also says, in a sentence, who can see the page now, and where the rule comes from when it is inherited. Click the name to go there.\n\nA rule is saved at once, but, like any other change to a page, it reaches your website only when the page is **published**. Publishing a restricted page also publishes its unlock page and any restricted section above it that is not yet published, so a restriction is never missing from the live site.\n\n### Who can see this page\n\nThe table at the bottom of the card shows what happens to each kind of visitor, so you can check a rule without trying it:\n\n| Visitor | What happens |\n|---|---|\n| Not a member | Gets the unlock page |\n| Member, email not verified | Opens the page, or is asked to confirm their email, depending on the audience (below) |\n| Member, verified | Opens the page |\n\n### Which audiences you can choose\n\nOnly an audience with **stored members** can be chosen: one whose rule is about a person, such as \"has bought twice\". An audience that reads something about the visit, such as the language of the page, is worked out for each request, and a request can claim anything, so it cannot grant access.\n\nEach audience carries its own setting for how strict its access is (see [Audiences and lifecycle](../audience/lifecycle-and-audiences.md#visitor-access)):\n\n- **Open membership.** Being a member is enough. The audience can name a form that makes someone a member, and the unlock page offers it. Anyone can type anyone else's email into a form, so this suits pages where that does not matter, such as a whitepaper.\n- **Verified access.** A member must also prove they hold their email address, by following a link emailed to it. The unlock page offers a sign-in. Use this for anything that matters.\n\nThe card says which of the two the chosen audience uses, and that it is set in the Audience app, not on the page.\n\n## The unlock page\n\nThe unlock page is an **Experience** like any other, built on the **Unlock page** platform Contract. It has a heading, a message, an optional teaser, and the label of the button that opens the way in. It is always public, even when it sits inside a restricted section.\n\nChoose it in the **Unlock page** line of the card:\n\n- **A page of its own.** Pick any Experience that qualifies. For a restricted placement you can also override the heading, message, teaser and button label **per language**, so one unlock page serves many places with the right words for each.\n- **The site default.** If a placement chooses none, visitors see the site's default unlock page. Set it from **Edit site default** on the card, or from the **Default unlock page** card on the site's top page.\n- **The plain built-in message.** If nothing is chosen anywhere, or the chosen page is not published, visitors see \"Members only\" and a short message in English. They always get an answer.\n\nTo make an Experience that can be chosen, base its Contract on the **Unlock page** platform Contract: in the Contract builder, choose it under **Based on a platform Contract**. Its four fields then appear at the top of the Contract, read-only. A Template that supports that Contract can then render an Experience of it. The card warns you if a page you chose no longer qualifies.\n\nA restricted page depends on its unlock page: publishing, promoting and exporting the page carry the unlock page along, and an unlock page that a rule uses cannot be deleted while it is in use.\n\n## In the page tree\n\nRestricted pages carry a badge in the tree: the audience's name where the rule is set, and **inherited** below it. An unlock page is marked **Unlock page**.\n\n**Preview as** above the tree strikes through the pages a kind of visitor would not be served: **Not a member**, **Member, email not verified** or **Member, verified**. **Editor** clears it. It draws what the rules say; it does not sign you in as anyone.\n\n## Things worth knowing\n\n- A restricted page never appears in the sitemap or in navigation for a visitor who may not read it.\n- Removing someone from an audience takes effect within minutes: a visitor's access is re-checked every few minutes while they browse.\n- Switching visitor access off for your organization stops editing, but any rule already set keeps being enforced. To open a page, change its rule.\n- Deleting an audience that a rule uses is refused until the rule is changed; the refusal lists where it is used.\n- A restriction protects the **page**, not the things it points at. Content written directly in a restricted page is protected with it, but a shared Component that the page *references*,
|
|
144
|
+
"body": "# Members-only pages (visitor access)\n\nYou can keep a whole site, a section or a single page for the members of an **audience**. Everyone else is served an **unlock page** instead, and the restricted page's content, title and address are not sent to them at all. The restriction is enforced by the server, not by the page, so it holds whatever your website does.\n\nThis is different from [personalization](content-personalization.md), which changes what a page *says* for a visitor. A personalized page is still sent to everyone; a restricted page is not.\n\nThe **Visitor access** card appears only when your organization has visitor access turned on. If you do not see it, ask an organization Owner. Changing a rule needs the **Manage visitor access** permission; anyone who can see a page can read who may see it.\n\n## Setting a rule\n\nOpen a page, a section or the site's top page in **Composer** and find the **Visitor access** card. Choose one of three:\n\n- **Follow the parent.** The page is restricted if the closest page above it with a rule is. On the site's top page this reads **Follow the default** and means public.\n- **Open to everyone.** Overrides a restriction above, so one page in a members-only section can be public.\n- **Restrict to an audience.** Choose the audience. Only its members are served the page, and everything under it that follows it.\n\nThe card also says, in a sentence, who can see the page now, and where the rule comes from when it is inherited. Click the name to go there.\n\nA rule is saved at once, but, like any other change to a page, it reaches your website only when the page is **published**. Publishing a restricted page also publishes its unlock page and any restricted section above it that is not yet published, so a restriction is never missing from the live site.\n\n### Who can see this page\n\nThe table at the bottom of the card shows what happens to each kind of visitor, so you can check a rule without trying it:\n\n| Visitor | What happens |\n|---|---|\n| Not a member | Gets the unlock page |\n| Member, email not verified | Opens the page, or is asked to confirm their email, depending on the audience (below) |\n| Member, verified | Opens the page |\n\n### Which audiences you can choose\n\nOnly an audience with **stored members** can be chosen: one whose rule is about a person, such as \"has bought twice\". An audience that reads something about the visit, such as the language of the page, is worked out for each request, and a request can claim anything, so it cannot grant access.\n\nEach audience carries its own setting for how strict its access is (see [Audiences and lifecycle](../audience/lifecycle-and-audiences.md#visitor-access)):\n\n- **Open membership.** Being a member is enough. The audience can name a form that makes someone a member, and the unlock page offers it. Anyone can type anyone else's email into a form, so this suits pages where that does not matter, such as a whitepaper.\n- **Verified access.** A member must also prove they hold their email address, by following a link emailed to it. The unlock page offers a sign-in. Use this for anything that matters.\n\nThe card says which of the two the chosen audience uses, and that it is set in the Audience app, not on the page.\n\n## The unlock page\n\nThe unlock page is an **Experience** like any other, built on the **Unlock page** platform Contract. It has a heading, a message, an optional teaser, and the label of the button that opens the way in. It is always public, even when it sits inside a restricted section.\n\nChoose it in the **Unlock page** line of the card:\n\n- **A page of its own.** Pick any Experience that qualifies. For a restricted placement you can also override the heading, message, teaser and button label **per language**, so one unlock page serves many places with the right words for each.\n- **The site default.** If a placement chooses none, visitors see the site's default unlock page. Set it from **Edit site default** on the card, or from the **Default unlock page** card on the site's top page.\n- **The plain built-in message.** If nothing is chosen anywhere, or the chosen page is not published, visitors see \"Members only\" and a short message in English. They always get an answer.\n\nTo make an Experience that can be chosen, base its Contract on the **Unlock page** platform Contract: in the Contract builder, choose it under **Based on a platform Contract**. Its four fields then appear at the top of the Contract, read-only. A Template that supports that Contract can then render an Experience of it. The card warns you if a page you chose no longer qualifies.\n\nA restricted page depends on its unlock page: publishing, promoting and exporting the page carry the unlock page along, and an unlock page that a rule uses cannot be deleted while it is in use.\n\n## In the page tree\n\nRestricted pages carry a badge in the tree: the audience's name where the rule is set, and **inherited** below it. An unlock page is marked **Unlock page**.\n\n**Preview as** above the tree strikes through the pages a kind of visitor would not be served: **Not a member**, **Member, email not verified** or **Member, verified**. **Editor** clears it. It draws what the rules say; it does not sign you in as anyone.\n\n## Things worth knowing\n\n- A restricted page never appears in the sitemap or in navigation for a visitor who may not read it.\n- Removing someone from an audience takes effect within minutes: a visitor's access is re-checked every few minutes while they browse.\n- Switching visitor access off for your organization stops editing, but any rule already set keeps being enforced. To open a page, change its rule.\n- Deleting an audience that a rule uses is refused until the rule is changed; the refusal lists where it is used.\n- A restriction protects the **page**, not the things it points at. Content written directly in a restricted page is protected with it, but a shared Component that the page *references*, can still be reached by someone who already knows its address. A file in Assets is different: you can limit a private file to an audience in Assets (see *Limiting a private file to an audience*), and then it has no link at all for anyone else, wherever a page shows it. Keep anything else that must stay private written directly in the page.\n\n## Gate a download behind a form\n\nA public page can hold back a report until a visitor asks for it. This is how ebitex.io's own whitepaper works, built only from ordinary pieces:\n\n1. **A private file in Assets**, limited to an audience (see *Limiting a private file to an audience* in the Assets guide).\n2. **An audience that stores its members**, for example \"Whitepaper readers\", with rule \"submitted the whitepaper form\". Turn on **verified access** in Audience if a member must also prove their email.\n3. **A form in Forms** with the ebitex Audience destination, so a submission adds the person to the audience.\n4. **A page with a personalizable Presentation field.** Its **default** is the teaser everyone gets: what is inside, the form, and a way to ask for a sign-in link. Add a **variant** on the audience: the card with the download. Anyone who is not a member never receives the variant, so the file link is not in the page they load.\n5. **Share the page.** A visitor submits the form, follows the emailed link if the audience asks for verified email, and the same page now shows the download.\n\nThe visitor's device is recognised for the visit without storing anything. Remembering them on later visits needs their consent, which your site asks for itself. Give people who decline a way to ask again: the sign-in link does that.\n"
|
|
145
145
|
}
|
|
146
146
|
];
|
|
147
147
|
//# sourceMappingURL=helpCorpus.generated.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,yzZAAyzZ;KACl0Z;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,6p0BAA6p0B;KACtq0B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o1qBAAo1qB;KAC71qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,w8PAAw8P;KACj9P;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,izQAAizQ;KAC1zQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,
|
|
1
|
+
{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,yzZAAyzZ;KACl0Z;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,6p0BAA6p0B;KACtq0B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o1qBAAo1qB;KAC71qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,w8PAAw8P;KACj9P;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,izQAAizQ;KAC1zQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,okYAAokY;KAC7kY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,8xqBAA8xqB;KACvyqB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,0uHAA0uH;KACnvH;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u9JAAu9J;KACh+J;IACD;QACE,MAAM,EAAE,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,0oSAA0oS;KACnpS;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,y5YAAy5Y;KACl6Y;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,yrIAAyrI;KAClsI;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,69KAA69K;KACt+K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;IACD;QACE,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,qiPAAqiP;KAC9iP;CACF,CAAA"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ebitex/content-mcp",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.238",
|
|
4
4
|
"description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"homepage": "https://developers.ebitex.io/getting-started/content-as-code/",
|