38d1e367fc
The knowledgebase plugin is a link registry - a description, a URL and some keywords pointing at a document held somewhere else. That leaves the documents themselves as HTML files on a share: no search, no history, no way to know whether the copy pinned to a noticeboard is current, and no way for a technician to tick off where they are. A guide is stored as an ordered list of typed blocks rather than a blob of HTML, because three of the four things this feature exists for depend on it. A tickable step needs a stable id to be remembered; dark mode needs semantic markup rather than pasted colours; and print needs to know where a step begins so it does not split one across a page. Free HTML gives none of that and lets pasted styling fight the theme. Inline text is a restricted Markdown subset - bold, italic, inline code, links, line breaks - escaped BEFORE formatting, so nothing an author pasted can reach the DOM as markup. No fonts, sizes or colours: emphasis is semantic and the theme decides how it looks. That is what makes a guide written next year match one written today, and dark mode work without an author thinking about it. DRAFTS AND VERSIONS. The guide row is the working copy; every save that changes something writes an immutable revision; and a separate pointer says which revision READERS get. Without that pointer, editing a live procedure changes it under a technician who is halfway through following it. Publishing promotes an existing revision rather than snapshotting, so a publish with unsaved edits cannot ship a version nobody reviewed. Restoring writes a new revision with old content, so the record of what people were told in between survives. Saves dedup on a content hash covering title, summary, tags and blocks, so an autosave that changed nothing writes no version - otherwise the history fills with identical entries and hides the three edits that mattered. Progress lives in the browser, not the database: shopfloor PCs share a login, so per-user ticks would show one technician's progress to the next person on that bay, which reads as "already done". Keyed by guide and version, because step 4 of version 3 is not step 4 of version 2. Five permissions, and the split between edit and publish is the point: a technician can write a procedure up while somebody else decides it is fit for the floor. create-without-edit works too - an author may edit their own guide until it is published, after which other people are following it.
43 lines
1.3 KiB
JavaScript
43 lines
1.3 KiB
JavaScript
/**
|
|
* Guides plugin routes.
|
|
*
|
|
* Three views, and the split between the last two is deliberate: reading a
|
|
* guide and editing one are different jobs with different rights, and the
|
|
* checkboxes are live in exactly one of them.
|
|
*
|
|
* meta.plugin = 'guides' so the ADR-009 router guard redirects when the backend
|
|
* plugin is disabled. Every route requires auth because every guides API route
|
|
* is behind JWT plus a guides.* permission.
|
|
*/
|
|
export default [
|
|
{
|
|
path: 'guides',
|
|
name: 'guides',
|
|
component: () => import('./views/GuidesList.vue'),
|
|
meta: { requiresAuth: true, plugin: 'guides' }
|
|
},
|
|
{
|
|
path: 'guides/new',
|
|
name: 'guide-new',
|
|
component: () => import('./views/GuideEditor.vue'),
|
|
meta: { requiresAuth: true, plugin: 'guides' }
|
|
},
|
|
{
|
|
path: 'guides/:slug',
|
|
name: 'guide-view',
|
|
component: () => import('./views/GuideView.vue'),
|
|
meta: { requiresAuth: true, plugin: 'guides' }
|
|
},
|
|
{
|
|
path: 'guides/:guideid/edit',
|
|
name: 'guide-edit',
|
|
component: () => import('./views/GuideEditor.vue'),
|
|
meta: { requiresAuth: true, plugin: 'guides' }
|
|
}
|
|
]
|
|
|
|
// No full-screen routes: every view renders inside AppLayout. Declared so
|
|
// routes.gen.js can read `.toplevel` off the module without Rollup warning
|
|
// about a missing export.
|
|
export const toplevel = []
|