The Knowledge Base also lives inside mywork's floating chat-widget. Click the chat FAB at the bottom-right of any mywork page → click the Help tab at the bottom of the chat shell, and you're reading articles without leaving your work. This article tours that surface and explains how it stays in sync with the public reader.
Where it lives
mywork's chat-widget shell has three tabs at the bottom:
- Chats — direct messages and group conversations.
- Notifications — system-generated alerts.
- Help — the Knowledge Base.
Clicking Help swaps the body content for a Web Component called <kb-widget>. The component is Shadow-DOM-isolated, so its CSS doesn't bleed into mywork and mywork's CSS doesn't bleed in.
Three internal views
The widget renders one of three views at a time, depending on what the user is doing.
| View | Triggered by | Looks like |
|---|---|---|
| Tree | Default on open. Empty search. | A search input at the top, then a vertical list of folder cards. Each card has the folder icon, the folder name, the recursive article count, and a chevron. Click a folder card to expand its subfolders + articles inline (accordion behaviour). |
| Search | Type into the search input. 300 ms debounce. | The folder tree disappears; a flat list of article hits replaces it. Each hit shows the article title with the article icon. The list is the same FULLTEXT result as the public reader's search — see Search the Knowledge Base. |
| Article | Click a folder's article, a search hit, a related-article card, or any in-body /a/<slug> link. | An icon back button + the article title at the top, then the rendered body with an inline On this page TOC at the start, then a Related list at the bottom. |
How content gets there
The widget makes four cross-origin requests to the kb-app on demand:
| Request | When | Returns |
|---|---|---|
GET /api/kb/folders | On widget mount. | The full folder tree with article summaries. Cached on the widget for the session. |
GET /api/kb/search?q=… | Each time the user types (debounced). | Up to 50 article hits, ranked. |
GET /api/kb/article?slug=… | When opening any article. | The article body, keywords, and Related list. |
GET /api/kb/widget.css | On widget mount. | A self-contained stylesheet covering article body chrome (callouts, code blocks, tables, image alignment). Injected as a <style> in the Shadow DOM. |
All four are public reads — no X-API-Key header. CORS is Access-Control-Allow-Origin: * so the widget can call from any host.
Internal links re-render in place
When an article body has a link like [click here](/a/the-dashboard), the widget intercepts the click:
- It checks whether the link's href matches
^(?:https?://[^/]+)?/a/<slug>$. - If yes, it prevents the default navigation, extracts the slug, and calls its own
openArticleBySlug(slug)method — which fetches the article and re-renders the article view. - If no, the link is treated as external. The widget sets
target="_blank"andrel="noopener noreferrer", so the click opens a new browser tab and leaves the chat session intact.
This is why article links work everywhere with no special syntax — write [Some article](/a/some-slug) in the editor, and it does the right thing in the public reader (normal navigation), in the chat-widget (re-renders inside the widget), and inside any future surface that consumes article HTML.
Blob URLs are rewritten
Images and videos referenced via /api/kb/blobs/<id> are relative URLs. In the public reader they resolve to https://mydoc24.org/api/kb/blobs/<id> automatically. In the chat-widget — which runs from mywork's origin — relative URLs would resolve against mywork and 404.
The widget rewrites every relative /api/kb/... URL inside the article body (in src and href attributes) to absolute URLs against the kb-app origin before insertion. This is the rewriteRelativeUrls helper in kb-widget.js. Do not store absolute kb-app URLs in article bodies. Keep them relative — the widget handles the rewrite for any deployment URL.
Resize the widget
The chat-widget shell has a small resize handle in its top-left corner. Click it to toggle between two preset sizes:
- Compact — 380 × 580 px. The default.
- Expanded — 720 × 820 px. Useful when reading a long article or wide tables.
The choice persists per browser via localStorage.chatWidgetSize. The handle was previously a free-form drag-resize; the click-toggle replaces it because freeform resize made the article view escape its container.
What's not in the widget
- No editor. The widget is read-only. Authors edit on
/admin/edit/<slug>. - No archive view. The widget only sees
PUBLISHEDarticles. See Article statuses field definitions. - No login state. The widget calls public read APIs — it doesn't know who the user is. mywork's login powers the widget's visibility (only signed-in mywork users see the chat-widget) but not its content gating.
- No standalone URL. You can't link directly to a chat-widget article view; the widget always opens at the tree view. Internal
/a/<slug>deep links from outside the widget go to the public reader instead.
Theming
The widget reads CSS variables from mywork (the host page) — --primary-color, --surface-card, --surface-border, --text-color, etc. — so it picks up mywork's PrimeFaces theme automatically. Switching mywork's theme (light/dark, accent colour) is reflected in the widget without a kb-app deploy.
Related
- The Knowledge Base — the public reader and admin landing.
- Search the Knowledge Base — the search box at the top of the widget.
- Article statuses field definitions — visibility rules that the widget honours.