The goal of this commit is to replace the "Toggle underline" option
from the website's text editor by a new "Highlight effects" option which
should allow applying some highlights on the selected text and setting
their color & thickness. Also, the text editor "Toggle strikethrough"
option will be moved to the list of highlight effects in the new option.
For this purpose, the JS code used for text animations will be updated
to be more generic and handle text highlights too. Moreover, The "Text
Highlight" options will be applied by adding a SVG to the targeted text
element (allowing to adjust their `stroke` and `stroke-width`).
To simplify adapting highlights when the text content is updated,
we follow this generic structure:
```
<span class="o_text_highlight">
<span class="o_text_highlight_item">
line1-textNode1 [line1-textNode2,...]
<svg.../>
</span>
[<br/>]
<span class="o_text_highlight_item">
line2-textNode1 [line2-textNode2,...]
<svg.../>
</span>
...
</span>
```
Rendered line breaks in text nodes are detected using range client
rectangles (see: `text_processing.js` > `splitNodeLines()`), and the
highlights are updated on window resize...
We also need to adjust highlight SVGs to fit an updated text in "edit
mode" (mainly using editor's commands), a `MutationObserver` is used
for this purpose (we only redraw the SVG for each text unit).
A simple SVG path generator was implemented in this commit (see:
`text_processing.js` > `drawPath()`) to build highlights. It applies a
list of SVG path commands according to text dimensions in a specific
mode (E.g. on "pattern" mode, we repeat the same elementary path to fit
targeted text node...).
Remarks:
- The `--text-highlight-width` and `--text-highlight-color` properties
are used to control the highlight effect's thickness and color.
- We build the highlight option preview in the same way as text content.
To achieve this, a hack was used (we open the `<we-select/>` first since
we need the right `getBoundingClientRect()` dimensions to correctly draw
highlight SVGs).
task-3285817 (rd-website)
task-3269759 (rd-design)
closesodoo/odoo#122751
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Chrysanthe (chgo) <chgo@odoo.com>
*: website_livechat, website_sale, website_sale_wishlist
This commit adapts some templates and tests JS to prepare for the new
headers in the next commits.
task-3060986
Part-of: odoo/odoo#119650
*: mass_mailing
This commit introduces options for the flex column layout and the
horizontal resizing to be used on mobile and be independent from
the desktop layout.
This makes it possible to:
- Have different number of columns on mobile and on desktop.
- Use different column widths and offsets for mobile and desktop.
- Reorder columns independently.
The behavior expected from the columns is:
- In the editor panel, Cols indicate the number of columns per row on
both mobile and desktop. The option is conditional of your environment:
you edit the number for the screen size of your current resolution.
- When columns have different sizes (either because it is the default
behavior of the snippet, or because the user resized some), the counter
should read "Custom". Same when the user changed some offsets.
- If manual modifications were made on width and offset, they are reset
on the current display if the number of elements is updated. This was
decided because an old, specific layout with custom offsets / width
doesn't work well with a different number of elements. (This is also the
default behavior before this PR with desktop-only modifications.)
The expected behavior when reordering is:
- On mobile, it should only affect the mobile layout.
- On desktop, it should affect both layouts.
In order to have a coherent feature on both mobile and desktop as well
as correct some non-ideal but non-blocking behaviors, the commit also
changes the following behaviors:
- When setting a columns count lower than the current number of items in
the `.row` container, extra items are now wrapped on the next flex-rows
(still within the container) instead of being deleted.
- When going from e.g. 3 to 5 columns (and as many items), the change
happens all at once instead of each item being visibly added one by one
on the next row, then brought back to the first row.
- The columns count automatically updates when resizing an item, instead
of updating only after you click somewhere else on the snippet.
This commit also adds a test to validate the new behavior.
task-3097045
closesodoo/odoo#117562
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor, mass_mailing
This commit changes the way the font size selector works. Before this
commit, the font size selector applied a hardcoded font size using the
style attribute of the selected element. The purpose of this commit is
to change this to apply a class on the selected element, making it
responsive and customizable.
In all Odoo applications, the font size selector will now apply a class
on the current selection. An exception is made for mass mailing where
the class would not make much sense as not related to the custom heading
sizes (probably needs to be refactored in the future to use the standard
font-size classes) and fonts cannot be responsive in mails anyway (so
there would be a difference between preview and sent mail).
Those classes are:
- `display-N-fs` with N in [1 => 4]. The sizes are stored in the
`$display-font-sizes` map.
- `hN-fs` with N in [1 => 6]. The sizes are stored in the
`$hN-font-size` variables.
- `small` for the small font size. The size is stored in the
`$small-font-size` variable.
The font size selector shows the value of the class (which is dynamic)
that will be applied.
In the website application, the value of each class is configurable
thanks to a previous commit. The user can choose the size of each font
size class in the website settings.
Note that many alternatives were considered for this feature, this is
the chosen compromise. For the record, here is a very short summary of
the alternatives:
- Doing nothing: voted as the worse idea. Users see a font-size selector
they will use it one way or another. The font-size won't be
responsive, breaking their mobile website. And there are real use
cases you could not do: a big "promotion" paragraph on your product
page? Not possible: you either break your mobile page (using the font
size option) or possibly hurt your SEO (using the font-style option
and turning your paragraph into an h1).
- Removing the font-size selector: we did not want the loss of the
feature as there are correct usecases to use it (as mentioned above).
- Using the Bootstrap hN and display-N classes instead of making new
ones. Closed to be the chosen idea but discarded because those classes
comes with colors (that the user can configure) and it would feel
weird to have the color change when changing the font-size. Also, in
the end, we also did not want the line-height, margins, etc of those
classes (only the font-size).
- Instead of X new classes, have only one: o-fs, which would be applied
alongside a bootstrap hN or display-N class, when chosen by the user,
to cancel the unwanted style of those. It works but it forces us to
always have an added `<span>` to apply the font-size, which we don't
want in the future (mainly because of display-N classes, see next
commit). It is actually very needed to be able to use proper
line-height when reducing the font.
- Using a combination of an inline `em` font-size + a class to clamp it
on mobile. Was probably the best next idea but rejected for several
reasons. The main one probably being the inconsistency when changing
the whole size of a title/paragraph (not part of it) and later
changing the related theme size later. E.g. have an `<h1>` followed by
a `<p>`. The h1 is 40px, the paragraph is 20px. Force the title to
20px, because you want it smaller, same size as the paragraph. Real
use case but also users could simply use the font-size controls by
mistake. We would thus apply 0.5em to do that. Later, change the theme
font-size of h1 to 36px (small change). The 0.5em one is now 18px,
smaller than the following paragraph. Preventing that would require
more checks which would "break" other things / possibilities.
- Probably others that were forgotten.
In the end, there was no good or bad answer. "Anything works", as long
as the feature "I want this text smaller/bigger" is there. The
surrounding features are always compromise (some users would expect some
behavior, some users would expect others). This commit focused on
solving the unresponsiveness of those custom font-sizes, which was a
problem for many users.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit adapts the configurator so that the pages it generates are
composed of the primary templates generated from the manifest by the
previous commit.
task-3381714
Part-of: odoo/odoo#126719
The issue that can happen is a t-cache covering a t-call-asset.
The asset_cache is invalidated but not the t-cache, meaning that the url
pointing to the asset will lead to a 404 once another request, without
t-cache, will regenerate the asset.
X-original-commit: fffc198914b8c885905e9dddd72b6490fcc4c120
Part-of: odoo/odoo#138647
This commit removes instagram from the `snippets_all_drag_and_drop` tour
to prevent too much external calls.
task-2603045
closesodoo/odoo#138558
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The livechat button was disabled in website preview because
its implementation could not properly handle being in an iframe
inside the backend [1].
With the public livechat code being refactored to use discuss code,
this is no longer a problem, so the livechat button can be present
again. This also makes previewing the website more correct: the
livechat button is actual present on the website, so hiding it was
a lie.
By re-enabling the livechat button, this also allow to remove the
test coverage by a tour, which was sometimes failing on runbot due
to tour being small and doing `im_livechat/init` rpc after the end
of the tour.
[1]: https://github.com/odoo/odoo/commit/e86c1ce94a148745d58ac38e408e1bc947978670
runbot-24631
closesodoo/odoo#135913
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
before this commit:
translations updated by `update_field_translation` api cannot be detected by
t-cache and some cached data whose model overrides `write` with an extra
'clear_caches()'
Step to reproduce:
- Create a mega menu, select any template, `Odoo Menu` for the example
- Install another language on the website
- Go to the translated version of your website and enter translate mode
- Change "Camera" in the mega menu to something else
- Save
The change won't be replicated, looking like it did nothing.
From there, removing or adding `edit_translations=1` in the URL will
use different cache version of the page's views and you will see the
outdated value on one and the correct on the other one.
after this commit:
`update_field_translation` will call `write`
it does the following 4 important things
1. mark field as modified
2. execute logics in the override `write` method
3. update write_date if needed to support t-cache
opw-3305117
X-original-commit: 2beb466668e4eb80d7c3ca3947445fb1cb141cff
Part-of: odoo/odoo#135277
When building a website with the website configurator, you get pages
with a nice layout. However, the text inside is not adapted to your
company, industry or even, most of the time, language.
Using a LLM, we could easily get text much more relevant to customer
needs. The scope of this work is static pages generated with the website
configurator (homepage, about us, pricing, ...).
Later, in other tasks, we also want users to be able to generate text
inside the website builder.
This commit implement the bare minimum to generate and replace a website
content by AI generated sentences (based on the information provided by
the user).
Related IAP PR at https://github.com/odoo/iap-apps/pull/656
task-3248852
closesodoo/odoo#121021
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Since #121376 a clear_cache was removed when unlinking an attachment
This clear_cache was not useful when restarting a server with new
sources, an other operation changing the content of an assets should
invalidate the cache manually. This is the case of ir.asset CUD
operations.
Unfortunately, a manual update was left missing in website, when
archiving ir.assets used for snippets.
This was discovered on runbot, with two workers, when the first workers
generates assets before the cron, and the second one after the cron.
The second worker unlinks attachments creating an inconsistency in the
cache of the first one.
This problem can be solved quickly by invalidating the assets cache in
the cron manually but this will be done in all cases. The proposed
solution will check the ir.asset that should change and only clear the
cache if the state changed.
Regarding performances, this should actually be a slight improvement in
query count since at the cost of one more select to prefetch the record
we can avoid multiple update, one per snippet. In most case no update at
all should be done, at most 2 can be done (one for archive, one for
unarchive).
Example with some assets to unarchive:
Before:
TOTAL ENTRIES: 277
SELECT: 158 (~0.16591858863830566s)
UNKWOW: 54 (~0.0202481746673584s)
UPDATE: 65 (~0.03202557563781738s)
After:
TOTAL ENTRIES: 214
SELECT: 159 (~0.1663439826965332s)
UNKWOW: 54 (~0.029229164123535156s)
UPDATE: 1 (~0.0002865791320800781s)
If the number of query is lowered, the python processing is slightly
higher. Locally the test time is similar, slightly longer since an
additional call to _disable_unused_snippets_assets was added to check
the cache invalidation
closesodoo/odoo#130973
X-original-commit: 3aeab51ff4379e6d76172614fd39f09d6c449ac6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
We prevent to merge partner linked to more than one user (by raising an
exception) to avoid having multiple user pointing to the same partner as a
consequence of a merge.
We want to avoid this situation because it generates weird behaviors. As
res.user inherits from res.partner, having multiple user pointing to the same
partner makes the fields of that partner shared with all those users. This was
decided following the tentative to improve partner merge in website_slides
(odoo/odoo#114840), where we also noticed strange behavior like completing a
lesson with one user were adding karma to all the users linked to a same
partner.
We have also adapted WebsiteVisitorTests tests in website that were failing
because they were merging partners with more than one user: simply by merging
partners with only one user.
Task-3167160
closesodoo/odoo#125322
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Add test to verify scrollbar behavior for page and popups with or
without backdrop. The expected behavior is that the page scrollbar
should not be present when a modal with a backdrop is open, and that the
page scrollbar should be displayed if the popup does not have a
backdrop, such as a cookie bar. However, if a modal without a backdrop
itself has a scrollbar, the page scrollbar should not be displayed to
prevent the two scrollbars from overlapping, which prevents scrolling of
the popup on Chrome (when clicking on the scrollbar instead of using the
mouse wheel).
In addition to that, this commit includes a test to confirm the proper
functionality of snippet animations when a cookie bar is displayed on
the page. Moreover, it also verifies that the snippet animations perform
correctly within a popup.
During the forward port of this commit (Master branch), the test failed
due to missing braces around 'throttleForAnimation' in the '000.js' file
of 's_popup'. These were directly added in this commit.
task-2983901
closesodoo/odoo#128914
X-original-commit: 4dd462f20ccb29923e5a053e0ed4c08545f82ae7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
*: test_website, website
Steps to reproduce the bug:
- Drag and drop a text-image snippet onto the page.
- Add a shape to the image of the snippet by selecting the shape from
the options.
- Click on the "replace" button in the options of the image.
- In the media dialog, navigate to the "icons" tab.
- Choose an icon.
- Inspect the HTML code of the icon in the DOM.
- Bug: The 'data-shape' attribute with a value is still present.
After this commit, when replacing media, the transfer of element
attributes specific to "shape" elements only occurs towards an image and
no longer towards other media (e.g. icons).
We also prevent adding shapes to images that don't support it (e.g. SVG
files). Before this commit, when replacing a .jpeg image that had
a shape with a SVG image, the shape was not removed.
This commit also adds tests to prevent these bugs from reappearing.
task-3420533
closesodoo/odoo#129079
X-original-commit: 023b0b3124a7181fdf486df8c830bb16edd10aa6
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
*: web_tour, website
When no transformation is applied on an image, changing the quality
sometimes increases its storage size.
This commit makes sure that the original image remains used if only the
image quality is modified and if this makes its storage size bigger.
Fixes#61619
task-2835144
closesodoo/odoo#103398
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit separates the test that was added together with the "not
move images twice within image wall" fix because it requires additional
fixes for working in 16.0.
task-2990053
closesodoo/odoo#125758
X-original-commit: f4e8ca1eca1193a72a0b1d21cbc4af5093907ca9
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
This commit introduces a new feature to the popup snippet.
Up until now, the popup could be displayed after a delay or on exit.
This commit enables the popup to be displayed on click.
To make use of this feature, the user will need to:
- Set the "Display" option of the popup to "On Click (via link)".
- Paste the anchor that has been copied to the clipboard into the
URL input of any link.
This commit also adds a test for this new feature.
task-2172312
closesodoo/odoo#76442
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to website > drop a snippet with text content.
- Select a text > click on text animation button to activate the option.
- Click on the button to disable text animation > The text animation
cannot be applied again on the text.
Starting from 16.0 (exactly [1]), the `document` > `selectionchange`
event listener was added on `this.$body[0]`, which means the code from
`__onSelectionChange` will never be executed, and as a consequence, the
option will handle the text as if it has already an animation because
of the not correctly updated value in `this.$currentAnimatedText`.
Spotted while working on [2].
[1]: https://github.com/odoo/odoo/commit/3c2febddb67888617dad74af0e9e46ed60d105b7#diff-d2188391a9d83cc97f3220e08d259e82796d94191dcf5e5fdb9b77e57074e6a5
[2]: https://github.com/odoo/odoo/pull/122751
task-3414256
closesodoo/odoo#127812
X-original-commit: 1bf244c77f4bd1f52c0964b75e0ce5582bfa54f7
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
The website frontend apps menu list is not working when the user has a
`Home Action` defined on his user.
The `Home Action` is meant to redirect to the defined action whenever
that user is login in.
But since the backend menu links on the website have most of the time
no `action` defined but just a `menu_id` defined, the `Home Action` will
kick in and take over the redirection, the same way as if the user just
type `/web` without any params.
To solve that, we simply force the `action` of those links (if they
don't already have one).
This will make sure that the redirect is working as it should for users
having a `Home Action` set.
Step to reproduce:
- Set a Home Action for any user, like "Contacts"
- Go to the website frontend, eg on `/`.
- Click on the top left button to show the backend app menus list
- Click on any menu (CRM, Invoicing, Calendar..)
-> Most of those menu will not redirect you were you are supposed to be
but on your Home Action instead.
You can figure which one will be buggy or not by just mouseovering
the link and see if the URL param `action` is set to something or
not.
--- Technical hints ---
There is multiple methods to get the list of menus in Odoo:
- `load_web_menus`: called by the web client rpc, calling `load_menus`.
If a top/app menu has no action defined on it, it sets the first found
action of their children menus to it.
It returns the full (flat) list of menus, not only the top/app ones.
This method is not ormcached but is calling an ormcached method and
just doing some tiny work on the data.
- `load_menus_root`: called only by website backend template to add the
app list on the website (in the frontend) to jump to the backend.
It does not force the action if a menu has no action set on it.
It returns only the top/app menus.
This method is ormcached.
Note that this method seems only used by the website module.
- `load_menus`: returns the full (flat) list of menus without a force
action
This method is ormcached.
Fixes https://github.com/odoo/odoo/issues/119971
task-3378963
closesodoo/odoo#127840
X-original-commit: f28a349aa40b2ea48ef8f2b71e806b965777014f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The unsplash beacon public widget is started before the test assets JS
is loaded. Because of this, the approach in [1] fails sporadically.
If the result from the `/web_unsplash/get_app_id` RPC is obtained
before the test assets JS is loaded, the beacon patch is not applied
in time, and the test fails.
This commit applies the patch within the actual page HTML to avoid this
issue.
[1]: https://github.com/odoo/odoo/commit/a5abc766424f34074be3ae7a97ad7c6e9583f9c5
runbot-22610
closesodoo/odoo#127809
X-original-commit: 3f64135ff136addfad7c4c79e8c19cc33f8b19cf
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before the task
when the default language for a website is not en_US, and users try to
edit_translations from the website, all terms are marked "translated"
because odoo adds
`data-oe-translation-state="to translate"` if the term is not extracted from
the en_US value and is the same as its en_US term
After this commit:
if the record's bounded website's default language is lang_base
odoo adds
`data-oe-translation-state="to translate"` if the term is not extracted from
the lang_base value and is the same as its lang_base term
closesodoo/odoo#127468
Task-id: 3344973
X-original-commit: 7c20510bda2f1312a9392df445ee38aea7b2267b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Before this commit, the "click on save" in french step was checking for
the element containing the "Save" french translation term, which is
coming from Transifex.
It sometimes changes, making the tour fail.
It was "Sauver", then "Sauvegarder" and now "Enregistrer".
This was a well known issue as we already made a quick and dirty fix for
that with [1].
It was judged enough as we did not want to spend more time on this fix
as it was expected to not break anytime soon, and we needed a quick fix.
The chance is now taken to adapt the test to not rely anymore on the
.pot file.
We also take the chance to not use an existant translation but a fake
one as it will speed up the test (no need to actually read/parse .po
files are there is none for this lang).
[1]: https://github.com/odoo/odoo/commit/594ac2c9651f27cc1623fcd5b916cb191241651b
runbot-22946
runbot-22945
closesodoo/odoo#127493
X-original-commit: 6d9d4d1b43544ae98cc8037ba01c81b66ab9f0ee
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.
To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.
task-3360109
closesodoo/odoo#126522
X-original-commit: 1b0f25130b461e7b531548363c680200c7363e7f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Previously, any call to `IapAccount.get` during testing would lead to
the creation of a new `iap.account` record as this was done in a
separate transaction which is commited.
As we don't want any database modification resulting from a test
execution, we will now check if we're in test mode or not.
During testing, a new account will be created in the current transaction
so that it can be properly rollbacked at the end of the tests.
This commit also modifies how the `iap_jsonrpc` function is disabled
during testing as the old implementation used some pretty obscure
manipulations of the `BaseCase` class.
The tests of the `website` module needed to be updated to take those
changes into account.
closesodoo/odoo#122663
Signed-off-by: Florian Daloze (fda) <fda@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>
*: 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
This commit adds arabic in the list of iap languages so that we can test
that the industries are correctly translated in arabic.
related to task-3343616
closesodoo/odoo#125005
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit ensure the expected tables are accessed when a page (not
only) is requested.
This is needed because without that, we can only check the query count
number which might be broken without being noticed:
- Commit 1 reduce queries by 2 (no need to access table X anymore)
- Commit 2 later reduce queries by 2 (less access on a table) but
without noticing it, it also now introduce back the access of table X.
At the end the query count is still fine, but the code is not: it broke
a previous improvement while it was not necessary.
Worst, it could even lower the query count despite still breaking a
previous improvement (-3 queries +2 queries back).
Also, since the query count of a page is not exactly the same inside a
test and in real use cases, an `EXTRA_REQUEST` param is used in those
tests to abstract that change and still use the "real use case" query
count in the test to fit the reality, be human readable and easier to
write/debug.
Indeed, in test mode there is more queries due to the test cursor
rollback and savepoint, but there is one less query (the cache one).
Some commit wrongly reduced that `EXTRA_REQUEST` param making it looks
like there was an improvement while there wasn't.
This commit will help preventing all of that, ensuring the correct
tables are accessed and only those, on top of checking the query count
number (we still need to check the query count in case there is a query
not catched in the SQL table logs).
Some of the PRs/commits where it happened:
- https://github.com/odoo/odoo/commit/aa1c1b0bcb5327894c7b00d0454eebae06eaa005
- https://github.com/odoo/odoo/pull/112000/files#r1160851862closesodoo/odoo#124939
X-original-commit: 26e1fc3abd54a1baa16cf1c99d75d501a8dc6906
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds a test to check that the IAP languages work as
expected for the website configurator. The test checks that the
industries are translated (different than other languages).
task-3343616
closesodoo/odoo#123722
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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
When generating a new page key, it was only made sure to not match
existing page keys. This leads to COW happening on existing views if the
key already existed in a view.
This commit ensures that new page keys are not existing view keys
either.
Steps to reproduce:
- Create a page named "snippets".
=> Notification was shown indicating that `website.snippets` is private.
task-3328827
closesodoo/odoo#123693
X-original-commit: e7ef9f0bfc59a468c9f883561c371367cc06c1b7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The build does not break if the `with_context(active_test=False)` is
removed from `ir.asset`'s `_get_related_assets`. This access to inactive
assets is actually needed to be able to disable assets on a specific
website, similarly to what is done for `ir.ui.view`.
This commit adds a test to ensures that this feature is not accidentally
lost.
task-3326887
closesodoo/odoo#123662
X-original-commit: fced70f840c98e29675ff41812e76c1883d1d57f
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*website
Steps to reproduce the bug:
- Add a Cover and a Picture snippet on the website.
- Change their visibility to "Conditionally".
- Change the order of the two snippets on the page either with the drag
and drop tool or with the "move up" or "move down" option.
=> Their order on the "Invisible Elements" panel has not been updated.
The problem is fixed by calling `_updateInvisibleDOM()` at the end of
`moveSnippet()` and `_onSnippetDragAndDropStop()`. Note that before this
commit, all the snippets with a conditional visibility were hidden at
the call of `_onSnippetDragAndDropStop()`. This is due to the call of
`cleanForSave()` from `_destroyEditors()`. `_onSnippetDragAndDropStop()`
has been adapted in order to, as for the "move" option, do not change
the visibility of those elements.
task-3203914
closesodoo/odoo#123027
X-original-commit: 3a023cf00812cfbbef7f3b406fbd01b74f07b7c8
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
*web_editor, website
Steps to reproduce the bug:
- Add a Text-Image snippet.
- Change its visibility to "Conditionally".
- Save.
- Edit again.
=> The eye icon indicates that the snippet is not visible but the
snippet is displayed.
Note that [1] introduced a mechanism to solve this problem (the
`cleanForSave()` of the `ConditionalVisibility` option) but the code was
not working correctly since [2].
Let's first remember that when calling `toggleTargetVisibility()`, two
main actions are performed:
- The addition or suppression of the `data-invisible` attribute from the
dataset of an invisible element. This attribute is responsible for the
crossed or not of the eye icon in the "Invisible Elements" panel.
- The call to `onTargetHide()` or `onTargetShow()` that performs among
other things the addition or the suppression of the
`o_conditional_hidden` class on an invisible element. This class is
responsible for the visibility of the element on the page in edit mode.
This being said, here is what happened at the "Save" before this commit:
- `cleanForSave()` of `snippetEditor` is called. If the related element
has the `o_snippet_invisible` class, `toggleTargetVisibility(false)` is
called (meaning that the `o_conditional_hidden` class and the
`data-invisible` attribute are added to the element).
- `cleanForSave()` of the `ConditionalVisibility` option is called and
before [2], the `data-invisible` attribute was removed from the
corresponding element.
- At the `DOMContentLoaded`, the `o_conditional_hidden` class is removed
from all the elements that have a conditional visibility. The visibility
of those elements on the page now depends on the rule set by the user.
The goal of this commit is to restore the mechansim of the remove of the
`data-invisible` attribute from the conditionnal elements at the
`cleanForSave()`.
[1]: https://github.com/odoo/odoo/commit/1c442782f887a8c16bae05a43fae13a310ac05df
[2]: https://github.com/odoo/odoo/commit/de3c29fab2bc5349da8a9418f9d0086d76e6f7de
task-3203914
X-original-commit: b10d6cbf78235acd170716d556578227cccfbc14
Part-of: odoo/odoo#123027
Before [1], chat windows were not shown on the website preview.
Showing them was not intended and those chat windows overlap
with the one of the livechat.
This PR restores the previous behavior by preventing chat
windows to be shown on the website.
[1]: odoo#110188
closesodoo/odoo#123096
X-original-commit: 3e74f5c1f4ea045725edcd945276e524529ffd97
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.
Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account
=> If as an admin you check the company of the created user, it is
company A instead of company B.
[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9
task-3277317
closesodoo/odoo#121834
X-original-commit: 3fbfb5301c7583583e4f46c9b4ef16e048e5800c
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
New data will be introduced that involve the "product" word... while
this is a word a fuzzy test is based on. This commit adapts the test so
that its results are based on words that are less likely to appear in
default data.
task-2406626
Part-of: odoo/odoo#67913
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit an ir_assets generated automaticaly by the web editor
will generate an url ending with ...custom.addon.bundle_name.ext
After this commit the url will start with /_custom/addon.bundle_name/...
This will make it easier to spot at immediately if it is a custom asset
and thus it is useless to apply the glob. Actually, it will fail on the
/_custom when trying to glob, making it faster.
This is mainly useful to clarify and debug but in a case with mainly
customised ir_asset for one bundle, it may have an impact on speed.
An upgrade script was created for this change.
closesodoo/odoo#120699
Related: odoo/upgrade#4636
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
== Issue ==
A business code error was detected by the internal team on our
production. The cache and assets where invalidated !WAY! too often for
the past months.
It was hard to figure but finally the error was tracked down to be
located in the assets retrieval stack of our code when a database is
accessed through multiple different domains.
In our production use case, whenever one was accessing `odoo.com/web`
after someone accessed `accounts.odoo.com/web`, the assets would be
invalidated and recomputed, again and again, whenever someone accessed
the backend on a domain after someone else did with another domain.
Obviously, on our production, this could be occuring multiple time per
minute.
Technically, this is because the "assets retrieval stack" had a mismatch
in multiple endpoint when trying to find if a current website was
involved (serving for the frontend).
Some business method were using `env.context.get('website_id')` while
others were using `env['website'].get_current_website(fallback=False)`.
From there, when the code was called without a `website_id` in the
context, `get_current_website()` would still return a `website_id` when
called from `http://odoo.com` as there is a website having its domain
set to it. `get_current_website()` is then finding it and returning it.
But it would not when the user is on `http://accounts.odoo.com`.
Since we have a custom scss override (done through our website builder,
basically an ir.asset linked to a "url type" attachment:
`/website/static/src/scss/options/colors/user_color_palette.scss`) for
our website to define the website colors which is shadowing the scss
file from disk.
So, depending of the host/domain, either the real file disk for this URL
or the ir.asset linked to our website for this URL would be fetched to
generate the bundle hash (which is basically the last modification date
of the files/attachments).
Obviously, the file on disk and the ir.assets have a different last
modification date.
The system would then consider the assets as outdated and would
regenerate it.
You can see it in the logs where the attachment id of the assets URL
would get higher and higher everytime you access the DB through another
domain.
Using `get_current_website(fallback=False)`:
- `_get_related_assets()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L14
- `filter_duplicate()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_asset.py#L41
- ..
Using `get_current_website()`:
- `_get_custom_attachment()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/assets.py#L162
- ..
Using `context.get('website_id')`:
- `_get_asset_url_values()` https://github.com/odoo/odoo/blame/30d3b97b5ece379d9ddcbceda9d12c03dc7f4a48/addons/website/models/ir_qweb.py#L23
- ..
== Fix ==
A fix could have been to aligned those to use the same way of retrieving
the website but it would be too fragile (definitely some other places
where the same bug is involved but not yet found).
What is done in this commit is something we wanted to do for a long time
(see [1]) but was based purely on guess and feeling rather than concrete
bug / use case, but now that we found a real use case, we will do it:
- It doesn't seems to make sense to consider the request host/domain
when we are in the backend
- Same for the forced session, those should only impact the frontend
calls.
But this seems to have too much impact in stable to be changed, as it
would require to check every caller to also check for the session if
it makes sense. This will be done in master as not really needed to
prevent the critical bug fixed here.
- When something wants to alter the backend with a website, it should
explicitely be passed in the context, which is still considered
regardless if it's a backend/frontend call.
- If something needs to consider the forced website in session in the
backend, it should explicitely check it, not relying on
`get_current_website()`.
== Step to reproduce ==
- Start a db with website installed
- Enter the website builder in edit mode and change the "Theme Colors"'s
first "Color Presets"'s background color (it is white by default).
- Set the website domain to `http://127.0.0.1:8069/`
- Go to `http://127.0.0.1:8069/web` and login
- Go to `http://127.0.0.2:8069/web` and login
- Now start refreshing those 2 pages one after each other.
Everytime you will refresh the page, it will take a very long time
(~5-10 seconds) before loading the page, and monitoring the logs will
show something about invalidating the cache and huge query count.
== Benchmark ==
For the explained "multiple domain access" case, the backend /web will
now be loaded in less than 10ms and with ~10 SQL Queries when website is
installed, while it was taking ~4 seconds and ~200 Sql Queries before
the fix.
Before the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 222 0.135 3.840 <-- 222 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.101 3.692 <-- 181 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 215 0.121 3.704 <-- 215 Queries, ~4s
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host2.com/web HTTP/1.1 200 - 181 0.100 3.616 <-- 181 Queries, ~4s
```
After the fix:
```
odoo.modules.registry: At least one model cache has been invalidated, signaling through the database
GET host1.com/web HTTP/1.1 200 - 101 0.043 0.353 <-- 101 Queries, ~0.3s
GET host2.com/web HTTP/1.1 200 - 11 0.004 0.007 <-- 11 Queries, ~10ms
GET host1.com/web HTTP/1.1 200 - 11 0.003 0.005 <-- 11 Queries, ~10ms
GET host2.com/web HTTP/1.1 200 - 11 0.003 0.008 <-- 11 Queries, ~10ms
```
[1]: https://github.com/odoo/odoo/pull/94161#discussion_r904780031 (Also other PR/task but couldn't find those.)
closesodoo/odoo#120364
X-original-commit: 28dd35eb3c681b630f0b3c109a7d8209f9fa42d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] made sure that to be considered active, the current page URL
should have the same query strings as the ones defined in the menu URL
(if any).
But it was not fully accurate as extra query strings on the page URL
would make the menu not active even if the menu URL query strings would
be found in the visited page URL.
With this commit, when trying to determine if a website.menu is active,
we only take into account the subset of menu's query arguments.
For ex, a menu with an url of `/my-page?country=BE` should be
considered active if the request url is:
`/my-page?country=BE&utm_source=marketing-campaign&utm_medium=email`
[1]: https://github.com/odoo/odoo/commit/065ca15closesodoo/odoo#120188
X-original-commit: bc1f2c092122e171950348c3e32438e8b862f231
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Since [1] when the translations were converted to jsonb, when
translations are saved, the actual `ir.ui.view` is saved (instead of a
translation record like before). Because of this, the copy-on-write
mechanism of `website` kicks in and unneeded website-specific views are
created.
This commit disables the copy-on-write mechanism during the update of
translations in views.
Steps to reproduce:
- Install `website_sale`.
- Install a second language (e.g. French).
- Go to a single product's website page in the second language.
- Translate the "ADD TO CART" button.
=> Many website-specific views were created.
[1]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224
task-3225622
closesodoo/odoo#117256
X-original-commit: 1bf7e2322d22aeef30097a1d19848ff351bc83f9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] fixed the editor not being able to start when clicking on a
link that triggers a download. This was caused by the
websiteRootInstance being undefined when a page is about to be
unloaded (beforeunload). Unfortunately, this event can be canceled.
This means that the websiteRootInstance had to be undefined when we are
certain that a navigation is going to happen within the iframe. However,
the condition introduced by [1] does not take into account multiple
factors, which lead to the websiteRootInstance being undefined during
edition.
This commit fixes that and introduces a test to make sure this behaviour
is not easily broken again.
Steps to reproduce:
- In edit mode, on the Home page, go in the footer and click on any link
(except "Contact Us") under "Useful Links" or on the house icon in the
Social Media snippet.
- Change the footer height with the Height option.
=> The option is applied correctly (because the link stays on the same
page).
- Click on "Contact Us" or another Social Media icon.
- Try to change the footer height again.
=> The preview works but when we leave it, we see that the option was
not applied.
- Drop a snippet and click on it.
=> Infinite loading.
[1]: https://github.com/odoo/odoo/commit/e47a9900e4a7842774d33a332b325e1f08c3ca45
opw-3196324
task-3212501
closesodoo/odoo#114366
X-original-commit: 15a17656b42442b40f4476efe8c985a9ba28ff93
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Co-authored-by: Soukéina Bojabza <sobo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
To reproduce the issue:
- Website (edit mode) > Drop a snippet with icons (e.g. "Steps").
- Open mediaDialog to change an icon.
- Select the same one (or click immediately on "ADD") > This will set an
empty icon (without any "fa" specific class).
The code on `MediaDialog` > `save()` adds CSS classes from the original
icon to the new created one then removes the old 'fa' classes from it.
(see `initialIconClasses`), as a consequence, the class will be deleted
(not replaced) when the selected icon is the same as the old one.
The goal of this commit is to fix this behaviour by simply closing the
dialog if the selected icon remains the same as the old one.
task-3210472
closesodoo/odoo#114345
X-original-commit: 0515e987b985622bc7b913dbbb37c0d0cd69eb4b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
As the public user, browse the website where you usually should see some
profile pictures (e.g. inside the forum). All the images are wrongly
replaced by the grey avatar placeholder.
When using `ir.binary._find_record` it was checking the access rights
and raising `AccessError` early even if the record was
`website_published`.
closesodoo/odoo#113526
X-original-commit: 0611fb437b699588317919e72ccfa1c41f1245bc
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
