In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.

This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.

This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.

As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.

Move specific
===========

Due to business decisions knowledge is moved to enterprise repository. As
some other moves are planned, notably coupon or the complete responsible UI
and support that are coming to community Odoo feels like knowledge belongs
to enterprise applications.

Planned move from enterprise to community are

  * mass mailing themes;
  * mobile UI;
  * complete coupon and loyalty cards support;
  * spreadsheet library;

For any questions please refer to decision makers.

This merge contains the initial merge and all fix or stable improvements done
since the merge. This is done to keep the history as it is still quite fresh. Keeping
the history is doable.

This merge contains notably

  * Original merge https://github.com/odoo/odoo/pull/82315
  * Fix https://github.com/odoo/odoo/pull/91283
  * Fix https://github.com/odoo/odoo/pull/91313
  * Fix https://github.com/odoo/odoo/pull/91343
  * Partial https://github.com/odoo/odoo/commit/fc79bd1e0e01e8ffe4a6cf401392a7016d658a7d#diff-98e4331831cbb77d22012a34808e294bcb506e873b53d44a75bdd79f88230e68
  * Fix https://github.com/odoo/odoo/pull/91385
  * Partial https://github.com/odoo/odoo/commit/ac66c26097070e0fb9589895a4cc7ac9e6159246
  * Partial https://github.com/odoo/odoo/commit/6cf8db906f595a0e579f9b0fd93e789c54c17fd4
  * Merge https://github.com/odoo/odoo/pull/91430
  * Partial https://github.com/odoo/odoo/commit/89c8abce537c5c8a63e5be20f53a7d49deeb1137
  * Fix https://github.com/odoo/odoo/pull/92850
  * Fix https://github.com/odoo/odoo/pull/92851
  * Merge https://github.com/odoo/odoo/pull/91969
  * Fix https://github.com/odoo/odoo/pull/92863
  * Fix https://github.com/odoo/odoo/pull/93003
  * Fix https://github.com/odoo/odoo/pull/93398
  * Merge https://github.com/odoo/odoo/pull/93690
  * Merge https://github.com/odoo/odoo/pull/93215
  * Fix https://github.com/odoo/odoo/pull/93597
  * Fix https://github.com/odoo/odoo/pull/94890
  * Partial https://github.com/odoo/odoo/commit/1fcd098af5fa18e848c66bb83bdceb6ba0308512
  * Partial https://github.com/odoo/odoo/commit/2d44f2792dec0b2f205475a22dbedc97e9c54a64
  * Merge https://github.com/odoo/odoo/pull/94836

Task-2900765

Purpose
=======

Allow companies to centralize all their knowledge in a specific place they own.
Create wiki-like pages to structure the information and make it easily
available. Leverage those later on while working in the back-end.


Specifications
==============

An article is mainly composed of a title and a body. The later is an html field
that can contain text, images, link to other articles or records from other
models, templates, etc..

Articles will be classified in 4 categories:

- *Workspace:* 
The articles are available for each internal users in read or write access.
Only internal users can create, read, modify and delete knowledge articles.

- *Private:* 
The articles are only available for the owner. Only internal users
can set an article as private. A private article can be shared to external users
in read access only. If the article is shared with internal users, see Shared
section.

- *Shared:* 
The articles are not available for any user except the ones that have been
added as members on it. For the current user, this section contains all the
private article the user shared with someone and all the other's private 
articles shared with me.

- *Favorite:* (Additional category for UX)
Articles can be set as favorite and are user specific. Any identified user can
set an article in favorite, as long as the user has access to it. Public users
cannot add articles to favorites. Favorites can be reordered and this ordering
is user specific.

An article can have a parent and multiple children. Each parent and each
children is also an article. Root articles are the highest parent in the 
hierarchy and are considered as the *Subject* (aka Topic) of their whole 
hierarchy. There is no limit on how many levels there are in the hierarchy.

In the 3 first categories, the articles are listed starting for the root 
article. The child articles are listed below their parents only if the user has
access to them. It can be that a user has access to an article that is not 
listed in knowledge main view because that user has no access to the parent 
article. More information about access below.

Categories are based on the root article. If a children is private, because only
accessible by 1 user, and its parent is accessible by everyone, the children
will be listed in Workspace section.

Technical notes

The following domains apply to assign root articles in the different categories:
- Private: permission 'none', only member = uid
- Shared: permission 'none', more than one member with read/write access
- Workspace: other
In addition, the UX category
- Favorite: is_user_favorite = True (can contain articles from any category)


Home View (backend)
===================

The main knowledge view is a tweaked form view that displays all the accessible
root articles and their accessible children in a side panel hierarchic tree. 
This side panel allow quick access to each articles without having to navigate
back to a list or kanban view. This form view mainly displays the title and the
body but also integrate custom buttons to manage and search the articles.
All those buttons + the side panel are detailed below.

This "Home" view is loading displaying the first favorite article of the
user. If the user has no favorite, it falls back to the first root article of
Workspace section.

The default view mode depends on the user access:
- If user can read: readonly mode
- If user can write: edit mode

Search View
-----------

The standard list view will be used as an advanced search to find an article
that cannot be found easily via the command palette (ctrl+K). All the searching
options remains standard (search / filter / group by). Selecting an article in
that view will redirect to the home view (displaying the selected article).

Side Panel
----------

- *Reorder and hierarchy:*
From the side panel, drag and dropping an article can resequence the articles 
between them and/or change the parent of the moved article.

Note on reordering:
Each parent have its own sequence for its children. So the sequence is not
common for each articles in the database, but specific for the children of a
same parent. The resequencing is done among the children of the same parent.
If some articles has no parent, there are considered as the root articles and
all root articles have their own sequence too.

- *Create:*
From the hierarchy tree, the user can directly create an article using the '+' 
signs:
    - as root of Workspace or Private section
    - as a child of a target article.

- *Fold/Unfold:*
To speed up Home page loading: only first level is loaded + the articles that
user already unfolded in the past. The app keeps track of unfolded articles per
user (using Local Storage).

- *Icon:*
Each article has an icon associated with it. The user can click on the icon to
change it.

- *Search an article:*
This button opens the command palette to perform a search on articles.
More detail on this in the Advanced Feature section (below).

Article header and Button Menu
------------------------------

- *Breadcrumb:*
Located on the top left of the main view, the breadcrumb can be used to edit the 
article title.

- *Favorite:*
Next to the title, a star button can be used to add/remove the article to/from
the favorite.

- *Create:*
Creates a new private root article.

- *Share:*
Opens the permission panel. This is where the user can configure the access on
the article or, if user has no write access, see what are the access rules on the
article. More detail on this panel in the Access Rules section (below).

- *Chatter:*
Toggle the chatter On/Off at the right of the article view.
There users can:
    - Send messages and log notes
    - Schedule activities
    - Follow an article

The following buttons can found in the kebab menu, in which we can also find
who created or edited the article last and when.

- *Move To:*
Opens a modal to select the parent under which the current article should be
moved. The article will be placed as the last children of the selected parent.

- *Lock:*
When activated, prevents all edition of the article content (body and title) 
until it is unlocked. (Purpose: avoid accidental edits)

- *Duplicate:*
Creates a copy of the current article, under the same parent, but does not copy
the children articles. The new created article will have the same access rules
as the original article.

- *Archive:*
Will archive the current article and all its children. Archived articles can be
retrieved using the Advanced Search (see below for detail) with "Archived" 
filter.

- *Full Width:*
By default, the article is centered in the view, to make it easier to read.
If needed, the can activate the full width. This will make the article body take
full width available on the article view. This option impacts the rendering of
article, also in the frontend view. More detail on the Frontend View below.

Body
----

The body is composed of an html field that can be edited using the Odoo Editor
and all its capabilities. Some new commands have been added to enrich the
editor: /template - /file - /article (More details in Advanced Features section)

At the top of the article body, the article icon and cover can be added using
their respective "Add" buttons.

- *Icon:*
Can be modified by simply clicking on it.

- *Cover:*
Can be modified using the "Pen" icon at the top left of the cover,
and deleted using the "Bin" icon at the top right.


Frontend View
=============

The frontend view is basically a simpler version of the backend view where users
can only read the article and add them to their favorites (if user is 
identified). 

The frontend view is composed of the side panel in the left, the article title 
and favorite button on the top and the main body view.

From the side panel, the user can navigate to each available article, reorganize
them favorites and filter the articles using the search bar.

From the main body view, the user can consult the content of the article and
download eventual attached files from the '/file' sections.


Access Rules
============

Basics
------

The access is defined depending on two criteria:
- The Internal Permission
- The article members and their permission

Both have 3 level of permission:
- none (No Access)
- read
- write

The internal Permission is the base permission for internal users. By default,
all internal users can write on the article, unless the permission have been
downgraded to 'Read' or 'No access'.

An internal user however can be added as a member of the article with a
specific permission that applies only for them. This member permission takes the
priority on the internal permission.
The internal users will always be redirected to the backend view when they want
to consult an article.

By default, external users (portal or public users) cannot have access to the
articles, unless they have been added as member. They can only be invited with
read acces on the articles. 
External users will always be redirected to the frontend view when they want to
consult an article they have access to.

An administrator (group_system) will always have write access, even if 
permissions tell the contrary. However, only the articles they have the
permission to see or write on will be listed in the side panel. They can find
the other articles in the Advanced Search view.

Only the users with write access can edit the article body and title, reorder or
change the parents and children, invite members and edit the access rules of the
article.

- *Constraint:*
An article should always have at least one user having write access on it.

- *Lock mechanism:*
Only users with write access can lock or unlock the article.
when an article is locked, the title and body of the article cannot be edited,
even by a user with write access on it.

Access Inheritance
------------------

By default, a child article inherit the access rules from its parent.
That means that access rules can be defined on the root article and those rules
will apply for each descendant article (children and their own children, etc.).

However, a child article can have specific rules that will apply only on itself
(+ its descendant):

- *Synchronized:*
That can be done by adding a member on that article, or by upgrading any of the
permission based on its parent(s). In that case, the article access rules still
depend on its parent(s). If an additional member is added on the parent, 
the child article will still inherit that member. The rules that applies 
specifically on the child article have the priority on the inherited rules.

- *Detached:*
When an access rule is downgraded in a child article that initially depends on
parent's access rules, the article access rules are detached from the parent's 
access rules. All the access rules that applied on the parent are copied on the
child article and that article is flagged as detached. The children of that 
article will, for now on, only depend on it, and not on higher parents anymore.

An detached article can be resyncronized with its parent. In that case, all the
specific access rules that do not apply on its parent will be removed. The child
article will still keep its specific upgraded access rules but will, once again,
depends on its parent.

Share Modal (and access rules application)
------------------------------------------

The share modal (or permission panel) is where the access rules of an article
can be configured.

From there, a user with write access can:

- *Invite new members:*
A modal opens and the user can:
- add existing partners or type email addresses and create new partners
- select the permission that should apply on all selected partners.

If there are external users among the selected partners, only the read access
can be used. That means that if the user select:
- Write permission: the read permission will be given to that partner.
- No Access: The partner will not be added the members.

An invitation email is sent to the invited partner. 
If the partner is already registered (has an active user), them can directly
access the article with the link provided in the email. They may need to log in
first.

If a partner is not yet registered (have no user), when using the link provided
in the email, them will be asked to register first, and will be afterwards
redirected to the article.

- *Modify the Internal Permission:*
The user can select the new permission to set for all internal users.

    - Special use cases:
        - If the user sets internal permission != write, the user will be added as 
member with write access. The purpose is to let the user continue to edit the 
article.
        - When downgrading internal permission on a child article (that depends on its
parent), detach it from parent in terms of access rules.
        - when upgrading internal permission on a child article, just set the
permission. The article is not detached from parent, but the article will use
its own internal permission to compute the user accesses.

- *Modify a member's permission:*
The user can select the new permission to set on the target member. The user can
also remove a member.

    - Special use cases:
        - When downgrading or removing a member based on parent: Detach the article 
from it's parent
        - When upgrading a member based on parent: add a new member with the selected 
permission.

Website Published (Access for public users)
-------------------------------------------

When the Website App is installed, users have the possibility to publish the
articles. When an article is published, everyone can read the article.

- *Internal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in backend view.

- *Portal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in frontend view.

- *Public users* can read a published article. They can access it by using the
article link from the frontend view.


Advanced Features
=================

Search and Advanced Search
--------------------------

- *Command Palette:*
Searching is done through the command palette. Just as we have '#' for channels,
'/' for menus and '@' for users, '?' has been added for articles.

The command palet is accessible by either
- Hitting CTRL+K (and then adding ? to search among articles)
- Clicking on the fa-book icon of the chatter, which already
adds the '?' so that one can start searching straight away.
- Clicking on the "Search An Article" button (in the side panel)
while reading another article, where the '?' is automatically added too)

The search result are ordered as followed:
My Favorites > Most Favorites > the rest.

The results display the article name + the subject (highest parent name).

If no results are found and user have write access, them can create a new 
(private) article with the search query as title.

- *Advanced Search:*
If the user is not happy with the search results, them can do an 
"Advanced Search", which sends me towards a normal Odoo list view where I can 
search, filter, groupby, ...


Editor Commands
---------------

Some new editor commands have been added:

- */article:*
This command is available on every html field using the Odoo Editor.
This command allows to add a direct link to the selected knowledge article.

- */file:*
This command is only available in the Knowledge App.
This command allows to add a file (or an image) download button inside the
body. The user can choose a file to add from its own file directory or an
existing attachment already present in the database.

- */template:*
This command is only available in the Knowledge App.
This command allows the user to create a block where them can write and lay out
content destined to be reused by the readers of the article. The lasts will be 
able to copy and paste it to send it as message or use it as a description on 
other records.
No /command can be added inside a template.


Technical notes:
/file and /template commands can be activated in other modules by adding
knowledge_commands = True on the html field in the view where they should 
be activated.


Technical considerations
========================

Access Rules Computation
------------------------

Articles access rules are based on inheritance from parent articles. Purpose is
to avoid making copies of all member rules on each article in the hierarchy. 
This allows to lower database storage. The counter part is that the computation
of user accesses is made more complex. Instead of simply reading the article
internal permission and members permissions on the article, access is computed
based on each parent above the article.

To speed up batch compute, user permissions are computed directly with recursive
SQL queries. They collect all the needed information for multiple users (based 
on their partner) and multiple articles.

Ordering on is_user_favourite
-----------------------------

To allow ordering on is_user_favourite computed field, the search method have
been overridden to add the favorite articles of the current user to the search
result. This is used in the advanced search view but will also be used in
the ctrl+K command.

Sequences and resequencing
--------------------------

Sequences in knowledge article does not respect the conventional sequencing
(one sequence for all the records of the model). Instead, the sequence is
specific for all children of same parents. Resequence had to be overridden to
take that into account and only resequence the children of same parent, and not
the entire table. Moving an article in the middle of a 'folder' should not
impact the other folders but only the children of that target folder.

Breadcrumb
----------

On the form view, the breadcrumb will be located in the control panel.
For the knowledge module, we needed a headless layout. In the mockup,
the breadcrumb has to be placed within the form sheet.

Unfortunately, the breadcumb is a owl component and its logic is
encapsulated in a function which makes it not editable.

To avoid having to update the core, we will render a custom breadcumb
that will be generated based on the `breadcrumb` parameter passed to the
`init` function of the form view.

Task-2674460
Might be inspired from odoo/odoo#82315

Co-Authored-By: Damien Abeloos <abd@odoo.com>
Co-Authored-By: Julien Banken <jbn@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Fabio Barbero <faba@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Aurelien Warnong <awa@odoo.com>

Forward-Port-Of: odoo/enterprise#29107