# Implement the collaborative mode in Knowledge

/!\ This PR does not enable the collaborative mode in Knowledge, because
some collaborative errors are in the process of being fixed in the `web_editor`
module. see task: 3217965, as well as the traceback `InvalidStateError, failed
to execute setRemoteDescription on RTCPeerConnection`, which will be
investigated soon. In the meantime, the `collaborative` option of the html_field
should stay `false`, because there is a risk of data loss as long as those bugs
are present.

Here are the necessary changes to make it possible to enable the collaborative 
mode in Knowledge. Knowledge commands introduce a new kind of editor blocks:
`Behaviors`, which are OWL `Component` which need to be mounted. This mounting
is asynchronous and this has to be supported, while not all nodes are observed 
by the editor, meaning that parts of a `Behavior` can be collaborative while 
others may not.

The following is a brief introduction for every commit in this PR, check them
out individually for more detail.

### [MOV] knowledge: move the abstract_behavior wysiwyg template
- Move the abstract_behavior wysiwyg template with other similar templates in
  `knowledge_editor.xml`

### [IMP] knowledge: remove duplicate editor getter
- The `get editor` was unnecessarily overrided with the same implementation.

### [IMP] knowledge: fully implement oeProtected and oeTransientContent
- Those attributes will allow a fine control on which nodes are NOT observed by
the editor (oeProtected="true"), and which nodes are NOT saved/serialized
for collaboration by the editor (oeTransientContent="true"). It allows
`Behavior` OWL lifecycle steps (like `onMounted`, `onPatched`) to not use the
`observerUnactive` method to make changes in the editor, which was hazardous as
some steps are asynchronous (so there could be a lock active during an
asynchronous task).
- Every `Behavior` is now `oeProtected="true"` by default, and can specify which
  of its sub-nodes are `oeProtected="false"` (meaning they should be observed by
  the editor and collaborative).
- An usage example of `oeTransientContent="true"` is an embedded view, as its
  content is generated dynamically each time, and in the context of the current
  user, meaning that sharing those nodes in collaboration or saving them in the
  database does not make sense.
- As OWL `mount` is asynchronous, this commit introduces a way to "pre-render"
  `Behaviors` in a `d-none` div aside the editable, so that the `Behavior` fully
  rendered can be inserted at once in the editable. (this is to avoid generating
  multiple `add` mutations during the rendering process, which could be
  decoupled in collaboration, breaking the rendering logic.)

### [IMP] knowledge: avoid OWL instructions in unprotected Behavior nodes
- OWL template instructions can add empty text nodes in the DOM after rendering
  (i.e `t-if`, `t-else`). If those nodes are observed by the editor (under a
  `oeProtected="false"` parent), this means that functionnally identical content
  could have technical differences and not be considered the same by the editor.
  As such, the current solution is to avoid those instructions under a
  `oeProtected="false"` parent and handle conditional content manually in the
  `Component`.

### [IMP] knowledge: make articles structures collaborative
- The /index command creates a block with content generated by OWL, so we are
  exactly in the case mentionned in the previous commit. That content should
  thus be handled outside of the OWL template. And this requirement is reinforced
  by the fact that we want to let the editor override those rendered nodes from
  a collaborator mutation (external step). (OWL crashes if its rendered nodes
  are modified without its consent).
- Therefore this commit introduces the necessary changes for that command to
  work properly in collaboration.

### [IMP] knowledge: setup embedded view intersectionObserver in editable
- The intersection observer for embedded views does not catch the moment when a
  "pre-rendered" node is moved from the `d-none` rendering zone to the editable.
  Therefore it is only set up once in the editable, with the usage of a
  temporary mutation observer.

### [IMP] knowledge: insert external embedded views in collaboration
- When joining an html_field in collaborative mode, there is no way to know if
  there are connected collaborators before actually making said connection. This
  is a problem when we want to automate the insertion of an embedded view from
  another module in Knowledge.
- This commit uses the hook introduced in `web_editor` to attempt the insertion
  a second time if the content received from the database where the embedded
  view was inserted the first time is reset from the currently active
  collaborator when the current user joins him in collaboration
  (`onHistoryResetFromSteps`).

### [IMP] knowledge: buffer external steps during Component rendering
- In a collaboration, when applying a step requiring a custom OWL `mount`
  (which is asynchronous), further external steps should be buffered while the
  rendering is done, in case those following external steps should concern
  "rendered" nodes which are not yet present in the editor. Once all nodes are
  rendered and present in the editor, further steps can be applied safely.
- This commit uses the option introduced in `web_editor` to provide a promise
  when it detects that a step added a new `Behavior` anchor node, and that
  promise will be resolved when the `Behavior` is fully rendered and ready.

See odoo/odoo#104680
See odoo/upgrade#4384