KB rework

These are the wanted features to remaster the knowledge base and make it look like modern wiki systems like Notion, Obsidian, or Outline

To check also: https://www.odoo.com/fr_FR/app/knowledge

Quick mock-up of the feature done with Copilot. Please note, this is not a final design, more an inspiration to take.
Styles are not fixed, and are here to present a coherent experience for the preview.

Please check directly with the following mini site showcasing features (without any serious implementation): https://orthagh.github.io/glpi_newkb_mockup (source available)

Standard interface and admin features

The most important point is to remove most tabs and integrate them into a single UI.

All features are detailed below.

Sidebar and nested documents

On the left of the page, a sidebar will display

• the tree of documents, a click on a document will directly display it in the document view.

• a few special actions (explained later)

Every document will accept nested documents.
Previously, we had categories to represent the tree. We will migrate these to documents themselves, and reconstruct the whole tree at migration.

Documents containing children are foldable.

On hover of a document link, a “+” button will appear. Clicking on it will show under a new nested line with an input[type=text] control to type the document title.
After an [Enter] key, we will be redirected to the new document with the top heading set with the typed label.

Sidebar can be collapsed via a dedicated button.

When enabled, the sidebar change its display mode to hover and hide on a few pixels. Hovering the small zone display temporary the sidebar above the document.

Document view

We have a single page for viewing or editing a document.
A toggle button will be displayed on top right to change the current mode.

In both modes, we have:

• a breadcrumb system.

• a meta section, just after the title, dimmed texts, with:

  • the last update and the associated user

  • the number of views,

  • the number of linked documents and GLPI items

  • etc.

  Just make sure the displayed meta are coherent with the interface and the rights. We shouldn’t display the last updater on self-service for example.

  
  

• a scroll-spy component for displaying summary of headings anchored on the top-right of the viewport

  
  

  
  
  

  
  

In view mode only, we have:

• Anchors on headings

In edit mode only, we have

• The title is editable, and an icon can be chosen when clicking just before the title

• A modern WYSIWYG editor to edit the document with blocks and slash commands like Notion. A few candidates (see Text editor libraries for more details):

  • tiptap

  • Lexical

  • milkdown

  To note, some users don’t like the “/ trigger” and the headless menu bar. They prefer a classic system with a big toolbar. An option should be proposed in “Preferences” page.

• An emoji picker, triggering on “ :” (with space before)

• Users mention, triggering on “ @” (same)

• Saving is automatic, but maybe triggered on a small delay to avoid overloading the server. Also, a click on the “Save” button force triggers the saving in database and end the “Edit” mode.

Action menu

On top right of the page, a click on the three-dots icon will show a menu of secondary actions.

This action menu and its three-dots link should also be available when hovering a document link in the left tree.

Comments

They can target the whole document or a specific node (That could be very difficult to achieve ourselves, and may require a text editor library that offer the possibility).
Prior to the new design, it was already possible to comments about the document, so we need to migrate these attached to the document.

Comments will be available though an action menu (in the top right burger menu), that opens a side panel displaying all comments.

If a comment target a specific node of text in the article, it must be highlighted (underline by default, a background when active), and on click, it also opens the side panel. A selected comment in the Dom will be highlighted in the panel.

Comments can be marked as “Resolved”.

A mini form will be available at the bottom of the panel to add a comment on the whole document (no text node target).

Selecting a text in “View” mode should also propose to add a comment targeting the selection.

History / Revert

Another side panel will be available though the “History”, and will display here document changes, in addition to property changes (ex: “XX added document”, “XY edited permissions”).

For document changes, it will be possible to revert the changes.

A click on a document revision will display change the content of the main document container, with a highlight of the changes. In this case also a “Restore” button (outline secondary) will appears on top right (in place of modify/save button) to apply the revert.

Search

A click on the search link will make a modal appears where we will have:

• a fuzzy input

• recent searches

• maybe a few tips

Drafts

A document is considered as a draft when no rights for users have been added, and so when it’s only visible for administrators.

They are available through a link in a special section of the side panel.

A click on this link will display a special page listing all draft documents.

Favorites

Each document can be set as a favorite with a control (star icon) available in the action-menu.

The left side-panel will display the list of favorites in a special section.

Breadcrumbs and main title

At the top of the container, we will always display a breadcrumbs section where we are placed in the document tree.

We will have a virtual document named “GLPI”, non-removable but editable (its title also), to act as a root node.

Then we display the nested document in order.

If we have a long chain, we should make the ellipsis (with a tooltip to recall the rest) in the middle:

GLPI > … > My final article

On document scrolling, the breadcrumb will continue displayed, and will recall the title.

Icon picker

In edit mode, left to the title, the icon can be modified.
On hover, a distinct style is applied to indicate the possibility to edit it.

When clicking on this zone, we open the illustration picker we already have developed for the forms in 11.0 version.

By default, we’ll use a generic icon for all articles. This could be particular useful for migrating the existing instances; maybe something like a folder or a file (Note: we may request news icons to our designer if needed)

Permissions and sharing

On click on the corresponding menu item, a single modal will open with 2 tabs:

• one for classic permissions (we may reuse the original “Targets” feature of current kb)

  
  
  

• One for sharing publically the document

  
  In the same way as the “Allow direct access” form feature, the sharing toggle must be disabled by default, and use a token for verifying link access.

  
  

Attachments and documents

Currently, GLPI allows linking documents to a kb article.

We may add a footer listing the existing documents.

A button is available (only in edit mode ?) to add new ones or link existing and open a modal for that.

Links with other GLPI items

In the same footer, a second tab will display the links of associated GLPI objects.

As for the document, a button is present to link to other assets, the form will be displayed in a modal.

Translations

An entry in the action menu allows to enable translation mode.
In this case, a special header is display to alert the user.

Entering translation mode, also means enabling editable mode of the document and the title (and so full editor, save button, etc)

If any translation already exists, a count recalls it in the meta header. When no translation done, the label should not be displayed at all. Clicking on this label enables the translation mode.

You can also change the language with a dropdown, all GLPI langs should be displayed. A special check mark will displayed in the dropdown where a translation has been saved

On a lang selection where the document doesn’t have a translation yet, we copy the original document and save it.

If a translation already exists, the document content load the translation, still in editable mode.

collaborative features!

These are separated from mandatories because they imply important technical changes

Most of the collaborative features for known editors and tools are based on yjs.

The JS framework allows clients (browsers) to make

• CDRT (conflict management of documents)

• Awareness and presence

The issue is that for achieving real-time exchanges, you need to have a server based on:

• WebSocket (server is a master for documents)

• WebRTC (server is here only to make signaling for peers)

The WebRTC mode is probably not a good choice for GLPI’s kb because:

• Scaling doesn’t work for more than 10 peers

• You need someone to be the master to store the document changes in the GLPI database.

The WebSocket server currently proposed as an example by Yjs provides HTTP callbacks that can be used to store the document in DB.

Another alternative would be to write a WebSocket server directly with PHP.

In both cases, we need to have a daemon running the server.
This significantly complicates the installation of GLPI.

I haven't made up my mind, but we may submit these features set under GLPI-Network subscription, which requires partner expertise. Also, we may ease the thing by working on docker release with the WebSocket server well set up.

This need a bit a research, but in case of GLPI Network Cloud (and maybe more generally for all GLPI instances), we may want to use a single server (one per pool, one for all ?) to avoid performance issues. All the instance connect to a single server, with encrypted data ? How we finally store the data on the MySQL Database, finally WebRTC ?

Self service portal integration

We want tiles mode for the index, with no tree. When an article is displayed, the tree could appear.

TODO

Optional features

TODO to spec