Internal Wiki
The Internal Wiki is the Helpdesk's staff-only knowledge pillar — a private library of how-to articles and process notes for your team. It shares the same tables and management screens as the public Knowledge Base, but every article is gated behind authentication and the help permit and is never exposed to guests or customers.
What the Internal Wiki is
The Internal Wiki is where your organization documents the things it does not want customers to read: onboarding checklists, escalation procedures, tool configuration steps, internal FAQs, and process notes. It is the private twin of the Knowledge Base. Both pillars are served by the same Help controller, the same Help_articles_model / Help_categories_model, and the same two tables — they are distinguished only by a discriminator column.
type column equals help. The exact same code path serves the Knowledge Base when type equals knowledge_base. There is no separate "wiki" table — changing an item's type is what moves it between the two pillars.Who can reach it
The Help controller extends App_Controller, so a valid staff login is always required. Its constructor then enforces two more conditions before any Wiki page renders:
Module toggle
$this->with_module("help", "redirect") checks the module_help sub-toggle (the Internal Wiki pillar switch, which sits under the module_helpdesk master in Manage Modules). If module_help is off, the user is redirected away.
Permission check
with_permission_any("help", "knowledge_base") requires the user to hold either the help or the knowledge_base permit. Without both a module toggle and a permit, the request is sent to forbidden.
Per-view refinement
Individual tabs and actions apply narrower permits — help_create, help_category, help_categories, and so on — so a read-only agent sees the Preview while a manager also sees the Articles and Categories management tabs.
App_Controller authentication. Do not treat the Wiki as a place to draft content you intend to publish externally; use the Knowledge Base for that.The management interface
Opening /help renders help_and_knowledge_base/articles/index: a tabbed screen whose tabs are AJAX-loaded on demand. Which tabs appear depends on your permits.
| Tab | Loads (endpoint) | Shown when | What it does |
|---|---|---|---|
| Preview | help/view_preview | Always (default active) | Renders the reader-style category grid exactly as staff browse it — category cards with article counts. |
| Articles | help/view_articles | list_articles (holds the help permit) | DataTable of all Wiki articles with a category filter, plus the Add Article button when you hold help_create. |
| Categories | help/view_categories | has_category (holds help_categories) | DataTable of Wiki categories, plus the Add Category button when you hold help_category_create. |
Articles tab
The Articles panel (articles/tab-panel) shows an appTable DataTable sourced from help/articles_list_data/help. Columns are Title (a link to the article view), Category, Status, Total Views, and a per-row action column. The action column carries a pencil (edit) link when you hold help_update and an times (delete) link when you hold help_delete. A category filter dropdown at the top lets you narrow the list to one category.
Categories tab
The Categories panel (categories/tab-panel) shows an appTable sourced from help/categories_list_data/help with columns Title, Description, Status, Sort, and an action column. The edit action opens the category modal (help/category_modal_form/help); the delete action posts to help/delete_category?type=help. Each row's action links are individually gated by help_category_update and help_category_delete.
The article form
The article editor (articles/form) is reached at help/article_form/help (new) or help/article_form/help/{id} (edit). Its fields:
| Field | Control | Notes |
|---|---|---|
| Title | Text input | Required. Autofocused on load. |
| Category | Select2 dropdown | Required, numeric. Only categories you are allowed to see appear (see the category-access dropdown below). |
| Description (body) | WYSIWYG rich-text editor | The article body. Supports styles, lists, tables, links, images, and video embeds. |
| Status | Radio: Active / Inactive | Only active articles are visible to readers. |
| Files | Dropzone upload | Attachments upload to a temp dir, then move to the permanent timeline path on save. |
Saving posts to help/save_article. On success the controller re-renders the same edit form with a record_saved flash message, so you can keep editing. The form submits as a full page (not AJAX), because it carries file uploads.
The category modal
Adding or editing a Wiki category opens a modal form (categories/modal_form) with Title (required), Description (rich text), Sort (a numeric order key), and a Status radio (Active / Inactive). Saving posts to help/save_category; on success the row is spliced into the category DataTable in place without a full reload.
sort value on the Preview grid and reader pages (ascending). Give your most-used categories a lower sort number so they surface first.Core workflows
1. Create a Wiki category
Open /help → Categories tab → Add Category. Enter a title (e.g. "Onboarding"), an optional description, a sort number, and set Status to Active. Save. The category appears in the grid and becomes selectable in the article form.
2. Write & save an article
Articles tab → Add Article (or open help/article_form/help directly). Enter a title, pick the category, write the body in the rich-text editor, attach any files, set Status to Active, and Save. You land back on the article's edit form with a saved confirmation.
3. Edit an existing article
From the Articles DataTable, click the title (to read) or the pencil action (to edit). The pencil opens help/article_form/help/{id} pre-filled. Change what you need and Save. Existing attachments are preserved unless you remove them.
4. Organize & reorder
Adjust category Sort values to reorder the Preview grid. Move an article between categories by editing it and choosing a different Category. Retire outdated content by setting its Status to Inactive rather than deleting it — it disappears from readers but stays recoverable.
5. Search for an article
The reader search box calls help/get_article_suggestion, which returns up to 10 autocomplete matches (by title or body) — scoped to the categories your role is allowed to access. Start typing and pick a suggestion to jump straight to the article.
- Decide the home category. If none fits, create one via Categories → Add Category (Active, sensible sort).
- Open Articles → Add Article. Title it as a task ("How to reset a locked kiosk terminal"), not a topic.
- Select the category, then write the steps in the rich-text body — numbered steps, screenshots (image insert), and any warnings inline.
- Attach reference files (a config export, a form) via the Upload File button.
- Set Status to active and Save.
- Verify from the Preview tab that the article appears under the right category and that its view opens cleanly.
Because Wiki and KB share one table set and differ only by the type discriminator, you move content between pillars by re-homing it into a category of the target type. There is no in-UI "convert" button, so use this procedure:
- Confirm the content is safe to publish externally — strip any internal-only credentials, links, or process notes.
- In the Knowledge Base (
type = knowledge_base), create or pick the destination KB category. - Re-create the article under that KB category: open the KB Articles tab → Add Article, then paste the title and body. (Editing an existing Wiki article only lets you choose categories of the same type, so a fresh KB article is the clean path.)
- Set the new KB article Active; set the original Wiki article Inactive (or delete it) so the two do not drift out of sync.
- Verify the article now appears on the public Knowledge Base and no longer implies internal-only context.
Developer note
The underlying move is a single-column change (an article's category, whose category_id points at a category whose type flips the pillar). Only make that change through a model method — never with raw SQL from a controller or view.
Category-level access control
Beyond the coarse read/create/edit/delete permits, the Wiki respects a per-category access model driven by the help_categories permit. It renders an all/specific dropdown in the RBAC UI:
When a role's help_categories is set to specific, the models restrict results to the category IDs stored in help_categories_specific (a comma-separated allow-list) using a FIND_IN_SET filter. Admins and roles set to all bypass the restriction. Roles with neither all nor a matching specific list get empty article, category, and search results.
Internal Wiki vs. Knowledge Base
These pillars are code twins. This table captures every meaningful difference; everything else (tables, controller, models, forms) is shared.
| Aspect | Internal Wiki | Knowledge Base |
|---|---|---|
| Audience | Staff only | Staff + public / anonymous |
| Visibility | Private — never exposed to guests | Has public / anonymous reader views |
| Guard | Always requires auth (App_Controller) + help permit | Auth for management; public views for reading |
type value | help | knowledge_base |
| Controller | Help | Knowledge_base (shares Help's views/models) |
| Base route | /help | /knowledge_base |
| Category access permit | help_categories (+ help_categories_specific) | knowledge_base_categories (+ specific) |
| Adsense snippet | internal_wiki | knowledge_base |
Routes & endpoints
Only the three linkable entry points below are pinned in the module's config/routes.php. Every other Help method — including all the multi-segment management endpoints — resolves through App_Router default segment dispatch (no explicit route needed).
Pinned entry points
/help → Help/index/help/category/{id} → Help/category/$1/help/view/{id} → Help/view/$1Management endpoints (default dispatch)
| Endpoint | Method | Purpose |
|---|---|---|
help/view_preview | GET | Renders the reader-style category grid for the Preview tab. |
help/view_articles | GET | Renders the Articles management tab (DataTable + Add Article button). |
help/view_categories | GET | Renders the Categories management tab (DataTable + Add Category button). |
help/article_form/{type}/{id} | GET | Add/edit article form. {type} is help; {id} optional. |
help/save_article | POST | Persists an article (multipart, with file moves). Redirects back to the form. |
help/delete_article | POST | Soft-delete (or undo) an article. type passed as a query param. |
help/articles_list_data/{type} | POST | DataTable JSON feed for the Articles tab. |
help/category_modal_form/{type} | POST | Add/edit category modal body. |
help/save_category | POST | Persists a category; returns the new row JSON. |
help/delete_category | POST | Soft-delete (or undo) a category. type passed as a query param. |
help/categories_list_data/{type} | POST | DataTable JSON feed for the Categories tab (fetched via the appTable plugin's POST source, like the articles feed). |
help/get_article_suggestion | POST | Autocomplete search — up to 10 access-scoped matches. |
help/upload_file | POST | Uploads an attachment to the temp dir. |
help/validate_file | POST | Validates a posted attachment. |
help/download_files/{id} | GET | Downloads an article's attachments. |
{type} Because the KB reuses the Help controller, the same help/* endpoints serve both pillars — the {type} segment (help vs. knowledge_base) selects which. The Knowledge Base's own knowledge_base_articles / knowledge_base_categories wrappers simply preset type = knowledge_base and reuse the identical tab panels.Permissions (RBAC)
Wiki permits live in the module's config/permissions.php and surface in the Roles UI under the Help Center: Internal Wiki group only when module_helpdesk is enabled. Assign these per role.
| Permit key | Grants | Type |
|---|---|---|
help | Access the Internal Wiki pillar — the Articles tab and read access. | Enable toggle |
help_create | Create Wiki articles (shows the Add Article button and allows save_article for new records). | Action |
help_update | Edit Wiki articles (shows the pencil action; allows save_article on existing records). | Action |
help_delete | Remove Wiki articles (shows the delete action; allows delete_article). | Action |
help_category | Enable the Wiki Category feature (surfaces category management). | Action |
help_category_create | Create Wiki categories (Add Category button; save_category for new records). | Action |
help_category_update | Edit Wiki categories (pencil action; save_category on existing records). | Action |
help_category_delete | Remove Wiki categories (delete action; delete_category). | Action |
help_categories | Access to Wiki categories — the all/specific access dropdown that scopes which categories the role can see. | Access dropdown (all / specific) |
help_categories is not a typo of help_category They are distinct permits. help_category* controls whether the user can create/edit/delete category records; help_categories is the all/specific access scope that limits which categories (and their articles) the user can see and search. A role can have full category CRUD yet still be scoped to a subset via help_categories = specific and its help_categories_specific list.Statuses & states
Both articles and categories carry a simple two-value status. Only Active items are visible to readers, appear in category counts, or return from search.
| State | Applies to | Effect |
|---|---|---|
| active | Article, Category | Visible to readers, counted, searchable. The default on new records. |
| inactive | Article, Category | Hidden from readers and search; still editable by managers. Use it to retire content non-destructively. |
| Deleted (soft) | Article, Category | Set via the delete action; removed from all lists but recoverable through the delete/undo response. |
Terminology
The staff-only knowledge pillar. Backed by help_articles / help_categories rows whose type is help.
A single Wiki entry: title, category, rich-text body, status, optional attachments, and a view counter (total_views).
A grouping of articles with a title, description, sort order, and status. Also the unit of access control via help_categories.
The reader-facing view rendered inside the management screen so managers can see exactly what staff readers see.
The help_categories dropdown that determines whether a role sees every Wiki category or only those listed in help_categories_specific.
A search autocomplete result (up to 10) returned by get_article_suggestion, scoped to the user's allowed categories.
Tips & best practices
help_categories = specific.Troubleshooting
Two gates must pass. First, the module_help sub-toggle must be enabled (it sits under the module_helpdesk master in Settings → Manage Modules) — otherwise with_module("help") redirects you. Second, your role must hold either the help or knowledge_base permit — otherwise you are sent to forbidden. Have an admin verify both.
Tabs are permit-gated. The Articles tab needs the help permit; the Categories tab needs help_categories. If you only see Preview, your role lacks those permits — assign them in the Roles editor.
Article counts and reader visibility require the article to be Active and the parent category to be Active. Check both statuses. Also confirm you are not viewing under a role scoped away from that category via help_categories = specific.
Suggestions are scoped by category access. If the role's help_categories is specific with an empty or non-matching help_categories_specific list, the search returns an empty set by design. Grant the relevant categories or set the scope to all.
The buttons are gated by help_create and help_category_create respectively. Without the create permit the tab is read-only. Row-level edit and delete actions are likewise gated by help_update/help_delete and help_category_update/help_category_delete.
Editing a Wiki article only lets you choose categories of the same type, so you cannot re-home it into a KB category from the edit form. Follow the promote-to-KB SOP above: re-create the article under a knowledge_base category, then retire the original.
Related pages
Knowledge Base
The public twin of the Wiki — same tables, type = knowledge_base, guest-visible.
Permissions Reference
Every Helpdesk permit, including the full help* set and category access scopes.
Web Pages & Help Center
Public-facing pages and the CMS-themed Help Center front door.
Developer APIs
Endpoints, dispatch, and model contracts behind the Helpdesk module.