A new method `triggerEvent` has been introduced in order to simplify
event creation. This commit adapt the tests to use that method.
closesodoo/odoo#92653
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when adding a space anywhere in the a text node,
a plain text link gets transformed into a proper link.
It might be an undesired behavior as we could want to manually remove
the link but it will be re-transformed when completing a paragraph.
task-2795019
X-original-commit: 76b5ecc88001ae9decaf3943550ecb4ddb874599
Part-of: odoo/odoo#92653
Ensure the selection in the fonts tags after `applyColor`, otherwise an
undetermined race condition could generate a wrong selection during
multiples call of `_processAndApplyColor` from the color picker.
task-2822221
closesodoo/odoo#92654
X-original-commit: 2b2aba49550cf7c2ba1914f03beef9cbdf60b166
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit
When removing the style of a link in an html_field, the style was
not removed.
After this commit
When removing the style of a link in an html_field, the style is
removed.
task-2857072
closesodoo/odoo#92573
X-original-commit: f98c6b1ffe3a788f2da6536a109efe68cb6c2da7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Rationnals
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
closesodoo/odoo#88134
Task: 2801675
Related: odoo/documentation#2083
Related: odoo/enterprise#26191
Signed-off-by: Julien Castiaux <juc@odoo.com>
Currently only the `*.assets_*` CSS and JS files are considered as
assets. Because of this some assets from `web_studio`, `pos` and
`document_spreadsheet` become available for selection as documents.
This commit replaces the existing blacklist by a check on whether the
URL matches `/web/assets/*`.
Steps to reproduce:
- Install website, web_studio and pos.
- Drop a Text - Image block in the home page.
- Replace the Image.
- Go to the Documents tab.
=> Some JS/CSS/map assets were available for selection.
task-2799866
closesodoo/odoo#89151
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This applies the following heuristic when converting from static columns
to stacking, responsive columns: don't do stack duos of columns where
one is very small and the other very big (eg., col-2 col-10). This
doesn't apply when one of the columns in question is host to a
full-width element (as this could cause ugly sizing).
task-2761098
closesodoo/odoo#87962
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When fixing a row's max-width for responsivity, we need to get the
parent table's width before manipulating it. Failure to do that caused
issues with nested table dimensions. In addition, masonry's maze of
nested tables required some extra styling in order to propagate
alignment.
task-2761098
Part-of: odoo/odoo#87962
Since flexbox is not well supported across e-mail clients, columns were
until now not responsive. This adds support for responsive columns and
a special rendering of them for Outlook so they don't break there.
task-2761098
Part-of: odoo/odoo#87962
Outlook's renderer doesn't understand Bootstrap's styling of buttons we
have a special rendering just for it but its design was suboptimal so
this improves it.
task-2761098
Part-of: odoo/odoo#87962
Outlook doesn't seem to properly read `text-align: inherit` on tables.
This makes them explicit by fetching the alignment of the first ancestor
with an explicit alignment.
task-2761098
Part-of: odoo/odoo#87962
Original 14.0 commit title:
Prevent deadlock on editor save when an option is focused
See [1].
In 15.0, the code worsened... but, by chance, fixed the deadlock bug.
See adapted version via the X-original-commit.
With this master version of the original commit, it is tried to clean
the code a bit... at least around the code that was originally touched,
without starting a big refactoring that is again needed. The deprecated
(and added by mistake) 'edition_will_stopped' and 'edition_was_stopped'
events are now gone.
Hopefully, we will continue to improve that editor hierarchy (and
ultimately converting to OWL?) in future updates.
[1]: https://github.com/odoo/odoo/commit/53a08b3470d7d18488abf93b7ea6551700650460
Related to opw-2767903
closesodoo/odoo#92321
X-original-commit: 483a2d6cac1be3b40a4d1878536baea9e6098ec1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_mass_mailing
Before this commit, some types of buttons were not managed by the
editor, only the primary, secondary and link buttons were supported.
However, if there is another type of btn in the DOM, the editor must be
able to handle it. This commit allows to manage all types of buttons in
the editor. This commit also adds a test so that the bug does not come
back.
Steps to reproduce the fixed bug:
- Drop a block with a <a> with the btn-success class
- Click on the button to edit it
- The link tool part in the editor does not work properly
or
- Drop the newsletter block
- Save and register to the newsletter
- Edit the new "Thanks" button
- The link tool part in the editor does not work properly
opw-2802139
closesodoo/odoo#92325
X-original-commit: 4c68b3e923610e1d573b4bd2b241b2fc5923c412
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] gradient color steps cannot be moved anymore for the text
foreground and background colors.
This was already modified in [2] but it did not address the case of the
color palettes.
This commit makes sure that the mousedown events are not prevented
within the color palettes that are spawned within the toolbar.
Steps to reproduce:
- Drop a "Text - Image" snippet.
- Select the text header line.
- Apply a custom text gradient.
- Add an intermediary color step.
- Try to move the new color step.
=> Color step could not be moved.
[1]: https://github.com/odoo/odoo/commit/57701b2125f7de4fc543bd9c10642a5c11fa32b8
[2]: https://github.com/odoo/odoo/commit/84fd0b0a1bc1d874e7d6d6ff10b4fb6351f5a1af
task-2862233
closesodoo/odoo#92210
X-original-commit: 50342251895d8397788c3f914a2e7abf5439813f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The conversion of background images for mass_mailing doesn't support the
conversion of shapes on them (limitation of html2canvas), and emails
should not contain videos. This removes these options for mass_mailing.
Since the video option was added in place by `website`, this adds an
option in its template so it can be disabled. A similar option was added
for shapes, which depends on images being enabled as well.
task-2856858
closesodoo/odoo#91314
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since background-image elements and their children will be flattened
into images, links within them won't work. This removes the link button
of the editor toolbar, as well as the link and button commands in those
contexts.
task-2856858
Part-of: odoo/odoo#91314
When the user selects across several blocks, the link tools are supposed
to be hidden. This was however broken due to other mechanisms restoring
it after it got hidden.
task-2856858
Part-of: odoo/odoo#91314
Outlook on Windows doesn't support background images. This has the
unfortunate effect that there is now way to write text over an image and
have it be seen on Outlook Windows.
This "flattens" background images by converting them and all their
contents to a `png` image, using `html2canvas`.
Note that _all the contents_ of the element with a background-image are
flattened into an image. This means that any interactive content such as
buttons is unsupported in that context.
task-2856858
Part-of: odoo/odoo#91314
This moves the `html2canvas` library from `point_of_sale` to
`web_editor` so as to be able to use it in `convert_inline`.
`point_of_sale`, depending from `web_editor`, doesn't lose access to the
library.
task-2856858
Part-of: odoo/odoo#91314
In the Firefox browser, when in edit mode, if we click on an input
element, a traceback sometimes appears for no apparent reasons.
The error comes from the fact that when calling the getRangeAt function
on the selection, it sometimes returns a "restricted" range.
Ex: Range { commonAncestorContainer: Restricted, startContainer:
Restricted, startOffset: 0, endContainer: Restricted, endOffset: 0,
collapsed: true }
And so, trying to access a container property (ex: nodetype) will
trigger a "Permission denied to access property "nodetype"" error.
This commit provides a solution to bypass the error. It consists in
redefining the getRangeAt function as the following:
- A range is created by calling the original function that was saved
beforehand
- We check if the range is restricted (the same way as what was done in
this issue: https://github.com/tinymce/tinymce/issues/2194)
- if it is not restricted, the range is simply returned
- otherwise, a new range is created manually, based on the selection
Steps to reproduce the bug:
- Install website
- Drop a form snippet
- Click on the input fields
-> Sometimes a traceback appears
task-2810365
closesodoo/odoo#92097
X-original-commit: c32f6efa956ae9affbb80f84b66118e343268eff
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `hasSearch` variable on `this` was not used anywhere and, if it was,
its semantic was arguable because it was set true as soon as the search
was fired rather than when the search had returned.
I'm taking this opportunity to use async/await as it's *way* better here.
closesodoo/odoo#92014
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When updating the results following a change in the search filter or the
source sources filter (All, Illustrations, ...), the list of media is
regenerated to match the new results. If the user clicks on one media at
the right time after the search is triggered (not too fast but not too
slow either) it is possible to select a media which id is out of sync
with the new state of the widget, thus prompting `_onAttachmentClick` to
provide `undefined` to `_selectAttachment`, which ultimately leads to a
traceback in `_highlightSelected` when accessing either `media.id` or
`attachment.id` depending on the case.
This commit fixes the issue by disabling pointer interactions with
the attachments during the search and rendering update process.
closesodoo/odoo#91985
X-original-commit: bc9db4e5a5559692f461acc7402df969b6236481
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prevent edition on e-commerce products header bar.
Since we cannot save any change done in the header object anyway,
And some edition would trigger error.
We put the all bar in a read-only mode.
task-2745151
X-original-commit: e2f7b8fad76dc816b2f6864340d3740446117cdb
Part-of: odoo/odoo#91840
In some case, when removing format on element with multiple textNode,
the code generate a traceback.
The loops in `toggleFormat` provide a limit element `closestDecorated` to
the `splitAroundUntil` util. However this limit element can be split and
dumped by the format removal. In this case the reference was never encountered
in the DOM by the `splitAroundUntil` code and will bubble all the way to the
`<html>` TAG an try to split it, which generate an error.
We fix it by getting the `closestDecorated` in every loop.
task-2850686
X-original-commit: 2d93345c38f55c276370d0059d562d28320db2fb
Part-of: odoo/odoo#91786
Add some unit test for strikeThrough format.
Those tests reveal some bug in the current formating code.
task-2850686
X-original-commit: 4d8e1dc381d01bb254d2e806a335a40733608f2e
Part-of: odoo/odoo#91786
Before this commit, iframes DOM mutations were not taken into account to
update the tour manager. So in the context of mass_mailing, displaying
the web editor in an iframe, the tours were updated at the right moment
by chance (no mutations for 750ms in the global document and in the
iframe document).
This commit adds an o_iframe class, used to define an iframe that will
render a part of Odoo. An observer is added in the tour service to
monitor the addition of such iframe, and sets an observer on that iframe
to correctly update the tour manager, counting the iframe DOM mutations
for the 750ms delay.
In addition to this observer, the iframe's HTML content is added to the
final document HTML log when a tour crashes (directly between the
<iframe></iframe> for convenience, copy/pasting it in a browser just
ignores what's in between).
Also, when the tour_service is initialized in an o_iframe, it will not
run the tours.
This fix targets the saas-15.3 as it is needed to avoid a race condition
introduced with [1] (introducing a tour which relies on DOM updates
inside the mass mailing iframe). This could be backported if the need
ever rise (it should really have been the case since [2]).
[1]: https://github.com/odoo/odoo/commit/52d32e26c34bef10823582ef5c1f840492b73d7a
[2]: https://github.com/odoo/odoo/commit/971629b9fe40911c3a9765c9fb746ea1c55d3560closesodoo/odoo#91718
X-original-commit: ea35bd06c84b7101224c3b3dd24d1780e13232a9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The mailing html converter uses the `reduce` method of `Array` to
compute column size when converting Bootstrap grids to tables. However,
if that array is empty, given that no initial value was passed, the call
caused a traceback. This is fixed by providing an initial value of zero
as should be expected.
task-2853723
closesodoo/odoo#91683
X-original-commit: 4504d1a880032829fb46dbdeab996bd4e0f9ee97
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection span across two element linked
to odoo field that cannot be styled.
The toolbar should not be visible.
The visibility check was performing a verification
based on the `range.commonAncestorContainer`,
therefore when the selection spanned across multiple element
the common ancestor was higher in the DOM than we wanted, and
the check was not working.
We changed the check to use `selection.anchorNode`
and `selection.focusNode` to ensure the verification works any time.
task-2845346
closesodoo/odoo#91324
X-original-commit: aaa65a49489bad3d25cc3229f0b85e66b8ae855d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit adds some commands that can be used in the html editor.
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.
Task-2674460
Part-of: 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>
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
Part-of: 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>
Before this commit, when hitting enter while not in composition mode,
the editor sometimes removed all the content that was added the previous
composition.
task-4720
closesodoo/odoo#91235
X-original-commit: eddc820417d97b4100a9fb2f9f8934a84bb2417c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, whenever the element that must be deleted by
`deleteBackspace` matches `isMediaElement` or `isNotEditableNode` and
the cursor was in the beginning of a `<p>` with inline content, the
inline content moved to the parent and the `<p>` was deleted.
Which is wrong.
Now, whenever the element that must be deleted by `deleteBackspace`
matches `isMediaElement` or `isNotEditableNode`, no inline content
moves.
Task-2781328
closesodoo/odoo#91233
X-original-commit: 34d06958d053b070b1e07541214899649602873a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Inserting `w.r.t` in the editor transformed it into an url.
This kind of content should not be considered as an url.
task-2795012
closesodoo/odoo#91221
X-original-commit: 75c146fac019b952543403736948b803689bd15b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
When having a checked checklist and clicking on the `strikethrough` gives
traceback.
After this commit:
No traceback is being generated.
Task-2833325
closesodoo/odoo#91114
X-original-commit: 491a79f6f8f734990a2ece3fd1b3f90d09a55c85
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There is some classes that are technical and should not create steps.
Otherwise it compromise the ability to undo/redo or compromise the
ability to detect the dirty elements properly.
This commit prevent thoses classes additions and removals to create
history steps.
task-2836351
closes odoo/odoo#91074
Forward-port-of: #90064
X-original-commit: 41d8a0f246a134e2b5292da4db11e67aa9cfb4ed
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the linktool was disabling the editor observer
until it was destroyed. This messed up with the undo/redo and the
isDirty.
This commit only disable the observer when necessary.
task-2836351
Forward-port-of: #90064
X-original-commit: 57c98f314332bbb4c3225942e1d3748eb131d8b0
Part-of: odoo/odoo#91074
Before this commit, the modifications of the form were not saved if the
user had only clicked on the submit button of the form. Only elements
with the class o_dirty are saved, but since this commit [1], the
observer that adds this class was disabled. The resolution of the bug is
just to remove the fact that the link tool disables the observer that
adds the o_dirty class. This commit also adds a test to make sure that
this bug does not happen again.
Here are the steps to see the bug:
- Go to /contactus page
- Click on edit
- Click on the Submit button
- Change a Form option (eg: Recipient Email, Labels Width, URL, ...)
- Save
Edit again the see that the changes are not saved
[1]: https://github.com/odoo/odoo/commit/c29fe9fa8fc8ff4a5e6f042607ef9b3070d1d339
task-2812722
Forward-port-of: #90064
X-original-commit: 3b45ef633adbeebee4819c30808680644b85c5fc
Part-of: odoo/odoo#91074
*: website
Issue: from 15.0 onwards all image options are available on "/shop".
Details:
On 14.0, images options were removed for unsupported images (we had
a message "Quality Options Unavailable" - see [1]) and images related
options on old editor toolbar were hidden too.
On 14.4 and after [2], images options from the toolbar (crop, width,...)
were moved to a separate 'ImageTools' option and as a consequence, they
don't respect the same visibility rules as 'ImageOptimize'. Other
options were added in XML and they have the same issue, they are visible
as long as the target is an 'img'.
This is a list of options that should be available for unsupported or
partly supported images:
[A] For "t-field" images (shape & quality options are available only if
the image is supported for processing):
- Shape
- Filter
- Width (image width)
- Quality
- Transform (crop)
[B] For external images or images unsupported for processing:
- Description
- Tooltip
- Transform (crop, transform)
- width (CSS width)
- Alignment
- Style
- Padding
- Animate
[C] For illustrations:
- Same as [B]
- Dynamic colors
The goal of this commit is to fix this visibility issue on the JS code
of image options.
[1]: https://github.com/odoo/odoo/commit/84417a174bc2bb76730cc89783d3426a3a3b07d9
[2]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
task-2724946
closesodoo/odoo#90224closesodoo/odoo#90832
X-original-commit: 8e6ca51ed3ebf121acfc7cb1ab992984d0764c90
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In Chrome, it is possible to partially select the contents of a
contenteditable=false element if it has a contenteditable=true child.
This commit prevents breaking such uneditables by expanding the range in a
deleterange to fully contain such elements.
It will be useful with the new blocks introduced with the Knowledge module.
Task-id: 2794990
Part-of: odoo/odoo#86489
Currently, the focus is forced on this.editable when using a powerbox command.
Knowledge /template will introduce blocks which are contentEditable=False, but
contains sub-elements with contentEditable=True, which are allowed to use
powerbox commands. Those sub-elements have another editable context as
this.editable. As such, forcing a refocus on this.editable will remove the
caret from the sub-element.
Avoid doing the refocus if the currently focused element is a child of
this.editable and is contentEditable=true.
Task-id: 2794990
Part-of: odoo/odoo#86489
Prevents the user to remove the last child (if it is an empty block) of an
editable, in order to avoid the case where the user can add text nodes directly
in a block where it should not be possible (i.e. directly under this.editable).
Replaces any empty block other than `<P>` by an empty `<P>` which is the default
block for the editor.
Task-id: 2794990
Part-of: odoo/odoo#86489
Add the attribute 'contenteditable' to the frozen list for html elements of
DOMPurify, so that this attribute is not sanitized in collaborative mode when
using _safeSetAttribute.
Task-id: 2794990
Part-of: odoo/odoo#86489
When fakeEl is empty, firstChild and lastChild both equal null.
task-2842638
closesodoo/odoo#90523
X-original-commit: 626caa89cf290f226b19dfa73bc4ab41c7f95fc0
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Avoid living `<li>` tags without a `<ul>` or `<ol>` parent
in the editable html.
task-2842638
closesodoo/odoo#90518
X-original-commit: c6660d9ae1c931da3ad442b30f610db463ede894
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Nicolas Bayet