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>
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>
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
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
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>
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>
This is an attempt at fixing a runbot race condition.
It was executed succesfully without any error on Multi build around
200 times on runbot.
Since [1] the reset button could be clicked before the HTML editor was
reloaded.
The `MutationObserver` in `tour_service.js` is debounced. Because of
this the states used to detect tour steps triggers might differ between
executions.
With the Reset button of the HTML editor not being hidden in the
rendered template, it might be detected before it gets hidden during
the `start` of `ace.js`.
This commit makes sure the the editor is both closed then reopened with
the Reset button visible before clicking on it, and also makes sure the
Reset button is not visible by default upon rendering.
[1]: https://github.com/odoo/odoo/commit/d20468c3463927a54c34688769a22b3949c5c465
runbot-3674
closesodoo/odoo#90453
X-original-commit: b35f127c86c1d271a76dae7186a96190e8558c73
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
After selecting an image and clicking on crop button, crop widget displays and
vanish immediately and crop does not work. After clicking on screen, it raises
an error (Cannot read properties of null (reading 'removeChild').
After this commit:
The crop button works fine without raising any traceback.
Task-2804892
X-original-commit: 1ab1c15386f778b04eb78f26b1e0934f3329c6af
Part-of: odoo/odoo#90401
This introduces a "direction" option on the editor to set the text
direction of the editor (passed by Odoo based on the localization), and
a Powerbox command to switch said direction on a given block. This
allows users to mix several text directions within the same text, eg.
when quoting Hebrew in an English text.
task-2814004
X-original-commit: 693df325588ccaf6385c9f610709f687ccdf61a8
Part-of: odoo/odoo#90247
The isDirty method of the wysiwyg was not very accurate
and was most of the time returning true
even if no changes were done in the editor.
task-2692125
closesodoo/odoo#90200
X-original-commit: bab673488e185ddd7792aedecc3870663290fed3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
* web_editor
Prior to this commit, removing a snippet while its widget was still
active could lead to slow removal as editors would be created for its
inner content.
Stopping a widget before removing it is good practice as it will clear
the DOM from any content it may leave behind and will prevent snippet
editor to be created for its dynamic inner content.
As an example, the `Products` snippet had SnippetEditors being created
for its product cards, which could lead to slow removal especially
in later versions of Odoo. E.g. in 14.0, because ImageTools were
introduced.
Closes#85464
task-2781418
closesodoo/odoo#90100
X-original-commit: ca1359e0f40b94b93eb8cfd6834a05796f64c675
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Ensure the current editor value is set in the Odoo FieldHtml during
`commitChanges` so it can be used by the `urgentSave` when needed.
closesodoo/odoo#89916
X-original-commit: 43dfc8140760497d9f0352897d71ad49b12fd6e5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The command `/image` used by portal users (in a forum post for example)
throws an access error. This fix removes this command for portal users
until master. In master, the command is reintroduced [here].
Indeed, before the new editor in v15, those restricted users could
insert an image as we were using an "in place" image upload dialog
from summernote resulting in simple base64 image added in the image tag.
This allowed to add image without creating an attachment.
But with the new editor, there is no such base64 image upload, and it
would be too tedious / risky to introduce one in stable.
[here]: https://github.com/odoo/odoo/pull/82612
opw-2648770
task-2811325
X-original-commit: e453d4c119a69f285d9a014babe485492bbe9c40
Part-of: odoo/odoo#89890
Disable checklist and stars when the html field attribute readonly is
true.
task-2832281
closesodoo/odoo#89845
X-original-commit: 7c87495d34713cf4ea82cfeb376097d67862eb2a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Commit [1] introduced a way to use pre-configured gradient that included
a change to the util method _areCSSValuesEqual.
Commit [2] added lines of code to compare shadows but unfortunately
broke commit [1].
The changes of commit 2 left a lots of elements in the body of the
document.
Steps to reproduce:
- Install base database
- Find HTML field (e.g. Login as admin => preference => Email signature)
- Select text and click on Text Color
- Click on gradient then custom gradients
- Move the slider around
- Inspect the body element
- Lots of divs are there
[1]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2b
[2]: https://github.com/odoo/odoo/commit/212d8ec10bb48e8fd7de3d3ff7660447b968c62aclosesodoo/odoo#89785
X-original-commit: 043dea4d8a46465f2faf3d6b93847dc2eabfde8c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when the selection was not in the editable at the time
of calling the LinkTool, a link was created outside the editable, which
is wrong.
Task-2696969
closesodoo/odoo#89772
X-original-commit: 78decd6a75d6abf06177747f350871fefc84fd5a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There are cases that seems to reset the editor content but shouldn't.
This commit:
- provide a dialog to allow the user to save his content before being
lost forever
- reset only if the record content has changed
task-2810115
closesodoo/odoo#89625
X-original-commit: e812e923ffe040e734e4d913eceaae396adf6c3d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Ensure the `onChange()` callback is called
after each history steps in the editor.
Call the `_doAction()` directly, to avoid using the
disabled `_doDebouncedAction()`.
task-2760436
closesodoo/odoo#89339
X-original-commit: 18eaabcb4dab4682e3a94e16dbe66ff3c6f35a77
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
This commit fixes a symptom of a more general problem which will be
investigated later.
Steps to reproduce:
- Go to apps
- Install website
- Follow the configurator flow up to entering edit mode
- Go to the 3rd tab of the editor panel
- Change the "background" color of the third color combination and
choose one of the gray colors
- Go to the backend => SCSS compilation crash
Basically, "frontend" color (complex) maps are available in all assets
(via the variables parts that all assets have in common). The original
plan was for them to be used in shared "frontend" environment like the
mass_mailing application. The web_editor SCSS generation uses those
variables to customize bootstrap variables... but it conflicts with the
backend also customizing those. That's why there is code to "clean" what
the web_editor app does when you are in the backend environment. The
problem after the mentioned steps is that this "cleaning" is done too
soon: gray colors are removed from maps to not alter backend grays and
a web_editor css rules wants to access those gray values if configured
to be used as mentioned in the steps to reproduce. This commit basically
reviews what was done at [1].
In master it should be reviewed so that the web_editor probably does not
touch any bootstrap variable when in a backend environment and/or some
code should simply be moved to the website app only. See also
web_editor.common.scss where many CSS rules depends on this and are
available in the backend... while they probably should not (like the one
which tried to use that gray value like explained above). But in stable,
we wanted to avoid changing too many things.
However, this was only a symptom of the problem: the fact that some
CSS rules should not be loaded in the backend is not a critical issue.
The real problem is that those CSS rules were breaking because the
backend assets are actually generated using website-specific assets
while the backend is supposed to be website-independant. That's probably
a bug introduced with the new assets system (ir.asset) which would
explain why this bug cannot be reproduced in 14.0. This will be looked
into in a future update. Also, this could be backported later if judged
necessary or if a traceback is actually found.
Note: the forward-ported commit also includes the fix made at [2].
[1]: https://github.com/odoo/odoo/commit/70f35620babdfdf43e2c603efbf37f2cf7399240
[2]: https://github.com/odoo/odoo/commit/0fef8cfb5dc2fc0a2d9e0352ea6a473a0d7b9dbc
opw-2735123
closesodoo/odoo#88968
X-original-commit: c58cee82939edb0ae0a95b5141d5c3b85dc404c0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the tab labels of the colorpickers were too long
in some languages (e.g. German) making them overflow and making the UI
impossible to use in some cases. Indeed, the bug was different depending
on where the colorpicker was:
- In the text tools, the colorpicker overflew the whole panel, making it
impossible to use
- In the snippet options, the colorpicker buttons were cropped without
ellipsis making them impossible to read
- In the backend, as the toolbar is floating, it was ok but the code was
quite dependent of the other colorpicker-related scss
This commit solves those problems and unifies the way colorpickers look
independently of their position (always full width, the buttons fill the
available space, if the buttons are too long they are cropped with
ellipsis, they have a title on hover and are always aligned on the
left of the tabs area).
opw-2786778
closesodoo/odoo#88844
X-original-commit: a4755218f239e5c00e9c6a23321654a3ab029470
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
On mass_mailing, the button does not have a specifc width.
Defining a width to the button makes the styling more predictible.
Task-2781002
closesodoo/odoo#88679
X-original-commit: 5f5b806559e06aad7f67b66c8da96d15516fcd52
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Nicolas Bayet