When the `s_nb_column_fixed` class is present on the row, it should not
be possible to change the number of columns in the "Columns" option (the
option is supposed to be hidden).
However, since commit [1], this behavior is broken. It happened because
the "Columns" option needs to always be displayed in order to display
correctly the "Grid" option and this class was therefore ignored.
This commit restores this class behavior by hiding only the widget
changing the number of columns and not the complete "Columns" option, in
order to still be able to toggle between the grid and the normal modes.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
task-3369847
closesodoo/odoo#127144
X-original-commit: 8148521f052268877f36947e0533843a25d17b83
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a URL is entered to add an attachment through the media dialog
a URL attachment is created. If the source material is removed the
attachment will not be reachable anymore.
This commit fetches the data and adds it as an uploaded file when
adding a URL image in website.
If the image binary cannot be fetched by the client (e.g. CORS), the
old approach is used instead.
This commit also adapts test tours which relied on the image's `src` to
verify if the entered URL had been taken into account by making them
rely on the image's `data-original-src` instead.
task-3129360
closesodoo/odoo#118877
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Drag and drop several snippets onto a web page in edit mode to make
the vertical scrollbar appear.
- Drag and drop a popup onto the page.
- Drag and drop snippets into the popup so that the height of the popup
exceeds the height of the viewport.
- Try to scroll the popup downwards by clicking and dragging on the
scrollbar (not using the mouse wheel).
- Bug: the page is scrolled instead of the popup.
Note: This bug occurs in Chrome (not in Firefox).
This issue occurs because two scrollbars are present at the same
location (one for the page and one for the popup) and they overlap each
other. Normally, Bootstrap removes the scrollbar from the body when a
modal is opened, and this behavior was adapted for the #wrapwrap element
with this commit [1]. However, when transitioning to Bootstrap 5, the
code that overrides Bootstrap was removed instead of being adapted (this
was done in this commit [2]).
In later commits [3] and [4], we continued to remove code that updated
the scrollbar based on the opening of a modal because this code was
causing errors due to the fact that it was incomplete without the part
removed by commit [2].
This commit restores the original behavior (before the deletions made by
the aforementioned commits) by restoring the missing code and properly
adapting it to Bootstrap 5.
[1]: https://github.com/odoo/odoo/commit/9cf8b97fe40444b44ebb6e6fb992bc658a087d32
[2]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7
[3]: https://github.com/odoo/odoo/commit/cb7cf77ed080e86f800af61c9a3dc4ad36ad6cfb
[4]: https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2
task-3102275
closesodoo/odoo#126709
X-original-commit: 0e75f1c01ca4fcc3eb483a7256bcf72b2bca39c3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.
The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.
This commit removes such undesirable effect.
task-3347942
closesodoo/odoo#126445
X-original-commit: f0272411f6cab059cc8bc2ceed37d9ce59ffe80c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.
For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.
task-3347942
X-original-commit: 8bad3a3fb00d59498455205e8d286a38adaf1335
Part-of: odoo/odoo#126445
Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.
Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar
The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.
task-3263463
X-original-commit: fb080218def7c47e7b96cf284d613fc03b8325f6
Part-of: odoo/odoo#126445
Previously, copy-pasted tables from other spreadsheet editors did not
keep their style once in our editor. This is simply because the way
style information is embedded in the HTML is not inter-compatible across
editors.
Google Sheets places all the cell's style on <td> tags, which can't be
styled in Odoo 15. This has been fixed by moving all possible style
attributes to a direct <span> children, which is created if necessary.
In Odoo 16 and forward, the styles are left on <td> tags.
Microsoft Excel defines the style in the standard <style> tag (in the
<head> of the HTML), using custom CSS classes on tags. We parse that
<style> and copy it to the style attribute of <td> tags with matching
classes. Those styled <td> tags are later handled as described above.
Libre Office makes use of deprecated <font> tags and its specific
attributes. Those attributes are mapped to equivalent values for the
standard style attribute. It also places eventual <s> and <u> tags as
parents of <font> tags, which means the strike or underline doesn't
inherit the style of the text. We invert those for nicer styling as is
the default in our editor.
Tests have been added for each of those aforementioned Spreadsheet
editors, ensuring we save exactly their style values that are compatible
with the Odoo editor, nothing less and nothing more.
Note that for v15.0, background color of cells is discarded as it is not
supported in our own editor. For v16.0 and on, it is supported and kept.
Task-3255167
closesodoo/odoo#126248
X-original-commit: 8b0f7e32ac73636cd3ce142dd44fe921fcc4c849
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Previously, when copy-pasting HTML with styles on styleable tags, those
styles could still be removed by the editor if they had a default value.
This was supposed to be a way to keep the DOM clean and lighter.
However, styles with default values still serve a purpose when
overriding non-default values inherited by their parents. Therefore,
removing them was a conceptual mistake.
One example in the editor where this purpose can be served is in
tables where spans can override the style of the cell or parent span.
This commit ensures we no longer remove style attributes because of
their default value.
Task-3332955
X-original-commit: 39acbc23929f6004e6cb5fe1059ccabf87799e8c
Part-of: odoo/odoo#126248
This reverts commit [1]. It broke all snippet button colors, making
them invisible. Besides that, the fix seems not obvious to make properly
and would thus require some more testing, thus the need of reverting
this urgently.
There is probably more things to consider when remaking that fix:
- mass_mailing scss code in web_editor should not be a thing. Even if
the comment about variables not being accessible is true, there are
definitely other ways to do it (make them accessible, add those rules
generically with a custom selector and fill that custom selector when
mass_mailing is installed, etc etc)
- More than scss code, we really do not want mass_mailing *CSS* rules
in website pages, especially in that code that generates *many* CSS
rules. Of course web_editor.common.scss contains many things that
should not be there and mass_mailing has probably already a lot of
useless code in the frontend assets... but the goal is to fix those
inconsistencies in the future.
- The fix impacts buttons which are not hovered while the goal seemed to
be to have their hover style disabled...
- The fix impacts buttons which are in o_ccX environments only (?) but
seemed to be about disabling all hover styles.
- Much doubt on the need of an at-root instruction, especially since
it creates a bug in frontend pages without o_mail_wrapper containers
so it probably does not work as intended.
- The fix should probably not be about overriding/duplicating the CSS
rules but rather post-processing the mass_mailing assets to remove all
hover rules. I guess it is even possible to do in JS removing the
:hover CSS rules, at worst by moving all CSS rules to inline <style>
rules or something like that.
Note: the main bug about button text being invisible is apparently from
16.0 and up only. This still reverts the code at its root (15.2) for all
mentioned reasons above.
[1]: https://github.com/odoo/odoo/commit/55aff2dcdf5537e16bdaf01ee68d776510572171
task-3376724
closesodoo/odoo#126116
X-original-commit: a6e861b19002b02e369d6b7c1ed5fe1401e77028
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a margin top on the we-alert to make it prettier.
Otherwise, the alerts are too close to the elements above them.
task-3302433
closesodoo/odoo#120874
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
*: web_editor, website
The goal of this commit is to add the reorder option on the carousel
slides. Because the option is now shared between the "Carousel", the
"Image Gallery" and the "Images Wall" snippets, a common super option
(`GalleryHandler`) has been created to handle this reordering.
task-2930786
closesodoo/odoo#117369
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, website and email editing was very limited on
devices that have a touchscreen. The blocks tab, the we-lists, ... were
unusable.
Example of issues (on a device that has a touchscreen):
- The users cannot drag & drop snippets in the page.
- The users cannot reorder the values of a multiple checkboxes field.
- ...
This commit allows to handle touchscreen events by translating them
into mouse events to allow users to fully use the editor.
opw-3195487
closesodoo/odoo#125976
X-original-commit: 142684dbe7e5c9d5c5fc1baa00b1027367a45213
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Fixes an issue introduced in a forward-port:
https://github.com/odoo/odoo/commit/db0c092973f480f3336a44e5f6868dc5a79f0e3a
The listener was not set on the correct target, `historyStep` event is triggered
on `odooEditor` and not `odooEditor.editable`.
This meant that the FormStatusIndicator was not properly notified and
the `save/discard` button was not visible after an editor `historyStep` on form
views
task-3373603
closesodoo/odoo#126006
X-original-commit: f76585530d7387ff2f44639252829aa4546cea1b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When converting inline svg shapes to images, we checked if the source
ended with ".svg", which is not enough, as it can include query
parameters (eg, .svg?color=red). We now simply check if it includes
".svg" instead.
We also need to make sure we didn't make a clone of the image in an mso
before converting it, as the source wouldn't get converted in the mso.
closesodoo/odoo#125839
X-original-commit: 3e9fa219ce612875aa034d95080f9cca1f972d27
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
After preventing "async" code on link tools update in [1], the
`'link_tools'` test is still failing because of another race condition
issue:
The click on "save" after setting the link style to secondary triggers
an event handler that destroys the link tools widget (see `Wysiwyg` >
`destroyLinkTools()`), leading to calling the `_removeHintClasses()`
method first (both `_addHintClasses()` and `_removeHintClasses()` will
disable the editor observer while adding / removing the link hint
class to prevent their mutations to be recorded...).
Since the observer is inactive, the changes made to the link using the
link tools will not be processed, and the block will not be set as
`.o_dirty`.
As mentioned previously, (and starting from [2]) the editor observer is
inactive (while handling the `.oe_edited_link` class) in order to
prevent recording the mutations... But since [3], the editor had the
ability to prevent some classes (including `.oe_edited_link`) from being
taken into consideration in the `filterMutationRecords()` method...
The goal of this commit is to fix this race condition issue by simply
keeping the observer activated while handling the link hint class...
Remarks:
- These changes are supposed to fix the `link_tools` test that fails on
16.0+, but 15.0 was targeted here since the `.oe_edited_link` class is
ignored by the editor starting from 15.0 and also to prevent any future
issue linked to disabling the observer...
- Adding and removing the `active` class should not affect the history,
since it targets the `linktTools` toolbar button...
[1]: https://github.com/odoo/odoo/pull/109250/commits/f42715fdc89a6a88446c5f88ecec29e6a9c96fe1
[2]: https://github.com/odoo/odoo/pull/90064/commits/26377710a6e3ad61a8c266e9f7c0b8ade98f657d
[3]: https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d
runbot-18747
closesodoo/odoo#125793
X-original-commit: 6a15cbe7b320989866ce143610dbea9ac00caa5e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when using the LinkTools (website, mass_mailing),
if an http URL contained a "@" (ex: https://www.youtube.com/@iRopes),
it got incorrectly recognized as an e-mail URL and the option to open
the link in a new windown was hidden from the UI.
This commit fixes the issue by making the test for e-mail URL slightly
more robust than just checking for the presence of a "@".
task-3356685
opw-3349704
closesodoo/odoo#125742
X-original-commit: 3f1db2397e50b26e2658d270cbb7ce908d5c05cd
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
'replace() argument 1 must be str, not bool' is generated if the user edit a
float or monetary section in the website view.
Steps to Reproduce
- Make debugger mode ON.
- Go to Settings > Translations > Languages.
- Remove the value of the 'Thousands Separator' field from the current user
language.
- Install the 'eCommerce' module.
- Go to the website.
- Go to the shop menu, and click any product from the product list.
- Click on the Edit button and try to edit any float or
monetary section like a product price (eg. change a product price from 750 to
70) and click on the Save button.
And traceback will be generated.
Applying this commit will resolve this issue.
sentry-4148693017
closesodoo/odoo#125684
X-original-commit: b895175cfc487f3db6e53351fd5774303f193698
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In JavaScript, createTextNode() escapes it's contents, so instead of
appending ' ' as text, we should append the character corresponding
to a non-breaking space. Alternative would be to use innerHTML.
odoo-helpdesk ticket 3372476closesodoo/odoo#125640
X-original-commit: 698a1a0c521635a0f8eb98388966e70740492274
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when creating a new record, there is no
`_currentClientId` set in the wysiwyg as there is no collaboration
setup for new records. When the user save the record, there is a call
to `Wysiwyg.resetEditor` but as the
`OdooEditor.collaborationSetClientId` was called before
`Wysiwyg.setupCollaboration`, the `_currentClientId` was not set.
That lead to the `OdooEditor._collabClientId` being undefined, which
lead `OdooEditor.serializeNode` to not serialize the node through the
function `serializeNode`.
So unless the client A reload it's page, if another client (B) open
the same record and synchronize with client A, client A will send it's
history when `get_history_from_snapshot` is triggered but no
`_historySteps` mutations nodes will not be serialized.
So when client B will receive the steps in `historyResetFromSteps`,
the code will crash.
After this commit, the proper order will set the _currentClientId in
time because `collaborationSetClientId` is set after
`setupCollaboration`.
task-3359732
closesodoo/odoo#125599
X-original-commit: 85acd380cab34ca507251c8b232520c76f2a3e58
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
In mobile view, the user was unable to select the table size form table
table picker, making table picker of no use.
After this commit:
In mobile view, the picker will not be visible visible and when the user will
write '/table' then a table of 3x3 dimension will automatically be inserted
without displaying the table picker.
Task id: 3283083
closesodoo/odoo#125480
X-original-commit: a1fa78cdc1c18aa663d09641f81a971e2a5aa683
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, `o_grid_item_image` was not handling videos but image-only.
This commit adds support for `.media_iframe_video` in addition to `img` to
ensure consistent styling across both images and videos within the grid items.
task-3103775
closesodoo/odoo#125075
X-original-commit: b54b34e6c34f435b2923e7b571b2bb2e4e9e0f08
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor, website
Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".
When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.
Upgrade PR: https://github.com/odoo/upgrade/pull/4767
task-3287330
closesodoo/odoo#123873
X-original-commit: c82d01f7532b5b120bedfbc40bf8f2f07d750ed6
Related: odoo/upgrade#4767
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
For background images, modifying options such as "Filter" does not
directly lead to the modification of their corresponding data attributes
in the DOM as those modifications are done at the save request. This
should not be the case. The goal of this commit is to, as for regular
images, modify their corresponding DOM data attributes at the option
update.
Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Replace the background image by one of your own.
- Add a filter to the background image.
- Inspect the Cover snippet.
=> The `data-gl-filter` attribute has not been added in the DOM and you
have to click on "Save" for it to be actually added.
task-3287330
X-original-commit: ed19a1e91a2706b157532778b15d4a581a4da0e2
Part-of: odoo/odoo#123873
Steps to reproduce the bug:
- Add a cover snippet on the website.
- Change the background image with one of your own.
- Save and edit again.
=> Options such as "Filter", "Width" and "Quality" do not appear
anymore.
The problem is that the `src` attribute of the background image is not
correctly updated when initializing the image. This is because the
target used to recover the URL of the background image is the snippet
and not the image itself. This problem is resolved by ensuring that the
argument of the function `getBgImageURL` is the background image. Now
that the `src` attribute is correctly updated, the `computeVisibility`
function of the the `BackgroundOptimize` option works properly and the
options "Filter", "Width" and "Quality" are displayed as wanted.
Note that now, the dataset of the target is filtered with a "white list"
(BACKGROUND_IMAGE_ATTRIBUTES) before being copied in the dataset of
`this.img`. Indeed, if the parallax is set to "None" for example, we do
not want data attributes such as `data-snippet` to be copied in the
dataset of `this.img`.
task-3287330
X-original-commit: 4356917d0d5cfa560794e4a0464c6ebc9a5ff3e7
Part-of: odoo/odoo#123873
Currently, all background shapes of snippets are hidden on mobile,
because most of them don't look great on small screens. This commit
adds a button in the website editor to toggle the shape on mobile.
It remains hidden by default if added on desktop, but displayed by
default if added on mobile.
task-3096132
closesodoo/odoo#116958
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a scrollbar appears in the sidebar, the toolbar could end up being
to wide, making a horizontal scrollbar appear. This commit makes the
toolbar buttons smaller (smaller padding) to avoid this.
closesodoo/odoo#119972
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With this commit, when a user clicks on the font size number in the
editor's toolbar, two things happen:
1. Same as before: the list of recommended sizes opens.
2. The current font size is selected, and the user can type any value
they want. They need to confirm with "Enter" or blur the input to use
a custom value.
task-3167041
Part-of: odoo/odoo#119972
When clicking on an input in the toolbar, the selection was lost and
the commands could not be executed. This restores the latest selection
in the editable in these cases.
Part-of: odoo/odoo#119972
Before this commit, when viewing the content of an html field in
readonly mode, internal links (same origin or relative links) that did
not have the target attribute set to "_blank" would be opened in the
same browser tab. This is undesired, and particularly disturbing when
the content is inside an iframe.
This commit ensures that, in readonly mode, all links are opened
in a new tab.
task-3323602
closesodoo/odoo#125382
X-original-commit: cb84f993bbf38130482c1f50e550bfdf94a60845
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There were two issues with the `getNormalizedCursorPosition`:
1. If the selection was in a non-editable element, the function called
`rightPos` only once, without ensuring that the new position was editable.
-> The current implementation fixes that by making it loop while in a
non-editable element, and also allows the normalized position to use `leftPos`
if the offset of a position is 0.
2. When searching for the deepest leaf to the right, the `DOMPathGenerator` was
allowed to traverse non-editable elements, which is not correct since the result
should always be editable for a normalized position.
-> This is fixed, and the name of the `DOMPathGenerator` utils is updated for
clarity.
task-3280704
closesodoo/odoo#125204
X-original-commit: 3d44028a7722f61900b8669489ff929244b1a4b8
Related: odoo/enterprise#42615
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
The previous iteration (394e4fe) prevented the editor to fix selections in
`contenteditable="false"` elements if they had a `data-oe-protected="true"`
parent. This caused undesirable side-effects such as being able to click in an
embedded view in Knowledge, then type `Backspace` and remove view elements.
The solution implemented in this commit allows the editor to fix such a
selection, only if it is not currently targetting a `<input>` or `<textarea>`
tag, as they are supposedly the only `isContentEditable === false` elements that
are editable by a user in an Odoo view.
task-3280704
X-original-commit: 98767b805fe26883cf851bac4f8d5382a3303eb4
Part-of: odoo/odoo#125204
Prevent custom editor selection of protected tables. The previous iteration
(394e4fe) did not take into account non-collapsed selections.
This iteration does not handle `data-oe-protected="true"` on `table` elements
below the `<table>` tag (i.e. `<tbody>, <tr>, <td>`...), because there is no
need for that currently and it would add further complexity to the code.
task-3280704
X-original-commit: 885d52c9b814d908438e8e424d17c4e4b6e9e731
Part-of: odoo/odoo#125204
Some commands of the editor are able to modify non editable nodes in the editor,
notably those that use the `formatSelection` util. This commit intent is to
prevent such commands to have an effect on `contenteditable="false"` nodes.
Here is the list of impacted methods:
- setTag
- switchDirection
- unlink
- indentList
- toggleList
- applyColor
- every function using `formatSelection`:
- bold
- italic
- underline
- strikeThrough
- setFontSize
In knowledge, `Behaviors` are OWL components that are used in the editor, and
they all have `contenteditable="false"` parts that are managed by OWL. Those
functions could modify those managed nodes and make OWL crash.
task-3280704
X-original-commit: 6d90274e0a21848d704cfd86d7a1d0c5860a9b18
Part-of: odoo/odoo#125204
Most e-mail clients do not support CSS rules for hover effects.
Previously, the mass_mailing application allowed to add buttons with
such effects. This was confusing to some and introduced discrepancies
between the editor preview and the actual e-mails.
This commit removes such hover effects from buttons in the context of
mass mailing.
Task-2936682
closesodoo/odoo#125298
X-original-commit: 55aff2dcdf5537e16bdaf01ee68d776510572171
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The triangle pointing towards an option in the editor is pointing
right and the symbol └ is used to show a sub option in the editor panel.
In a RTL setting, this does not make sense and should be mirrored.
task-3284274
closesodoo/odoo#125153
X-original-commit: a66ff40b28717617e28387b22bdfe9e468242907
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go on a backend HTML field (project task description for instance)
- Write and select some text
- Open the text background color colorpicker
- Hit the "reset" button (the trash icon)
=> The text becomes black (or white in dark mode)
This was because of [1] which indirectly removed the CSS variables
`--black` and `--white`, on which the colorpalette relies.
Note: the test update made by the original commit was lost in the
forward-port because [2] removed the test. It will be restored at some
point thanks to task-3177674.
[1]: https://github.com/odoo/odoo/commit/28444a5792b9929f5250e38f3f864694e22e9370
[2]: https://github.com/odoo/odoo/commit/49297bc7bba75541ca139e6c84e0d3b311765145closesodoo/odoo#125131
X-original-commit: 907c5b6cc24e0b86c219cda1299a87b7901f4e76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website
Commit [1] (and [2]) from the "website in backend" refactoring adapted
the colorpalette to read color information on the right document (as
the right document could now be the one of an iframe which is inside the
editor environment). Unfortunately, it did not do that correctly, making
an inconsistent API relying on the fact the colorpalette should receive
an "editable" param... while a jQuery version "$editable" param of the
same thing already existed. Doing so, it forgot to give that important
"editable" param in two cases:
- For editor toolbar colorpickers (text foreground/background edition)
- For colorpickers inside another UserValueWidget (like we-multi).
This commit solves the inconsistency by removing the need of that
"editable" params and relying on the previously existing "$editable". In
the future, this should be refactored anyway.
Steps to see the issue (A):
- Enter edit mode of one of your website page
- Select some text
- Hit the "reset" (trash button) of the text background colorpicker
=> The text becomes black for no apparent reason.
Steps to see the issue (B):
- Enter edit mode of one of your website page
- Choose a new main color for your website via the theme tab
- Select some text
- Open the colorpicker for the foreground color
- Go to the solid tab and input explicitly the main color of the website
=> The color is hardcoded on the selected text instead of using the
text-o-color-1 class.
=> A test has been added to check this usecase. Making a test for (A)
is less robust as it also requires the backend color names not being
the same as the frontend ones to have the bug (otherwise it works by
chance)... and that will be solved by the next commit of this PR
(another test will be added by that commit too) **.
Note:
- After this commit, following (A), a bug remains: the text receives a
strange padding (as a "inherit" background is actually applied).
Another PR will be made to solve that (see task for more info).
- ** After this commit, (A) done in backend HTML fields instead of a
website page leads to the same bug still. This is because of another
problem that the following commit of this PR will solve.
[1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-3237693
X-original-commit: a30206606423af9e6c8e0313c74fd6200247437e
Part-of: odoo/odoo#125131
Steps to reproduce the problem:
- Drop a popup snippet in a page.
- On another language, click on translate.
- Problem -> It is impossible to translate the popup.
To resolve this problem, the function `_updateInvisibleDOM` is called
even in translation mode. Thanks to this function, the invisible
snippets are now filled in the edit bar and the user has the opportunity
to display them or to hide them.
task-3098517
opw-3268592
opw-3283140
closesodoo/odoo#125078
X-original-commit: c76ff023b84da65d90b7967c91adde4bd777265b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the browser is zoomed, the value of the `border-width` CSS
properties obtained through `getComputedStyle` are impacted by the
zoom. Because of this, entering a "10px" border in a Chrome zoomed at
125% turns it into "9.6px" when leaving the input field.
This commit neutralizes the zoom effect by rounding the value up.
The rounding operation was empirically determined by observing values,
see table below.
When zoomed out this does not always work: e.g. at 50% zoom, a value
of 11px becomes 10px. But zooming out is an unxpected use case, that
situation is therefore not handled by this fix.
Observed values of the border-width property:
Set value => `getComputedStyle`
```
Value Chrome 125% Firefox 120%
1px 0.8px 0.83333px
2px 1.6px 1.66667px
3px 2.4px 2.50000px
4px 4.0px 3.33333px
5px 4.8px 5.00000px
6px 5.6px 5.83333px
7px 6.4px 6.66667px
8px 8.0px 7.50000px
9px 8.8px 8.33333px
10px 9.6px 10.00000px
11px 10.4px 10.83333px
12px 12.0px 11.66667px
```
Steps to reproduce:
- Drop a "Text - Image" block.
- Select the text column.
- Zoom with ctrl+mouse wheel or ctrl-plus.
- Set a 10px border.
- Leave input field.
=> Border option field displayed a different size.
task-3172235
closesodoo/odoo#125107
X-original-commit: 6398b0c75b9e14b7cecb1526fe5a950101d534ad
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit changes the way the we-many2one and we-many2many fields work
so that they check if the model they are attached to has a website_id
field, if so, the data loaded from the model will be that related to the
current website.
After this commit, developers can get rid of the website_id field when
they add a many2X field. The domain will be automatically computed.
task-3316278
closesodoo/odoo#124985
X-original-commit: 78cfcf3b2b3a44ee8e19084639e37277991b969a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
This commit clears the cache of we-many2X widgets. Since [the merge of
the backend into the frontend], the page is not refreshed when the user
goes to modify data in his backend. This means that if the data has been
changed between two editions of a page and the many2X widget has already
made the RPC call, it will not do it again and will still have the old
data. For example with website installed:
- Edit a page of your website
- Add the add to cart button
- Search for "ERP" product
- The product does not exist so save the page
- Create and publish a new product called "ERP"
- Edit the page again
- Search for the product "ERP"
=> It is not present because the query is in the cache which has not
been cleared. If you refresh the page, the product will be found.
This commit fixes this problem by clearing the cache after an edit.
Note that a similar implementation of caching clearing has been done
here: https://github.com/odoo/odoo/commit/3efb726575679f62f9ee2894193323bfe45d7938
[the merge of the backend into the frontend]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3078137
closesodoo/odoo#124908
X-original-commit: ff0cfca420a434e6024654749ea316bbfc5e0772
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
When sanitizing the content of the editor, we sometimes move up too far
and sanitize nodes that are not in the editor. This adds the proper
boundaries required to contain the sanitization.
closesodoo/odoo#124803
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, if in the database there is a document with
`data-last-history-steps` that contains a chain of history rather
then the last id, the wysiwyg will not properly retrieve the last id.
Subsequent call to _ensureCommonHistory will result in a conflict even
when there is no conflict.
task-3366800
closesodoo/odoo#124770
X-original-commit: 3cf0f5a0527d09cc3e6664c5734711ef923c0619
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since commit [1], the text selection must be kept if there was one when
using a snippet option. However, it is not the case when toggling the
grid mode for snippets that have None columns (e.g. Text) or have some
content outside of their row element (e.g. Picture). Indeed, when these
contents are wrapped inside a new column and then in the row, the
selection is lost.
This commit, as done in commit [2], restores the selection after the
content wrapping. It also adds a test checking if the selection is well
kept when toggling the grid mode and going back to normal mode.
[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41
[2]: https://github.com/odoo/odoo/commit/e4d7fbfca85c869d3a04dc517a8ad522cb533a90
task-3324775
closesodoo/odoo#124513
X-original-commit: bcb0e9b83fcb7e3f8a66131a089b88b39f58a2e4
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
When toggling a snippet to grid mode, if it has None columns (e.g. Text)
or if it has contents located outside of the row element (e.g. Picture),
the contents are wrapped inside a column and then put inside the row.
However, after this operation, it is impossible to delete or replace the
text in this newly created column.
As mentioned in commit [1], this happens because there is an unwanted
rollback in the history, which should be prevented by resetting the
nodes unbreakable id (i.e. the `ouid` property).
This commit makes this property reset and therefore allows to delete or
replace the text after the toggle to grid mode.
[1]: https://github.com/odoo/odoo/commit/e33b802b05b41df20e13ebc44bc5b78edae50bb8
task-3324775
X-original-commit: 5bd354802a9aae9575806ad83350e0b002efa2fa
Part-of: odoo/odoo#124513
1. move cache to _get_asset_paths
The `_get_asset_content` cache has many cache key that are related to a
posprocessing of the `_get_asset_paths` result, the heavy part of this
method. Moving the cache to _get_asset_content will have the benefit
to create less duplicates entries in the ormcache as well as less cache
miss.
To simplify even further, the css and js parameters are removed since
they only filter the output of get_paths, the heavy part of globing the
file will be done before that. Anyway, they are both true when called
from _get_asset_content, and the only other call, in
`_get_related_bundle` don't really need to filter them since it is not
a critical part regarding performance, and the funtional result will
stay the same.
The initial orm cache key was using `_get_template_cache_keys`, a little
overkill and possibly creating duplicates entries again. The only
context key needed is website_id for `_get_related_assets`.
Note that it is not really enough, the orm cache key should actually
contain `request.session.get('force_website_id')` as well has
`request.httprequest.host`. This will be addressed latter since a nicer
solution would be to have website_id as a unique parameter computed
earlier.
2. better _get_asset_paths cache key
The orm cache key was simplified in previous point but there is still
one concern, the website_id depends on more parameters than that:
- request.session.get('force_website_id')
- request.httprequest.host
- existing websites
The idea here is to call `get_current_website` instead of using all
parameters that could define the webiste.
In the same spirit of `_get_template_cache_keys` `_assets_path_params`
can be overriden to give extra params that are usefull to list assets
path. Those params are computed before entering the method
`_get_asset_paths`. This may latter put at a higher level latter, in
get_asset_node, to simplify the _generate_asset_nodes_cache key.
3. better assets_node caches key
The main purpose of this part is to improve ormcache containing assets
nodes. The ormcache key contains
- to much context key
- missing session/host/env info
- unwanted boolean options.
- keys leading to the same cache value
The main goal being to reduce the size of the cache keys, decrease the
number of cache entries and improve the cache hit.
This will also make the behaviour more coherent and hopefully less bug
prone because of mismatch in parameters.
The main reason of the orm cache is the slowness of the validation of
the assets. This includes:
- listing files (dedicated orm cache)
- computing version
The cache key was depending on
- `debug`
The only relevant value for debug is "contains assets"
We dont need to differ between debug='', debug='1', debug='test',
and 'debug=assets', 'debug=tests,assets', ...
- `defer_load`, `lazy_load`, `media`
Those values are only useful to generate html node, a leightweight
operations that does not really needs to be in cache. `media` was also
used in the generation but it looks useless if we have the media on the
node. THIS NEEDS TO BE VALIDATED but in any case, since media is not
used to generate the url, it doesn't make sence to use it in the
generation.
The main idea to remove them from the ormcache key is simply to generate
the nodes outide the ormcached values.
-`async_load`
This one is similar to `defer_load` and `lazy_load` but it looks like
it wasn't used anymore. This was simply removed
- context.get('lang')
The only information needed is the direction, rtl or ltr. This means
en and fr languages, despite sharing the same css assets, will duplicate
the ormcache entries.
-`_get_template_cache_keys`
Only the lang and webiste where really relevant in this flow. Other
keys are actually useless in this flow.
Some information used in the generation where not in the orm cache key
- `self.env.user.lang` if there is no lang in the context
- `request.session.get('force_website_id')`
- `request.httprequest.host`
- ...
The proposed solution is to:
- extract any informùation needed from thecontext, request, environment
before entering the ormcache, reduce it to the minimal possible set of
values needed
```
rtl = self.env['res.lang']._lang_get_direction(self.env.context.get('lang') or self.env.user.lang) == 'rtl'
assets_params = self.env['ir.asset']._get_assets_params() # website_id
debug_assets = debug and 'assets' in debug
```
and remove a leightweight part of the logic
```
def _get_asset_nodes(self, bundle, css=True, js=True, debug=False, defer_load=False, lazy_load=False, media=None):
links = self._get_asset_links(bundle, css=css, js=js, debug=debug)
return self._links_to_nodes(links, defer_load=defer_load, lazy_load=lazy_load, media=media)
```
Where _get_asset_links is the cached part, and _links_to_nodes is the
lightweight part generating the nodes based on the `defer_load`, ....
Additionnal notes:
- data-asset-version and data-asset-bundle are removed from the node
since they don't seem to be used anymore since 65d70acdbf
- async_load is removed since there is no occurence of this in the code.
- a small hack is still needed to pass javascript content instead of
links, this is only to manage css compile error and will hopefully be
removed in the future.
- a context key is still in use to generate the bundle, the
`commit_assetsbundle` but it has no impact on content and will hopefully
be removed in the future.
4. Add test for ormcache hit/miss
In this context, hit/miss is about having the same cache key for the
same result. This test demonstrates the current state, were entries are
create in the ormcache only if the key is really different and will lead
to a different result.
5. remove cache invalidation
This cache invalidation is quite agressive since everytime an
assetbundle is updated, all workers will clear their cache.
The concerned cache by this clear_cache is `_generate_asset_nodes_cache`
throug `_get_asset_nodes`.
The cache is ignored, both in dev=xml and debug=assets.
This clear cache was made conditionnal in 553ea82f81 but this does
not solve an issue we can have in production.
Lets imagine a clean solution
- all sources are updated
- all workers are restarted.
The orm caches are all empty, but since the sources
changed, all bundles will be recomputed. This means that every bundle
updated in database with save_attachement will invalidate the cache of
all workers. Rendering a pdf report of any kind using a specific bundle
will invalidate all cache. Starting a debug=assets for the first time
will invalidate all cache, even if the cache is not used in this case.
But for a regenerated bundle we would expect the ormcache to be:
- empty (did not generate the same bundle yet)
- have the same value (concurrent generation of the same bundle)
Having a different value would mean that the bundle was generated with
another version of the sources. In this case it is maybe even better not
to invalidate the cache since it could lead to an invalidation war
between two workers.
The only case where invalidating this cache is useful is when a bundle
changes, Usually if an ir_asset is created, modified, ...
There is still another rare but possible possibility to have a 404 if
the transaction is rollbacked after populating the assets node cache.
In this case, we only need to clear the cache locally in case of
rollback.
Part-of: odoo/odoo#121376
In several places, `convert_inline` uses `classList.toggle('c', true)`
to set classes. This is not a good practice, as it's not clear what the
state of the class is. It's better to use `classList.add('c')` since
this anyway checks whether the class is already present or not.
closesodoo/odoo#124465
X-original-commit: 43afc5a5a30530bc3ede9f0a46249977a7896b5a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Outlook needs explicit dimensions for images, which .img-fluid - by
design - doesn't provide. This puts them in mso conditionals with said
dimensions for Outlook.
X-original-commit: d0949de8ce895b7da5fd128fb5d72d23d5634866
Part-of: odoo/odoo#124465
Soukéina Bojabza