Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Add an "Image Gallery" on the website.
- Add a new image on the snippet.
-> Problem: the thumbnail of the first image of the carousel has been
replaced by the new added image.
To solve the problem, the triggering of the `image_changed` event has
been removed on extra image added. It was introduced by [1] to trigger
the re-rendering of the thumbnail when adding a new image on the
carousel but was actually useless. Indeed, the mechanism was the same as
now; when a new image was added on the carousel, the
`website.gallery.slideshow` that already handles the thumbnails was
re-rendered. An important thing to note is that the system was also
never intercepting this `image_changed` event as it was triggered on an
element that was not in the DOM (as it was removed at the
`_replaceContent()` call in the `slideshow()` method). However, since
[2], the images rendered by the `website.gallery.slideshow` are replaced
by the images (or the wrapped anchored images) returned by
`_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM
and the `image_changed` event is intercepted by the gallery option. As
the active carousel item is always the first one of the carousel after a
`website.gallery.slideshow` re-rendering, the system changed the
thumbnail of the first item with the new added image.
[1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87
[2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481
task-3736301
closesodoo/odoo#153717
X-original-commit: 3c4239212e7bedc3cb49f34d9eb0a23c3de0cbd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Steps to reproduce:
- Add an "Images Wall" snippet on the website.
- Add a link on the first image.
- Add a new image on the wall.
-> Problem: the first image does not have a link anymore.
When adding an image or reordering the images on a wall, the system
re-renders the snippet (see `nomode()`, `masonry()`, `grid()`) by adding
each images on the wall structure. The problem is that the system only
takes the images into account and not a possible image wrapped into an
anchor. This is now fixed as the system renders the images or the
wrapped anchored images returned by `_getImgHolderEls`.
The process is a bit different when adding an image or reordering the
images of an "Image Gallery" snippet. In this case, the system
re-renders the `website.gallery.slideshow` template. The problem here is
double: First, the template does not take a possible wrapped anchored
image into account. Second, there are only few image attributes that are
rendered by the template.
This leads to a new problem:
- Add an "Image Gallery" snippet on the website.
- Add a "Blur" filter on the first image.
- Click on "move to next" to move the first image at the second
position.
-> Problem: the image option does not show the filter and it is now
impossible to change some image options such as "Filter", "Shape" and
"Quality".
To solve those two problems**, the images rendered by the
`website.gallery.slideshow` template are replaced by the images (or the
wrapped anchored images) returned by `_getImgHolderEls`. By doing so,
the rendered images have the correct attributes (so the options can be
correctly displayed and modified) and they are still correctly anchored.
This commit also adapts the `snippet_images_wall` test. An extra trigger
had to be added on the `Select footer` step to ensure that the last
image of the wall has been inserted before clicking on the footer.
Without it, the tour fails as, if the moved image is in the first
position, the tour only waits for this image to be inserted in the wall
and then clicks on the footer. When the wall is completely built, the
focus is automatically done on the moved image and the step
`selectSignImageStep` fails to execute as its `extra_trigger` condition
(`.o_we_customize_panel:not(:has(.snippet-option-gallery_img))`) is not
met.
**: In this 16.4 forward-port, the second problem is not entirely fixed.
The task-3717041 will handle it.
opw-3535829
opw-3573135
closesodoo/odoo#152365
X-original-commit: e73a1a96dcf8786c01205ae0a97b10e38ab9afeb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When fields are submitted through the website form, their values are
used as they are. Because of this it is possible to include HTML in the
sent email while this is not desired.
To avoid this, this commit HTML-encodes the values received for custom
fields and html fields.
Steps to reproduce (with default_field):
- Go to the "Contact us" page with form untouched (it should send mail)
- Fill in the form
- In the name put John <b>Smith</b>
- Submit the form
- You will see that Smith will be in bold in the received mail
Steps to reproduce (no default_field):
- Install website_recruitment
- Go to the "Contact us" page
- Enter edit mode
- Change the form type to apply for a job (and select a job to apply in
the right panel option, like "Consultant")
- In debug mode in the backend, go to ir.model fields
- Find "Applicant (hr.applicant) record and edit it
- Remove the website_form_default_field_id in the "Website Forms" tab of
the form view of this record
- Back to the "contactus page", add a new custom field to the form
- Now, out of edit mode, add "<b>Something</b>" in the custom field and
submit the form
- Find the job application in the backend in the recruitment module, it
should be inside the "Consultant" job.
- You will see the "Something" in bold in the chatter
Note: In Odoo 16.2, commit [1] is already doing something similar for
one of the 2 places fixed here.
[1]: https://github.com/odoo/odoo/commit/3e7acff8d9302c3332fe3011f75374170484c61d
task-3650953
closesodoo/odoo#152170
X-original-commit: c2e934f421a8afee4ce537b1e03871a1bcef99d1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Bram Van Gaal (brvg) <brvg@odoo.com>
Co-authored-by: bram1000 <brvg@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit:
`destroyLinkTools` function sets the selection to entire link. However, in
case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be
updated correctly, also one could not change the a tag of a single element
within the link.
After this commit:
`destroyLinkTools` selects the `anchorNode` and the `focusnode` of the
selection instead of entire link.
task-3245819
closesodoo/odoo#151752
X-original-commit: e88ffecc4bdb0480fc1d47af14558f28f72a665d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit was written for Odoo 16.4 and then backported.
In Odoo 16, only point 2. described just below is not working.
The 16.4 commit was thus retarget to Odoo 16 as it was also fixing the
second point.
------------------
Before this commit:
The website selected in the website selector of the search view in the
website.page list/kanban view was always set to the first one found in
the DB and was never:
1. the one you visited in the website preview
2. or the one matching the URL of your backend.
But 1. was working fine before commit [1] from the frameworkjs which
introduced a way to "reset" the screen between apps/menu switch.
Despite 1. working before commit [1], it was not ideally coded and
worked "by chance", see below for a few facts and explication.
------------------
Fact 1:
When you have multiple websites and you are on a website, the website
served is the result of 2 possibilities:
1. All websites have a specific domain, then you can only see a given
website on its own domain. Attempting to select another website in
the website switcher will redirect you to that other website domain.
2. You have one or more websites without any domain, then you can see
those ones from any domain by using the website switcher. It will
force the website in session, and despite being on a domain which
should serve a given website (the one which has its domain set that
domain if there is one), it will serve you the one you selected in
the website switcher.
Fact 2:
- It is the `website_preview` which is setting the currentWebsite
property of the `website_service`.
- But the `website_service` can be used on its own, without any
`website_preview` being involved in the process.
- When the website preview is unmounted, the currentWebsite from the
website service is reset to null.
- The website page list component is reading the currentWebsite from the
website service.
- When switching from the website preview to another menu like the
website pages list, the page list component (PageControllerMixin) is
actually initialized/created before the website preview is unmounted.
In the end, the following happen:
1. Go to website preview -> it sets the website service current
website
2. Go to website page list
3. The website page list component reads the current website from the
website service which is set
4. The website preview is unmounted, emptying the current website from
the website service
5. The website page list is shown to the user
6. Any call from the page list component to the current website will
now be "wrong" / not return the same as during its `onWillStart`,
as website preview was unmounted just after that, emptying the
website set in the website service. Luckily, there is none.
Fact 3:
Commit [1] changed the order of the steps listed above, now 4 occurs
before 3, so when the page list component reads the website from the
website service, the unmount of the website preview already kicked in,
emptying that website service website.
This is the source of the bug fixed here: the current website could
never be found anymore.
-----------------
This commit is simply finding the current website_id by asking it to the
server.
It will fix point 1. listed at the very beginning of the commit message,
but will also make point 2. work.
Another solution would have been to find a workaround to the frameworkjs
change (like investigating the `noEmptyTransition` option) to restore
what we had before, but it would have been as "fragile" as before and
wouldn't have fixed other flows as the current fix does.
----------------
Steps to reproduce 1:
- Without any domain set, go to your DB in the website preview of your
website in the backend
- Switch to the website 2 in the navbar website switcher
- You are now viewing website 2 in the website preview
- Click on "Pages" in the "Site" menu to go to the page list view
- The website selected in the search view is the first one, not the
website 2. Also, the page shown are from the website 1, not the
website 2.
- This was working before commit [1] and this commit is fixing that.
But this commit is also fixing/improving flows which never worked:
- Before commit [1] (or in Odoo 16 to be simpler), do the same 4 first
steps as above.
- You will see that the listed pages are the ones from website 2 and
that the selected website is the second one, correct.
- Now just reload the page, it will show website 1, despite the website
2 being forced (if you did reload the page on the preview, it would
still show website 2).
- This is because the website_preview was never involved after the
reload since you reached the list view / website service without going
through the website preview.
- The same can be seen if you go to the Pages list view directly through
CTRL+K, in which case you won't go through the preview.
--------------------
Note that the chance is taken to reorder the wutils export, it was
becoming a real mess and it was not possible to easily read through the
method names to find/guess something.
------------------
[1]: https://github.com/odoo/odoo/commit/9f6ed9f6d1ef7ec1870980498480cae0ffc729d8
Related to task-3676124
opw-3658648
closesodoo/odoo#151269
X-original-commit: 0128beed551395b30f957a5edc1a23a6f3d0ba31
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the problem:
- Add a "Countdown" snippet on the website.
- Save.
- Enter in edit mode again.
-> Problem: the `destroy()` of the `CountdownWidget` public widget comes
from a `widgets_start_request` that is triggered when the
`WysiwygAdapterComponent` has been mounted and patched (see
[useEffect documentation]). The problem is that, as the widgets are only
destroyed at this moment, it is possible that a widget could replace an
element that has been modified during the instantiation of the
`WysiwygAdapterComponent`. For example:
- At the `onWillStart()` hook of the `WysiwygAdapterComponent`, the
`o_editable` is added on some elements.
- A widget could then replace one of these elements.
- The widget is destroyed after the rendering of the
`WysiwygAdapterComponent`.
-> The `o_editable` class is not on the element anymore.
The goal of this commit is to, as before [1], destroy the existing
widgets before instantiating the `wysiwyg`.
This commit also adds a test to ensure that the order of the calls to
the widgets and wysiwyg lifecycle methods is coherent.
Related to runbot-28700
[1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826
[useEffect documentation]: https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useeffectclosesodoo/odoo#151411
X-original-commit: 723c0dfeb7d39ca2522e65cf021664aacfc7099c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds translation capability to custom snippets.
Before this commit, the custom snippet was not translate friendly:
1. Neither when saving a block as custom snippet
2. Neither when dropping a custom snippet into a page.
This was a known limitation for years. But now it's time to make it
work.
Step to reproduce (part 1):
- Enable french
- Drag & drop Title snippet in a page
- Translate the Title
- Save the block as custom snippet
-> Go in the backend view of this custom snippet, in debug, there is no
translation that followed the title.
Step to reproduce (part 2):
- Following previous steps, now add the translation manually on the
custom snippet view
- Back in a page in edit mode, drag & drop this custom snippet in the
page
- Switch to french
-> The title is not translated, the drag & drop copy code but no
translations
Those are the "page/view" to "page/view" translation transfer, but it
could also be any html field (like a product description) to view
(custom snippet) or view (custom snippet) to any html field.
task-3375518
opw-3242100
X-original-commit: 2bd6c1a8d653453692211eef0f5d46a0047eb6f2
Part-of: odoo/odoo#150945
*website
Steps to reproduce:
- Drop a "Text-Image" snippet on the website.
- Click on a column and hide it on desktop.
- Click on the parent snippet and hide it on desktop.
-> The column is not a child of the parent in the invisible entry.
Since [1], invisible snippets are shown hierarchically in order to
better visualize the "parent-children" relation that could exist between
them. To do so, [1] based its logic on the `.o_snippet_invisible` to
find the invisible elements. However, since [2], a distinction has been
made between elements that are hidden only on desktop, only on mobile or
on both depending on some conditions. The goal of this commit is to take
the new `o_snippet_mobile_invisible` and `o_snippet_desktop_invisible`
classes into account at the creation of the invisible entry.
[1]: https://github.com/odoo/odoo/commit/922d3e63b597b1ef7fbbb5ebb4641a3ad8bdf4ed
[2]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3679823
closesodoo/odoo#150512
X-original-commit: c8f247ee5fa178f012b2852cba3d0e9322a2c3a6
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
*: web_editor
Commit [1] made the multiple drag and drop feature of the editor stop
using jQuery and used our own implementation. Unfortunately, the
initialization of that implementation in the case of the "drag column
on image move" feature marked the page as dirty by mistake.
Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the image of the snippet (and do not do anything else)
- Click on discard
=> A popup appears to say you will lose your changes... while you did
not make any.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
Related to runbot-18747
Part-of: odoo/odoo#148728
*: web_editor
Next commits will extend the main new test to make sure the flows they
are fixing are not wrongfully marking the pages as dirty. This commit
introduces it on its own as it deserved some more detailed explanations.
In 15.0, where this commit is being merged, the final version of the
test was failing for no apparent reason on staging only. This is because
the staging builds are made with more apps... which fill the website
menu with more items in such a way the "+" auto-fold menu feature comes
in play. That feature is marking the page as dirty by mistake in this
version, 3 different ways for 3 different configurations:
- the menu is not folded outside of edit mode and when entering edit
mode, the "+" appears and some menu are folded
- the menu is folded outside of edit mode and when entering edit mode
the resize actually makes it so a different set of menu is folded
- the menu is folded outside of edit mode and when entering edit mode
it stays the same (known to have been broken because edit mode
tweaks the dropdown behavior)
The first problem with this is actually the way we check the page is
dirty in case of discard: we check the whole DOM and compare it to the
way it was when entering edit mode... the whole DOM, including the non
editable parts. This is wrong by definition but it is also weird that it
does not match what is done when we *save*: where we only consider
sections that are explicitly marked as dirty (.o_dirty) and other
exceptions. This can't be changed in stable though, some save / discard
override may rely on this (not marking with the o_dirty class etc).
In 15.0, the original commit of this forward-ported version fixed the
3rd case described above, which was less risky than fixing the 2 others.
The cause for the DOM diff in that case was the `data-toggle="dropdown"`
which mysteriously reappeared between the moment we check the "initial
DOM" and the "DOM when we try to discard". This was because of [1],
which makes the dropdowns behave differently in edit mode, combined with
the fact that the "+" menu is re-rendered after each resize (and one is
triggered when entering edit mode since [2], originally for that
actually). That behavior is however apparently not needed for the "+"
dropdown, so we simply disable it. Some lower level fix is still needed
but will be done in master, as the real problem falls in the dirty page
detection system. A test was added for this specific third case.
In 16.0, this is different: all 3 cases seem fixed, probably indirectly
thanks to the website-in-iframe refactoring at [3] and the bootstrap 5
migration at [4]. Not sure. This forward-port commit thus only adds
tests and a bunch of comments. Note that what was said about the 15.0
version was actually not entirely true: "That behavior is however
apparently not needed for the "+" dropdown, so we simply disable it." is
actually wrong. Indeed, it changed the behavior when clicking *outside*
of the extra items menu (which is less important). A patch in 15.0 will
be backported anyway to explain that.
To make the final test pass, it ensures most menus are removed so that
the "+" feature is basically disabled always during the test. Behaviors
will of course be fixed in further versions.
Note that in this 16.0 forward-ported version, a test kinda already
existed for this... although it was badly written and the code that was
merged with it actually worsened the dirty check behavior. See [5].
This commit adds comments around some more problematic parts.
[1]: https://github.com/odoo/odoo/commit/fe67b34f1a03d838df82a1307cf6467f994a8f3b
[2]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[4]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[5]: https://github.com/odoo/odoo/commit/650a97d1bd59254cc2115d54d58940b6112a8d70
Related to runbot-18747
X-original-commit: a0b741a53fef6a2a15d9283397dd7ec22d624382
Part-of: odoo/odoo#148728
Since [this other commit], the recipient email option of the form on the
`/contactus` page is not filled correctly with the company email.
By chance, the form signature task fixed the bug but introduced another
one. The previous commit fixed the bug introduced by the form signature
task but reintroduced the inital bug. This commit fixes the initial bug
and adds a test.
By default, the form on the `/contactus` page sends emails to the email
address of the company. Unfortunately, before this commit, when a user
entered edit mode, the Recipient E-mail option always displayed
"info@yourcompany.example.com" even when the company's e-mail address
was different. This commit corrects this by displaying the dynamic value
of `company.email` in the Recipient E-mail option coming from the
data-for.
Steps to reproduce the issue fixed by this commit:
- Go to Settings > General Settings
- Update the company's email address
- Go to /contactus and edit
- Click on the form
=> The recipient email value is still "info@yourcompany.example.com"
instead of the company's email address.
This commit fixes the issue, adds a test to ensure the recipient email
option is correct and adds a utility to parse the data-for data.
Bonus: this commit also fixes the following issue catched by sentry:
- Go to /contactus
- Click on Edit
- In the Form option, remove the content of the 'Recipient Email' field.
- Save
- Fill and submit the form
=> An error is generated in the log.
[this other commit]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
task-3382195
sentry-4633940473
closesodoo/odoo#147933
X-original-commit: 56f6b8dccec5cebc9a93454538b39886d4d3f63c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The email_to field of the contactus form have to be dynamic except if
the user manually set it via the form options. Unfortunately, the
website signature task broke this feature. This commit fixes it and adds
a test to prevent this regression in the future.
Steps to reproduce the bug:
- Go to the contactus page
- Edit the page
- Add a field on the form
- Save the page
- Change the company email address via the settings
=> The contactus form still send the email to the old email address.
Related to task-3382195
X-original-commit: 10b4db60fbd077936b5c9586485fa40c3c890d3f
Part-of: odoo/odoo#147933
This commit is fixing a last minute error in commit [1] after a push
force which move its code above the existing line `vals['url'] = url`.
After the code move, `vals['url']` was not the updated url value (which
went through slugify and unique path functions).
- Create a /test page, publish it.
- Set /test as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /test_un
-> The page url is /test-un but the website homepage_url is still
/test_un (not slugified) in the website settings
[1]: https://github.com/odoo/odoo/commit/374a1b31f70a3209b1ae11db8e5886350579c7f9closesodoo/odoo#147641
X-original-commit: 3c8a58b654418fc2fc0dc9bc28420c7dcb1bafee
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- Create a "/test" page, publish it
- Set "/test" as homepage url directly on the website (in the settings)
- Go to that page
- Open the page properties and change its URL from /test to /else
From there, the website setting (`homepage_url` field) was still set to
/test and not /else.
It means that the first "published" menu would then be used to avoid
serving a 404 as homepage to your visitors.
It is a bit confusing and people probably just expect to change that
website setting too when changing the page URL.
We had some feedback about similar flows (that couldn't be reproduced or
where people weren't sure) where people ended up writting on the wrong
page or losing their content.
Maybe this will mitigate the issue.
Kind of related: task-3476840
closesodoo/odoo#147086
X-original-commit: 374a1b31f70a3209b1ae11db8e5886350579c7f9
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The `test_01_multi_domain_assets_generation` was introduced in PR [1].
But afterward, the commit [2] introduced a unique constraint on the
`domain` field. With this additional constraint, this test broke when
run with multiple existing websites as it assigns the same domain for
each of them.
This commit made the dummy domain assigned in this test non-unique,
which doesn't alter the original meaning of the test but, allows to run
it with multiple existing websites.
[1]: https://github.com/odoo/odoo/pull/118526
[2]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d
runbot-20848
closesodoo/odoo#146666
X-original-commit: 0c522e42a82ec596e69611c556c4fc0d50e6e978
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit the clean_assetbundle could unlink invalid
attachment, mostly when generating a no website assetbundle with
a different version than a website one, the website assetbundle will be
deleted.
Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439)
Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440)
Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%%
The issue is that %-%/ will match 439-b4c80c3/1/ and not only
439-b4c80c3/
Note that it looks like this issue existed for a while but was invisible
because before 16.4 clean_attachment was invalidating the ormcache,
hiding the fact that a still valid asset was deleted and regenerated.
The proposed fix replaces the domain with %-_______/. The unique is
always 7 character long. Note that this change was already made in 17.0
when removing the id from the asset url so this doesn't need to be
completely forward-ported.
opw-3558552
closesodoo/odoo#145452
X-original-commit: 2ac466547e01bfd65415a53ae1efc9d45d9299fb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).
Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page
- Click on the Team block
=> The user is able to drop a "Text highlight" block next to the team
member pictures.
This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.
[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
opw-3536227
closesodoo/odoo#144806
X-original-commit: 9b4c2498b8fa2bc0aca604b6256e6c805b9b4c10
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
For multi language website, when request http:/localhost/en/something,
Odoo reroutes from the requested path /en/something to the new path
/something with lang=en_US in context.
If the new path is a unicode string like http:/localhost/vi/xin-chào,
http:/localhost/ru/привет, a error should occur at
werkzeug._compat.wsgi_decoding_dance() because the path was not latin1
string.
The utf-8 encoding followed by a latin-1 decoding is required by the
WSGI specification[^1]. latin-1 is used as an encoding passthrought:
that encoding has a representation for all the 256 bytes, i.e. it is
impossible that decoding a text will raise a ValueError. The WSGI spec
uses this trick to save values until the actual charset (present in
the Content-Type header) in known.
[^1]: https://peps.python.org/pep-3333/#a-note-on-string-typesclosesodoo/odoo#143898
X-original-commit: 9b69b87c08b1d62b3581fe651bee692a4f217dff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When using the "Social Media" snippet, there are two situations leading
to a traceback. Here are the steps:
1) First issue
- In edit mode, drop the "Social Media" snippet.
- Add a new social network.
- Replace the icon by a real image (so not by an other icon).
- Set the URL of the new social network to a "relevant" one (e.g.
google, facebook).
=> traceback
2) Second issue
- Drop "Social Media" and change the list in order to have the first
social network with a real image as icon: either replace the first icon
with an image, or add a custom one with an image an move it to the top.
- Add a new social network.
=> traceback
Both issues happen because only icons set as `<i>` elements are taken
into account when modifying a social network (`querySelector('i')`) and
this element may not exist if the icon had another tag (like an image or
a span or even a video (as the media dialog allows to upload them)). As
there is no check ensuring that the element exists before changing the
different social media classes, there is a traceback when the `<i>` is
not found.
For the first issue, it happens because when changing the URL, we first
check if it matches with relevant ones or if an icon matching it exists.
If it is the case, we then update the social media classes to set the
matching icon => it can only work if the icon is a `<i>`.
The second issue happens because when adding a new social network, it
actually copies the style of the first one (unless there are none, a new
one is created in that case). If the first one is an image, it fails
when updating the classes because it is not a `<i>`.
This commit fixes these issues by simply adding checks ensuring the icon
element exists before trying to modify it. It also adds tests, ensuring
these use cases work as expected.
opw-3538230
X-original-commit: 0132fa38baee6501f4257dad718359400f1369ad
Part-of: odoo/odoo#144076
A custom script is modifying the output of
load_information_from_description_file to disable the
auto-install of modules during local testing. It was naively adapted for
v16.0 by replacing the corresponding methods. Since a lru cache was added
(nice optimization in most cases) this is an issue because running lint
test afterward will get the cached value with an incorrect autoinstall
value. It makes sens to avoid reading the file on the filesystem each
time, but making a deepcopy looks like an acceptable safeguard to avoid
hard to debug behaviors.
closesodoo/odoo#143628
X-original-commit: ad10ff4410ccf7c38f6154480484495bb57c53ff
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The "reset password" feature does not take into account
multi-website.
steps to reproduce:
- create a website A
- uncheck 'Shared Customer Accounts' on website A
- create a portal user user@example.com on website A
- create a website B
- uncheck 'Shared Customer Accounts' on website B
- create a portal user user@example.com on website B
- reset password for user@example.com on any website
before this commit:
An error is raised "No account found for this login"
(which is false, actually 2 accounts are found)
after this commit:
Only the user linked to the current website is properly
selected
opw-3551540
closesodoo/odoo#142110
X-original-commit: a2196253d6cf90dca3042a777703e0679f74f542
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1], when an error exists in an asset, the assets raise a not
found exception. The issue, is that, there is no feedback for the
developer to find the error.
Now, a new console log with the error details is shown.
[1] : bf3b6b0b8bclosesodoo/odoo#141705
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Previously proposed formating was trying to normalize extra in one part
of the path. This means that no extra needed a placeholder.
The implementation was meant to be more generic and extendible since a
part of the logic has to be in website.
A suggestion was made to make it more restricted but explicite by
keeping the url simple in web/controllers/binary.py but adding a
controller in website to add this extra part.
The base extra direction is now in the extension, as the min part.
Initial urls:
/web/assets/{unique}/[{website_id}/][rtl/]{bundle_name}[.min].{extension}
New urls:
/web/assets/[{website_id}]/{unique}/{bundle_name}[.rtl][.min].{extension}
Managed by two routes:
/web/assets/<string:unique>/<string:filename>
/web/assets/<int:website_id>/<string:unique>/<string:filename>
Where filename is in the format {bundle_name}[.rtl][.min].{extension}
Multiple possibilities where proposed
- /web/assets/website/<int:website_id>/<string:unique>/<string:filename>
More explicit but prefixing by /website was considered
- /website/assets/<int:website_id>/<string:unique>/<string:filename>
This one is a litle painfull to match similar attachement, where
website is ignored.
- /website/<int:website_id>/assets/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
- /web/assets/<int:website_id>/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
This last solution was not ideal to match without unique
/web/assets/%/<string:filename> can match both
/web/assets/123456/<string:filename>
and
/web/assets/1/123456/<string:filename>
Anyway, matching without unique shouldn't be supported for al (even if
it is kind of supported with any right now) but it will work by changing
unique wildcard to a more specific one (_ * 7)
closesodoo/odoo#131353
Related: odoo/enterprise#47313
Related: odoo/design-themes#730
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The generation inside the rendering has some drawbacks:
- `commit_assetsbundle` is needed for reports rendering because the
template rendering may generate some assets that will be accessed by
another transaction before the transaction is committed. But this
solution is not ideal since the transaction is committed in the middle
of the request
- when the first rendered page is a 404, the assets are not committed
and the page is broken.
- when starting, deleting an attachment can create a concurrent update
error and the request is retried. This will occur once per attachment
and for all worker trying to access the same resource. The whole
transaction is rollbacked, even the previously created assets bundle.
- The cold page load is a slower since there is more work to do.
- Implementing a readonly request is difficult because it could be
transformed to read write and re-executed if the assets bundle does not
exist.
Generating assets when needed solves those issues. The concurrency
when deleting an assets could still occur but only once per bundle, and
in a smaller transaction. This could be solved with a lock now that we
have more control on the transaction. The commit_assetsbundle can be
removed and 404 page should have a correct layout. The cold page load
could be a little faster because the assets bundle can be generated in
parallel requests instead of sequentially when rendering the page.
Part-of: odoo/odoo#131353
The main motivation is to be able to generate assets bundle outside
the t-call-assets call.
The need of an id in the url makes it mandatory to have an attachment
when adding the url in the page. Without this restriction, we can guess
the url without generating the assets.
This can also have other useful side effect:
There are corner case when a worked could have an invalid url in
cache because, if the transaction is rollbacked or if another request
generates the same attachment at the same time. This should be
partially solved by removing the id: The url remains valid even if the
attachment does not exist.
Note that the extra part of the url was made explicit, always there and
taking one / to remove complexity and ambiguity.
Note that an additional query appeared in .test_50_perf_sql_web_assets
because of the search, this but two of them were in _find_record. One of
them was an `exist`, not making much sense since we are not getting the
id from the attachment url anymore but from a search, and the other one
was prefetch of the "public field" since the call to _find_record does
not go in other cases (xmlid, website published, access token, ....). A
attachment of a asset is always public, and this part of the security
was moved to the search domain. The final result is one less query:
- one query to search
- one query to read the fields (_get_stream_from) (the prefetch could
actually be set to avoid prefetching everything)
Part-of: odoo/odoo#131353
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>
qsm-odoo