# Editor changes to enable the collaborative mode in Knowledge
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.

### [FIX] web_editor: notify current step when joining a collaborator
- Inserting an embedded view from a module in an automated process happens as
  soon as the first collaborator connect. This commit notifies the step for the
  embedded view during the following collaborators connections (to be sure they
  actually received it).

### [IMP] web_editor: 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 can be a
  better choice than using `observerUnactive` which stops the observer for all
  nodes of the editor, in case a node should never be observed.

### [IMP] web_editor: prevent 'insert' command unwrapping in root
- Modify the 'insert' command of the editor so that it does not unwrap nodes
  when the selection is directly inside the editable ('root'). Unwrapping a
  paragraph in that case would put text nodes as direct childs of the editable,
  which is not desirable with the current implementation.

### [IMP] web_editor: add a hook for historyResetFromSteps
- 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. With the hook, it is now possible to execute a
  specific action as soon as a collaborator is joined.

### [IMP] web_editor: force load collaborative on form view
- The collaborative mode loads lazily with the focus by default. In Knowledge it
  should start as soon as possible, therefore this commit adds an option to do
  so.

### [IMP] web_editor: make mocha tests odoo modules
- Since `web_editor` tests were not odoo modules, it was not possible to import
  dependencies from i.e. `web`. This commit addresses that.

### [IMP] web_editor: 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.

See odoo/enterprise#33483
See odoo/upgrade#4384

# 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