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
The `_wrap` util function of `convert_inline` was not checking if
`className` and `style` were defined before adding them to the wrapper
element, leading to things like `<div class="undefined">element</div>`.
X-original-commit: 9fd6e069d07c3f7964511af7289d95c970d11b3e
Part-of: odoo/odoo#124465
Firefox doesn't seem to do well with sibling tables, so we need to
wrap them each in separate rows.
X-original-commit: 625a6545ee9e64a90e36b676c5b7b9a3c8d42418
Part-of: odoo/odoo#124465
Bootstrap rows have negative left and right margins, which are not
supported by GMail and Outlook. Sometimes we use padding on columns to
undo the negative margins of their child rows. This corrects these.
X-original-commit: dc7c7330b4b7a1c17c3b736aa60c21882a455a31
Part-of: odoo/odoo#124465
Before this commit, the line-height of the body was not properly
inherited where it should. It is defined as a CSS variable and its value
was incorrectly retrieved (if the value is 1.5 and the font-size is
10px, `getComputedStyle` returns 15px instead of 1.5). Other properties
related to fonts were likewise improperly inherited.
X-original-commit: 12ae698bd9aff8466d69819e0b849752f967c126
Part-of: odoo/odoo#124465
This addresses a series of alignment issues in the conversion of html.
X-original-commit: 5b5a0030f8cd75f0a977d7804b54dc454a6a8751
Part-of: odoo/odoo#124465
This addresses a series of issues regarding images, their responsive
behavior and their alignment.
opw-3244705
opw-3185231
X-original-commit: e20bc14e8860ce8f84eb5b0006ec67b708530161
Part-of: odoo/odoo#124465
Prior to this fix, elements with background images were converted to
images via the html2canvas library. This made them work in Outlook at
the cost of several tradeoffs:
- the process was slow and asynchronous
- there could be no interactivity (links, buttons, etc.) in the
converted element
- responsive behavior was wonky: if only a slice of the image was shown
when it was converted (due to background-size cover behavior), the
rest was lost so if more width was needed in mobile, we would be
zooming on that slice, making it sometimes irrelevant and pixelated
This replaces all that with a conversion to VML, which is a vector
format supported by Outlook. This conversion is done only for Outlook,
which means that all other clients are getting the original background
element again.
There is a way to keep the background-size cover behavior in VML, using
the "aspect" attribute with value "atleast" but this only works on
v-fill elements and sadly putting the image on a v-fill element bugs in
Windows Mail (which is the default mail client on Windows 10 and 11) and
this client can't be singled out of mso conditionals. To get around this
issue, since this is only for desktop clients, we assume the width of
the screen to be large and mimick the cover behavior by cropping the
image to the target size. This allows us to put the image on the v-image
element and have proper rendering in Outlook and Windows Mail on
desktop.
Note:
When retrieving the image by URL in Python in order to crop it, we need
to ensure we have an absolute path. This is done - perhaps seemingly
naively - by checking if the URL contains '//'. Here's the reasoning
behind that choice. To check if a URL is absolute, we could use
`urllib.parse.urlparse` and check if it has a scheme but that would lead
to `www.odoo.com/path` being considered relative (and thus we'd add a
host to the URL even though there's already one). Instead, we could
check it it has a netloc but that would lead to the same issue since the
documentation of `urlparse` says:
> Following the syntax specifications in
[RFC 1808](https://datatracker.ietf.org/doc/html/rfc1808.html), urlparse
recognizes a netloc only if it is properly introduced by ‘//’.
Still, it would be more technically correct since `//some/path` would be
considered absolute (which it should be since it resolves to
`<current_scheme>//some/path`).
Base on that documentation, it seems that simply checking if the URL
contains '//' is pretty much equivalent to checking if it has a scheme,
with the double advantage that it's simpler and that it works for
`//some/path` as well. However, note that it doesn't solve the issue of
`www.odoo.com/path`.
In summary, here are the results with the current method:
```
http://www.odoo.com/path -> http://www.google.com/path // OK
some/path -> http://localhost:8069/some/path // OK
/some/path -> http://localhost:8069/some/path // OK
//some/path -> //some/path // OK
www.odoo.com/path -> http://localhost:8069/www.google.com/path // WRONG
```
X-original-commit: 9561ba31917024825705c876442139405e7a7957
Part-of: odoo/odoo#124465
Several issues were found regarding the responsiveness of columns,
especially in the Masonry snippet. This implements a new, more robust
approach to responsiveness of columns, based on article [1], where each
column is wrapped inside a new table, itself wrapped in an inline-block
div element, and all adjacent wrapped columns are in turn wrapped in a
common table cell:
```html
<.container>
<.row>
<.col id="A">
<.col id="B">
</.row>
</.container>
```
becomes something like:
```html
<table>
<tbody>
<tr>
<td>
<div style="display: inline-block;">
<table>
<tbody>
<tr>
<td id="A">
</tr>
</tbody>
</table>
</div>
<div style="display: inline-block;">
<table>
<tbody>
<tr>
<td id="B">
</tr>
</tbody>
</table>
</div>
</td>
</tr>
</tbody>
</table>
```
with some additional attributes and styles to make it work.
[1]: https://www.litmus.com/blog/mobile-responsive-email-stacking/
task-3184107
X-original-commit: 3ddba4dbd57891c2d9fc80fb7aa0dd08338fe3f6
Part-of: odoo/odoo#124465
Conversion of some masonry grids caused unexpected responsive behavior,
leading to a result that didn't match the edited design. This was caused
by a few separate issues:
1. Sometimes Masonry declares rows with a height of 100% but with
columns that overfit the grid. In these cases, we split the rows into
multiple rows but we failed to adapt their heights for them to be
divided equally.
2. A call to `setProperty` failed silently, making it so the height was
never set on certain rows.
3. When converting background images, we failed to remove their padding.
4. Bootstrap grid media queries were only inlined from the xl breakpoint
and up, but the snippets typically use the lg breakpoint.
5. The "o_desktop_h100" class was not applied to the parents of
`.o_desktop_h100` cells, making the rows too big for their cells in
mobile.
6. A combination of the above made the conversion fail when the masonry
snippet had a non-automatic height.
task-3184107
X-original-commit: 04d1c0caeb78ee3bedff579e229e5da47c2689ce
Part-of: odoo/odoo#124465
This adds two util functions, to create mso and !mso comments (which can
be error-prone).
X-original-commit: e258a28aa147db97eab1d3dc5db3595adf91541c
Part-of: odoo/odoo#124465
This addresses a series of issues with mso conditionals that were not
closing in the right places.
X-original-commit: 247e05a9cca403fca3de01feb49d0f0374ea38de
Part-of: odoo/odoo#124465
The "readonly iframe" mode of html_editor does not do
the processing required to ensure all links target a new tab when
the setup is called more than once.
As this happens often, links effectively did not redirect to a new tab.
Additionally sandboxedIframe did not allow new tabs to open.
We add `allow-popups` and `allow-popups-to-escape-sandbox`
to the sandbox attributes.
This is safe as the popup will not have access to the odoo window.
Which should mean it's as safe as opening a link without the sandbox.
opw-3337670
closesodoo/odoo#124395
X-original-commit: 61b6b6bf6181fe703cd3d455dba9004e1fad7135
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
This commit allows users to choose any color for their navbar when it is
over the content. With this commit, the user can choose the color he
wants for his navbar when it is scrolled and when it is not scrolled
without worrying about color mixing.
To simplify the explanation below, note that "Colors" option means the
Colors option of the header (just below the Template option) and the
"Background" option means the option below Header Position.
By following these steps:
- Drop some blocks in a the page (to be able to scroll)
- Set a light transparent red for the Colors option.
- Set the navbar position to "Over the content"
- With the Background option, set the background color to a dark color.
=> When you are at the top of the page, the color is the one of the
Background option. So far so good. Now when we scroll, the color of the
navbar is dark red. This is not what the user expects. The user should
be able to have any color he wants for the scrolled navbar. It's not the
case before this commit. He cannot have a dark transparent header on the
top of his page and a light transparent red when he scrolls. In this
configuration, the Colors option should set the color of the navbar once
the user has scrolled. The colors should not be mixed.
Technical explanation of the problem:
Background option applies the color on the header element and Colors
option sets the color on the nav element. The nav element is a child of
the header element.
So when the header has a color set by the Background option and nav has
a color set by the Colors option which has transparency, the color of
the header influences the color of the navbar when scrolling. This
commit allows to correct this.
This commit also fixes the same problem for the gradient option.
task-2904507
closesodoo/odoo#106281
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
The target for `this._pluginCall('sanitizeElement', ...)` should never be null.
As we provide the parent element of the initial target for optimal sanitization,
we can encounter some cases where the target element is not yet added in the DOM
and as such doesn't have a parent Element.
We add a verification to ensure sanitization doesn't generate error in those cases.
task-3356284
closesodoo/odoo#124287
X-original-commit: 1d9decd6b08eb2d093f0dcead73f3bb895be27ff
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Bootstrap tooltips are overlapping the parent box, it could cause an
infinite flicker in the web editor because the pointer goes over the
tooltip, disabling the tooltip, refocusing the parent, enabling the
tooltip, etc.
Since commit [1], the tooltips are centered differently, making this
worst because of a bigger overlap.
Steps to reproduce:
- drop a "Text" block
- select it
- hover the bottom border of the "50%" Height option
--> The tooltip flickers infinitely, along with the blue overlay on the
editor.
This commit fixes it by disabling the pointer events of the tooltip.
[1]: https://github.com/odoo/odoo/commit/09b720eff1a7
task-3299236
closesodoo/odoo#124262
X-original-commit: ec343728831c12eacdc6b3d031eb8d0b4b82ecdc
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
One of the list tests had two "end of selection" characters in its
content before and after the step function. This made it unclear which
was relevant and which wasn't.
closesodoo/odoo#111119
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Superfluous zero-width spaces were removed by the sanitizer and then
upon saving (`cleanForSave`). This commit removes the code dedicated to
that from the sanitizer in favor of the code in `cleanForSave` (adapted
to cover all cases).
Note: this means that with this commit, superfluous zero-width spaces
are not removed from the editor during edition anymore, but only when
saving.
task-3081457
Part-of: odoo/odoo#111119
Krzysztof Magusiak