Before adding a public Drupal chatbot, approve the information an anonymous visitor is meant to use. A published node, a visible teaser, a downloadable file and a member's view of the same page are different evidence surfaces. Map them separately, record the actual anonymous output, and ask the content owner to approve the public source. A widget's location does not establish what its answer collection may contain.
Author: Achla AI, Organization. Reviewed 14 October 2026. Prepared with AI assistance from official Drupal documentation and Achla product sources. This is an original source-approval workbook. Its scenarios are hypothetical, not observed client results or completed access tests.
Public Drupal chatbot scope starts with anonymous visitor evidence
A public chatbot should not begin with “index every published node.” Begin with the narrower question: which information has an owner approved for an anonymous visitor's questions?
Use an ordinary signed-out browser for the proposed public surface and a separate, authorized member session for comparison. Do not provide member cookies or credentials to a public-source service. The comparison is an owner review, not a way to give the assistant private access.
Record the URL, the visible information and the intended audience. If the page is reachable but contains information the owner never intended to share, reachability is a problem to resolve, not approval to use it. If it intentionally requires membership, leave it restricted.
Separate this workbook from a missing-answer investigation. Its outcome is approved source, excluded source or held requirement, before product selection. It is not a recipe for diagnosing an index or making a restricted page easier to collect.
Map nodes, content types, fields, blocks and API surfaces separately
Create a row for each representation that can carry a materially different fact. Drupal's view modes determine how content is displayed, with examples such as full content and teasers; formatters control how fields appear. A short listing should therefore not stand in for a full-page inspection. Drupal view modes and formatters.
Use this surface checklist to decide which rows your site needs:
| Surface | What to record | Why a separate row matters |
|---|---|---|
| Full node page | Content type, URL and visible fields | A public title does not establish that every field is public. |
| Teaser or listing | Listing URL and displayed summary | A summary may expose different wording or omit a condition. |
| Reusable or page block | Host page and block's visible text | A public announcement can appear outside its original node page. |
| Referenced file | Actual download URL and anonymous result | The download is a separate access surface from the linking page. |
| Published revision | Public URL and currently displayed wording | An editor's working copy may differ from the live representation. |
| API representation, if relevant | Endpoint, fields and intended consumer | Browser output does not demonstrate every API field's exposure. |
Drupal describes blocks as pieces of content that can be placed in theme regions. Record their actual host pages rather than assuming a sidebar or footer is outside the source boundary. Drupal block concept.
JSON:API respects entity and field access and does not create its own authorization layer. That is useful evidence about this API, not a guarantee that every custom endpoint or rendered page has identical output. Include an API row only when it is relevant to the planned source or exposure review; this article does not claim that Achla imports Drupal JSON:API. JSON:API security considerations.
Publication state and role permission answer different questions
Drupal distinguishes anonymous and authenticated users, with permissions assigned through roles. An editor's successful page view is therefore not a substitute for the anonymous observation. Record the session type on every evidence row. Drupal users, roles and permissions.
Record publication state separately. Drupal Content Moderation can keep a published version live while a different working copy is under review. A reviewer looking at the latest revision may be approving wording the public does not yet see. Translations can also have separate moderation states. Bind the approval to the public wording and language actually reviewed. Content Moderation overview.
Files deserve their own decision. Drupal's File module documentation explains that public files can be downloaded directly by anyone who knows the URL. Hiding an attachment from a displayed list does not establish download protection. It also warns that private storage alone does not guarantee denial: Drupal must have an applicable reason to restrict the download. Ask a maintainer to verify the actual access configuration rather than treating a directory label as the result. File module overview.
The workbook keeps three questions distinct: what state is the content in, what can this actor see, and what has the owner approved for public answers? A “yes” to one does not fill the other columns.
Fill the public-source approval register
Use one row per important representation. The following register is an illustrative example for a hypothetical professional association. The observations are invented solely to show how the worksheet works; they are not test findings.
| Content or surface | Intended audience | Illustrative anonymous observation | Illustrative authorized-member observation | Owner and approval decision |
|---|---|---|---|---|
| Membership-policy node, full view | Everyone considering membership | Public eligibility and annual renewal rule shown | Same public wording | Membership owner: include only reviewed public facts |
| Directory teaser | Everyone | Organization name and public summary shown | Additional member details elsewhere | Directory owner: approve teaser scope; inspect full record separately |
| Member-benefit node | Members | Login required | Detailed benefit terms shown | Membership owner: exclude from public assistant |
| Event page with internal planning field | Public event facts; staff planning only | Public date shown; planning field absent | Authorized staff can see planning field | Event owner: approve visible public fields; private planning stays excluded |
| Header announcement block | Everyone | Current registration notice shown | Same notice | Communications owner: approve this wording and host-page placement |
| Public handbook download | Everyone | Direct file URL opens without sign-in | Same file | Handbook owner: approve file separately from its linking node |
| Revised policy awaiting review | Public approved revision only | Earlier approved wording visible | Editor can inspect proposed wording | Policy owner: approve live version only; retest after later publication |
Add exact URLs, content type or field identifiers where useful, review date, evidence location and the person responsible for permission configuration. Leave unresolved observations visibly unknown. Do not replace a blank with an assumption such as “published, therefore public.”
For a real register, use short factual observations: “anonymous page shows title and body; field X absent,” rather than “secure.” The former can be repeated; the latter conceals the actual scope. Keep sensitive member values out of the public approval record. Record the surface and access result without copying private content into the proposed chatbot source.
Run paired anonymous and member scenarios
Choose a few representative situations, not just your easiest public page. The examples below describe what to test; they do not report completed results.
Public policy node. Open the intended policy URL without sign-in and identify one fact a visitor should be able to ask about. Compare the member view. If the wording is identical and the owner approves it, the row can move toward inclusion. If the member sees extra material, record which representation carries the approved fact.
Members-only node. Verify the anonymous outcome and then inspect it through an authorized member account. If the task depends on the member-only text, exclude that source from the public widget evaluation. A different product with verified authenticated retrieval may be needed; the Drupal architecture guide addresses that broader operating decision.
Page with a restricted field. Compare the field output, not just the page title or status code. Ask the field owner whether the anonymous representation is intentional. If an internal planning note appears publicly, hold source approval and notify the site's responsible maintainer through the team's existing process. Do not treat accidental exposure as permission to use it.
Referenced document. Test the actual download URL in the anonymous session. A login barrier on the parent page does not, by itself, settle access to a public file URL. Record the download result and the file owner's decision without changing storage or permissions during the review.
These pairs reveal source scope. They do not prove that a chatbot implements user-specific permissions. No such Achla capability is asserted here.
Assign include, exclude, fix-public-content or hold-private-workflow
Give each row one explicit disposition and a next owner action:
| Decision | Meaning | Next action |
|---|---|---|
| Include | Already-public representation is intentionally approved for the public task | Keep exact surface, wording scope, owner and date in the evaluation inputs |
| Exclude | Material is private, unnecessary or not approved | Keep it outside the proposed public source set; retain the decision record |
| Fix-public-content | Intended public information is ambiguous or conflicts across public surfaces | Ask the content owner to correct and approve the public wording before evaluation |
| Hold-private-workflow | Essential visitor task requires an authenticated source or personal result | Stop this public-only product path and investigate a separately verified workflow |
“Fix-public-content” does not mean relaxing access controls. For example, a hypothetical event page may say one registration deadline while its public header block says another. The communications owner must settle the intended public fact. The assistant should not be asked to choose which deadline is official.
“Included” also does not mean successfully collected or answered. Approval establishes that the content is permissible for the task. Later product tests establish whether the documented source path can use it and return an appropriate answer. Keep those results as separate evidence.
A public-only product may still fit a site containing member pages. The relevant question is whether the chosen visitor job can be fulfilled using the approved public surfaces. If it cannot, do not expand this product's documented capability through wishful interpretation.
Keep evidence and ownership current when publishing changes
Review affected rows after a content-type display, field, block, role, file or publication change. Record which earlier decision is still valid and which representation needs another anonymous check. Retain the previous evidence so the owner can explain the change.
Include the normal anonymous delivery path in the check. Drupal documents cache variations through cache contexts and notes that Internal Page Cache assumes identical pages for anonymous visitors. A signed-in editor's fresh output cannot establish the anonymous cached result. Ask the maintainer to investigate discrepancies; this workbook does not prescribe cache or permission changes. Drupal cache contexts.
Historical module issue reports can identify questions worth testing, but they do not prove a bug in your current installation. Prefer a dated observation of your own approved surface and the responsible owner's decision.
Evaluate the public-content Drupal connector only after approval
Once the source register supports a public-information task, review the existing Achla Drupal product page and current installation instructions. The evidenced product is a managed website-content answer widget with supporting source links. This article does not claim that the connector inherits Drupal roles or enforces private per-user retrieval.
Use troubleshooting documentation for the later installation checks, and current pricing for terms. If the public boundary fits, begin onboarding; sign-in may be required. Bring the approved register to that evaluation. Keep member-only sources excluded.
