Steps to reproduce the bug:
- Go on a product image and replace it by a ".jpeg" (note that the
mimetype of the image is "image/webp" since [1]).
- Change the format of the image and put it to "Original". The mimetype
of the image is now "image/jpeg".
- Add a shape on the image.
- Change the format of the image.
-> None is displayed as its format.
Let's first recall that adding a shape on an image transforms its
mimetype into an "image/svg+xml" and that the `originalMimetype`
attribute is used to record its original mimetype. This is needed in
order to correctly reset the image mimetype when removing its shape.
The problem here was that the `originalMimetype` attribute was not used
correctly and that the mimetype of an image with a shape was not
correctly updated at format change.
[1]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d
task-3431015
closesodoo/odoo#129680
X-original-commit: 40811e72c50faf146ccdf9f26c332db9ebc69fa9
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
*: web_editor, website
The goal of this commit is to add the reorder option on the carousel
slides. Because the option is now shared between the "Carousel", the
"Image Gallery" and the "Images Wall" snippets, a common super option
(`GalleryHandler`) has been created to handle this reordering.
task-2930786
closesodoo/odoo#117369
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
*: web_editor, website
Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".
When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.
Upgrade PR: https://github.com/odoo/upgrade/pull/4767
task-3287330
closesodoo/odoo#123873
X-original-commit: c82d01f7532b5b120bedfbc40bf8f2f07d750ed6
Related: odoo/upgrade#4767
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
For background images, modifying options such as "Filter" does not
directly lead to the modification of their corresponding data attributes
in the DOM as those modifications are done at the save request. This
should not be the case. The goal of this commit is to, as for regular
images, modify their corresponding DOM data attributes at the option
update.
Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Replace the background image by one of your own.
- Add a filter to the background image.
- Inspect the Cover snippet.
=> The `data-gl-filter` attribute has not been added in the DOM and you
have to click on "Save" for it to be actually added.
task-3287330
X-original-commit: ed19a1e91a2706b157532778b15d4a581a4da0e2
Part-of: odoo/odoo#123873
Steps to reproduce the bug:
- Add a cover snippet on the website.
- Change the background image with one of your own.
- Save and edit again.
=> Options such as "Filter", "Width" and "Quality" do not appear
anymore.
The problem is that the `src` attribute of the background image is not
correctly updated when initializing the image. This is because the
target used to recover the URL of the background image is the snippet
and not the image itself. This problem is resolved by ensuring that the
argument of the function `getBgImageURL` is the background image. Now
that the `src` attribute is correctly updated, the `computeVisibility`
function of the the `BackgroundOptimize` option works properly and the
options "Filter", "Width" and "Quality" are displayed as wanted.
Note that now, the dataset of the target is filtered with a "white list"
(BACKGROUND_IMAGE_ATTRIBUTES) before being copied in the dataset of
`this.img`. Indeed, if the parallax is set to "None" for example, we do
not want data attributes such as `data-snippet` to be copied in the
dataset of `this.img`.
task-3287330
X-original-commit: 4356917d0d5cfa560794e4a0464c6ebc9a5ff3e7
Part-of: odoo/odoo#123873
Steps to reproduce the problem:
- Drop a popup snippet in a page.
- On another language, click on translate.
- Problem -> It is impossible to translate the popup.
To resolve this problem, the function `_updateInvisibleDOM` is called
even in translation mode. Thanks to this function, the invisible
snippets are now filled in the edit bar and the user has the opportunity
to display them or to hide them.
task-3098517
opw-3268592
opw-3283140
closesodoo/odoo#125078
X-original-commit: c76ff023b84da65d90b7967c91adde4bd777265b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*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
Steps to reproduce the bug:
- Add a form snippet on the footer of the website page.
- Change the visibility of the form snippet to "conditionally".
- On the footer settings, deactivate the "Page Visibility".
=> The form snippet is still present on the "Invisible Elements" panel
but clicking on it has no effects. Indeed, it is inside the footer which
is hidden.
The goal of this commit is to reorganize the "Invisible Elements" panel
in order to better visualize the hierarchy between the different
invisible elements. To do so, the list of the invisible snippet elements
(`[...$invisibleSnippets]`) is scanned. Each invisible snippet that is
the descendant of another is discarded of the list (to only keep the
"root" ones) and a map is created with its `keys` set to invisible
snippets that have invisible descendants. The `value` corresponding to
an invisible snippet element is a list filled with all its descendant
invisible snippets except those that have a closer invisible snippet
ancestor. The list of the root snippets is then scanned. Each root
snippet is inserted in the DOM as well as their descendant snippets
found thanks to the newly created map.
Note that thanks to this commit, another problem is solved:
- Add a cookie bar on the website.
- Add a Text-Image snippet and change its visibility to "conditionally".
- Save and edit again. Note that the "Cookies Bar" is above the "Text-
Image" on the "Invisible Elements" panel.
- Click to display the cookie bar.
=> The order of the "Cookies Bar" and the "Text-Image" is switched on
the "Invisible Elements" panel.
Indeed, before this commit, the order of the snippets was influenced by
the order of their snippet editor creation. Because this order was not
always the same from one call to `_updateInvisibleDOM()` to another, a
glitch could happen when toggling a snippet visibility.
This is now fixed as the order of the invisible snippets in the
"Invisible Elements" panel is determined either by their order in the
list `rootInvisibleSnippetEls` or their order in the lists contained as
value in the map `descendantPerSnippet`.
task-3203914
X-original-commit: 548e95b3dc9bf642c5eea3fc43b83f7ce282be0b
Part-of: odoo/odoo#123027
Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.
Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.
[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce
opw-3246341
closesodoo/odoo#122782
X-original-commit: ccaf4f1e52f10308ef507059316732c02ad6e6e4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.
opw-3246341
X-original-commit: 34b3770ad1ee9c872acaf4f82ac3c6cf52d5d333
Part-of: odoo/odoo#122782
The goal of this commit is to fix the race condition introduced by
[this commit]. Here were the problematic steps:
- Open the mega menu.
- When then mega menu is opened, scroll up.
- Open the mega menu after scroll.
Before this commit, what could happened was that the mega menu did not
have enough time to be closed after the scroll. Clicking on it would
then actually close it rather than open it as wanted. This commit adds
a step to ensure that the mega menu is closed before open it.
[this commit]: https://github.com/odoo/odoo/commit/9b1de9e28697edbb6e1fa88665294f983f60e37f
runbot-20660
closesodoo/odoo#119438
X-original-commit: abd0038de73a057eb9c34dc8d316b67d96fac409
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery snippet on a the page.
- Stay in edit mode and click on one of the arrows (left or right).
- Bug -> The arrow disappears.
This bug comes from the fact that the "oe_edited_link" class is added
to the anchor of the arrow when clicking on it. Because of the scss
related to this class, the position of the arrow is modified. This bug
is fixed by adding the "o_not_editable" class to the anchor of the
arrow. By doing so, the "oe_edited_link" is not added to the anchor of
an arrow when clicking on it.
task-3147271
closesodoo/odoo#118383
X-original-commit: 92f2a50bbabaa387f557ef8e728796c3b3e6410c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Go on the blog of the website.
- Edit.
- In the "Customize" section, apply the "List" "Layout" and activate
the "Sidebar".
-> The sidebar appears at the bottom of the page instead of on the
side.
The situation looks like this:
```html
<div class="container">
<div class="row">
<div class="col"></div>
<div class="border-end"></div>
<div class="col-12"></div>
</div>
</div>
```
The bug comes from the fact that the `div` with the `border-end` class
is inside a `row` class. Due to that, a bootstrap 5 css rule applies
and puts the `width` of the `div.border-end` element to `100%`. Because
the element tries to fill the entire width of the `div.row`, it is put
at the bottom of the page as well as its following elements (in this
case, the sidebar). This bug is fixed by removing the `div.border-end`
element.
opw-3217775
closesodoo/odoo#117849
X-original-commit: 9d8b895b934e5b0986c932837fd043cf847a8992
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Steps to reproduce the bug:
- Add multiple images on a product page
- Go to the shop and edit an image of this product by double clicking
on a small image on the carousel thumbnail
- Save
-> Nothing happens and the image is not updated
The goal of this commit is to ensure that a field of type image is not
`readonly` before adding the `contenteditable` attribute to its image.
task-3122670
closesodoo/odoo#114598
X-original-commit: 36fb7654b785888f100d5163e6cebd788c3c042a
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.
The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.
Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.
opw-3133464
closesodoo/odoo#114472
X-original-commit: 6ae5d73332d5413495cc25e28cba86f8be18b570
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the user had the possibility to spam the "Log in"
button when trying to connect. This could lead to a change of the CSFR
token and an errror of type "werkzeug.exceptions.BadRequest: 400 Bad
Request: Session expired (invalid CSRF token)" could then happen.
This commit makes the “Log in” button un-clickable once it has been
clicked and adds a loading effect to it.
task-2996329
closesodoo/odoo#114226
X-original-commit: e6273856b2f5ef13c5cf965ae79b830498beaa5a
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Steps to reproduce the bug:
- On the website application, add an image gallery snippet.
- Change the "Speed" parameter.
- Save.
-> Nothing happens: The displayed image is always the first one and
there is no cycle between the images of the snippet.
Since Bootstrap 5, the amount of time to delay between automatically
cycling to the next item is defined by `data-bs-interval`. The bug
comes from the fact that some parts of the code still used the old
parameter name (`data-interval`).
opw-3165570
closesodoo/odoo#113423
X-original-commit: 8368fa1f5e45a14ed8938017b2da90a810dbf0c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The first objective of this commit is to polish the website
configurator:
1) On page 1 of it: - The size of the text is increased.
2) On page 2 of it: - The font size inside dropdown is reduced.
- 30 results are displayed inside dropdown instead
of 15.
3) On page 3 of it: - The size of the text is increased.
3) On page 4: - The cards are refactored.
- The end line is removed.
- The "Build my website" button is moved to the left.
4) On page 5 : - It is now impossible for the user to click on a theme
preview before it is completely loaded.
5) On all pages, the size of the "Skip and start from scratch" button
has been increased.
On the second page of the website configurator, the user has to choose
an industry type. Sometimes, it happens that the user is searching for
an industry that is not known by the server. Before this commit, a
message of type "No result found" appeared and the user had to choose
an other industry among the existing ones. From this commit, the
"No result found" message is replaced by the name of the industry that
the user is writing. To choose its industry type, the user can click on
the displayed industry name or outside of the input area. This last
option calls the `_blurIndustrySelection` function and the written
industry is kept as the final industry choice. If the user chooses an
industry name that is not known by the server then the remaining of the
website configuration is done with the "abbey" industry. Moreover, this
unknown industry name as well as the language used by the user is sent
and stored to the IAP database. The goal of it is to regularly update
the industry list so that it becomes as most complete as possible.
IAP PR : https://github.com/odoo/iap-apps/pull/549
task-3062171
closesodoo/odoo#110187
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Facebook" snippet inside the "Table of Content".
-> The page is blocked.
This may happen with other snippets than the facebook one (e.g. the
image gallery or the countdown).
A mechanism that interests us here is the mutation observer. Up to this
commit its goal was to regenerate the navbar of the TOC when its DOM
content changed. In practice, since [1], a "widgets_start_request"
message was triggered up each time there was a change of the TOC
content. In the case of the Facebook snippet, this behavior led to an
infinite loop. Indeed, when the Facebook snippet was dropped inside a
TOC, its content changed so a "widgets_start_request" was triggered up.
This message led to the execution of the start function of the TOC but
also of the start function of the Facebook snippet. Because there is a
change of the DOM in this last function, the mutation observer
triggered up a "widgets_start_request" message again that caused the
program to loop forever.
The goal of this commit is to regenerate the content of the navbar only
when its content changes. To do so, the content of the navbar before
the change of the DOM is compared with its content after the change of
the DOM. If those two contents are different, it means that the navbar
should be updated. Thanks to this commit, it is now possible to add
dynamic snippets such as "Facebook" or "Countdown" inside the TOC.
With this in hands, another bug appeared:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Text-Image" snippet on the page but not inside the TOC.
- Drop a "Countdown" snippet inside the "Text-Image".
- Drag the entire "Text-Image" snippet with "Countdown" and drop it
inside the TOC.
-> The page is blocked.
This bug comes from the fact that the drop of a snippet that stands on
the page inside an other snippet leads to the destroy and the restart
of the option of the outer snippet. However, in our case, the mutation
observer was still listening to DOM changes even after the destroy of
the snippet option. This led to parasite function call. This bug is
fixed by disconnecting the mutation observer when the option is
destroyed. Note that this is done in [2] as this was a problem in older
versions as well.
[1]: https://github.com/odoo/odoo/commit/a05f782871c61b2d58ca2fd4277cb7aed65a301d
[2]: https://github.com/odoo/odoo/pull/112960
task-3122249
opw-3164969
opw-3173006
closesodoo/odoo#113070
X-original-commit: 9139b27ee9216f4b6111d0596f101d4927b493b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.
Related PR: https://github.com/odoo/odoo/pull/110860closesodoo/odoo#113075
X-original-commit: 3787599479d2f1e951bca6622c7049b62d631795
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, trying to delete a page from the page manager in
debug mode would throw an error of type "Got duplicate key in
t-foreach".
As explained in this commit [1] and as per the [owl documentation]:
"Owl requires the presence of a t-key directive, to be able to properly
reconcile renderings." and "A key should be a unique number or string."
In our case, "dependency_value" is an array. Due to that, the current
item of the "t-foreach" iteration is the current value. The bug is
fixed by ensuring that the value of "t-key" is the current value index
and not the value itself.
[1]: https://github.com/odoo/odoo/commit/0d1c263298ca6724a6fe6c31e2a2d3221c5e8c75
[owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loops
task-3082345
opw-3100483
opw-3111671
closesodoo/odoo#109329
X-original-commit: f56d5906f845cb45f88d9729b73aa2ed08c551f3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Install the "Surveys" application.
- Go to the "Website" application.
- Go in the page manager ("Site" > "Pages").
- Select a page (typically "Home").
- Try to delete it.
- Error of type "'survey.survey' object has no attributes 'name'".
The error comes from the fact that records do not necessarily have the
attribute called "name". To fix this error, this commit uses
"display_name" that is defined in all models.
task-3082345
opw-3100483
opw-3111671
X-original-commit: d5aa5d7ebf9cd17a6df054252a1313ec8b85e83e
Part-of: odoo/odoo#109329
Steps to reproduce the bug:
- Add a "Table of Content" on the website.
- Try to save a "Block" of the table.
- 14.0: you get an error message.
- 15.0: it keeps loading forever.
- 16.0: you get a white page.
Users should not have the possibility to save part of a snippet. The
goal of this commit is to ensure that the save option applies on a
snippet. If it is the case, the user has the possibility to save it. If
not, the user does not have the opportunity to save it.
opw-3056913
closesodoo/odoo#108002
X-original-commit: 5f28c7d9a04c46d570b13766eaaa90e755008623
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit enables the use of the option "All pages" when using a popup
snippet.
Steps to reproduce the bug:
- Drag & drop a popup snippet.
- On its option in the right panel, there is "Show On" set by default
to "This page".
- Try to modify this option and select "All pages".
Bug observed: The "All pages" option can not be selected and the "Show
On" stays on "This page".
This commit has been done because since the version 16.0, the footer is
on an iframe [1]. Because of that, the program does not have a direct
access to the footer. This is why it is needed to first access the
top-level document before using the querySelector.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2983822
closesodoo/odoo#107236
X-original-commit: f469385dcfcbd9290c3522422f9e10600bb60b76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Louis (loco)