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>
Since [this commit], it is possible to have a block only displayed on
mobile screens. This feature can break the steps snippet by following
these steps:
- Drop a steps snippet in a page
- Set the third step to be visible only on mobile
=> The connectors are broken.
This commit fixes this issue by only considering steps that are visible
in desktop view for connectors drawing.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
closesodoo/odoo#113184
X-original-commit: d8521d197518e90d63443d1095b2df84487ad4ae
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From [this commit], it is possible to define the visibility of blocks
according to the device on which the page is displayed (either hide on
mobile, or hide on desktop). This change has brought two problems on the
table of content block:
1. The sub-component s_table_of_content_main (the right part) can be
invisible, which does not make sense.
2. The sub-component of s_table_of_content_main can be invisible but it
did not change the navbar of the TOC.
This commit prevents hiding the main part of the TOC and rebuilds the
navbar of the TOC according to the device visibility of its
sub-components.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
X-original-commit: b7f9c26a93e58f2ace964ab6b05132cc9f8f3366
Part-of: odoo/odoo#113184
By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view
=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).
The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).
[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3116227
opw-3135927
X-original-commit: f2b86dda77133ed9c4f02394693e771758d18bad
Part-of: odoo/odoo#113184
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>
Changing numeric values using the keyboard arrows did not work on some
fields. This commit solves this problem by adding the necessary
attributes to the numeric (we-)inputs.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's we-matrix.
The fields that make up the list trigger a preview at each input and the
user can navigate through the matrix with the keyboard.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's lists. The
fields that make up the list can trigger a preview and it is possible to
switch from one field to another using the keyboard. Note that the
social media we-list must render at each blur of one of its inputs, so
this we-list does not allow to switch from one input to another with the
keyboard.
As the we-list events changed, the social media block tests had to be
slightly modified to take these changes into account.
task-2601533
Part-of: odoo/odoo#81241
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The redirect function in the router exists only for the wait option.
This option is only used in one case (client action home). We have
therefore decided to remove the redirect function and to call
browser.location.assign(...) directly.
We will also remove the "wait" param for the "reload" and "home"
client actions. Because no call to "reload" needs it (1) and all calls to
"home" want it wait=True. So we will move the code that was executed
if wait=true to the "home" action client.
(1) In the POS, wait=true is used for a "reload" but this has no impact.
Wait=true was intended to wait for the server to restart before reloading
the page. In the case of the POS, there is no restart of the server, so
wait=True is useless.
closesodoo/odoo#112621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
See previous commit, it fixes a bug introduced by a recent change in the
javascript framework that broke the website kanban override.
This commit is ensuring that the kanban can be accessed and used.
Ideally, it should have been a QUnit test but since this has to be
merged ASAP (critical bug) and a test is more than welcome as it's not
the first time our custom kanban is broken, a hook in an existing tourµ
is used to easily and quickly test it in the meantime.
closesodoo/odoo#112369
X-original-commit: aca72bcdae98e1304c934f67efa65273d636863a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since [1], an error was raise because the xpath to add an if attribute
: "//div/t/t[2]/KanbanRecord" wasn't precise anymore and was applied to
the wrong KanbanRecord, removing the correct attribute.
Now a more precise xpath is used.
[1]: https://github.com/odoo/odoo/commit/fa20b8de642fc57e5c6a49ca77c28d4aab150df9
X-original-commit: bc4776d8f532f2c5882bdac1c72ac95c5ade6be9
Part-of: odoo/odoo#112369
*: website_slides
In some cases, components had dark text over dark background (or light
text over light background) by mistake.
Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
body color instead of the expected boxed layout color.
Another example:
- Do the same thing (set up a dark color behind a boxed layout).
- Go to a shop / product page.
=> The inputs are dark with dark text.
This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the first case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.
In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs.
In previous versions, this fix focused on fixing a critical component:
nav-tabs, for which the fix was straightforward.
Starting from 16.0, this commit will fix everything at the small risk of
changing the `$body-bg` variable meaning in the case of boxed layouts.
Before this commit, its meaning was "the color used for the background
behind the boxed layout (the <body> background color)", so equal to the
Odoo value `o-color('body')`. After this commit, its meaning will be
"the color used for the background of the box itself", so equal to
`o-color('o-cc1-bg')`. The `<body>` background color will be forced by
using `o-color('body')` as the value for the related *CSS* variable
defined by bootstrap. This allows to have a correct CSS generation for
all components in case of boxed layouts: indeed, the components mix
their own color with `$body-bg` (or use it as it is) relying on the fact
this is the color which appears behind them... which was not right in
case of boxed layouts.
This commit actually fixes another bug that was found during adaptation.
It is 2-fold, and unfortunately, it does not make sense to fix one part
without the other as it would increase the problem without the other
part. The website_slides pages customize their default background color
to not be the one chosen by the user, but a mix of it with some
lightgray. Odoo default for the body being white, this makes it a
lightgray for website_slides pages. This is totally ok... but only in
"full" layout. In boxed layout, we have the 2-fold problem:
A. The mixed color is not applied to the boxed layout but on the
background behind the box. So if you have a white box above a black
background, in website_slides pages you won't have the black
background you expected to keep but a lighter version of it and the
website_slides box will not use the lightgray but stay white
(creating other inconsistencies as the lightgray would also be used
by other components like tabs, for that app only).
B. The mixed color is actually not mixing the right colors: it mixes
the hardcoded lightgray with the color of the background behind the
box, while it was intended to be the one of the content (the one of
the box), like in "full" layout.
The changes explained above about `$body-bg` naturally fixes (B). Not
fixing (A) at the same time would result in a big change for the color
which is behind the box. This commit fixes it at the same time by now
applying the color to the right element. In previous version, this could
be fixed as well but would require a different fix (not relying on
`$body-bg`). So it makes sense to merge this first and backport+adapt.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c
opw-3151962
closesodoo/odoo#112254
X-original-commit: 14c985af526602a88666714e716283650521e537
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
The editor offers bootstrap tooltips, but these were not all initialized
and therefore appeared as standard HTML tooltips. This commit fixes that
by initializing all the tooltips so that they all have the same style.
Details:
- The bootstrap tooltips are now available in translate mode.
- With bootstrap 5, only one bootstrap component can be initialized on a
HTML element. This is why the tooltips are now initialized on the
first child when there is another bootstrap component.
- Some tests have been adapted.
task-2777738
closesodoo/odoo#85666
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website now being displayed in the backend of Odoo (since [1])
within an iframe. To be able to send events inside this iframe, the
`PublicRoot` widget from within the iframe is "captured" (using the
`OdooFrameContentLoaded` event). This is used to send events to Public
Widgets such as notifying them that the edition is about to start, so
they need to reload in edit mode.
Prior to this commit, the WebsiteRootInstance would be set to
`undefined` when the page was about to be unloaded (`beforeunload`
event). This is useful as this prevents the editor to start in an
inconsistent state if a user clicks on a link or changes page and clicks
edit too soon.
Unfortunately, the beforeunload event can be canceled.
Two ways this can be noticed:
- On firefox, enter edit mode and edit the page
- Try to close the tab
- A browser dialog is displayed asking the user to confirm if they want
to leave the page
- This is done using the beforeunload event
- It is triggered in both the iframe and the top window on firefox when
trying to close a tab
- Clicking on cancel won't allow you to resume the edition as the
`websiteRootInstance` was set to `undefined`
- On any browser, enter edit mode
- Upload a document using the media dialog
- Save
- Click to download the document
- Try to enter edit mode
Clicking on the link triggers a `beforeunload` as the browser is about
to leave the page. The browser somehow detects a download and cancels
the beforeunload. But the `websiteRootInstance` was already set to
undefined.
This commit fixes that by only setting the websiteRootInstance to
undefined in some context:
- When clicking on a link that will result in navigating inside the
iframe
- When changing website
- When the `WebsitePreview` component is asked to reload the iframe
- Doing it again when a `pagehide` event is triggered.
This last one is only for safety (e.g. if a widget within the iframe
triggers navigation which leads to a pagehide). Though using this event
is often too late, as the editor has time to start but often not fully,
and destroying it so early can lead to tracebacks.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3046473
closesodoo/odoo#112048
X-original-commit: e47a9900e4a7842774d33a332b325e1f08c3ca45
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
*: website_event
Since [1], it was not possible to customize the SEO values of an event
sub-page because a condition was inverted by mistake. Opening the SEO
dialog on those sub-pages actually displayed (and allowed to save) SEO
values related to the event main page.
[1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1
Related to task-3129034
closesodoo/odoo#111289
X-original-commit: 2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The page properties and optimize seo menu items were not explicitly
marked as not shown for non-designers. An unrelated bug currently hides
those items by chance... but as that bug will be solved in a further
commit of this same PR, it had now to be explicitly hidden in that case.
Note that after this a related bug remains: the "This page" title on
top of those sub menus is left visible if no sub menu is shown and
clicking on it actually crashes. That bug will be solved in another PR.
Also note that it might make sense to show the optimize seo dialog for
restricted editor users when they have the correct rights... but this
would be an improvement to consider in master.
Related to task-3129034
X-original-commit: 26c46ba70bac227c2b6a28a941e5c4f13bfe9029
Part-of: odoo/odoo#111289
Before 16.0 and the website-in-backend refactoring made at [1], the
publish button of the frontend had this behavior:
- The record is unpublished
- Click on the publish button -> a rpc to publish is sent but the
switch visual state is not updated (the internal checkbox is still
unchecked)
- The rpc comes back with the response -> the switch visual state is
updated (red -> green)
This is actually the behavior since the bug fix made at [2]. The main
point of this commit was to prevent toggling the checkbox while its
javascript behavior was not initialized yet.
From 16.0, that loading problem is not an issue anymore, as the publish
button is instantiated client side and thus only appears when it is
possible to use. We can thus update the visual switch state as soon as
the user click on it for a better UX. However, that was flawed:
1. If the publish action actually failed, the switch was kept
checked/unchecked while it should be reverted to unchecked/checked.
2. If you clicked very fast multiple times on the button, many RPC were
sent and their result order was not guaranteed.
3. There is no possibility for tours to wait for the actual publish
action to be done... and that will be needed in a further commit of
this PR.
This commit fixes all those flaws:
1. If the RPC fails, we now revert to the status before the user clicked
on it. Inspired by [2], the internal checkbox is now disabled, which
leaves its status entirely up to OWL instead of browser behaviors.
2. The switch now stops listening to clicks while a RPC is being
performed.
3. While a RPC is being performed a "data-processing" attribute is added
to the whole switch area.
Note: in master, the whole switch system should be reviewed. The publish
button one's structure actually makes no sense: a <div> which contains a
<a> which contains a <label> (already invalid DOM), with the <div> being
the event handler of the switch status changes...
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/2e751d80dd4b23abf374d5aa488827faaa593e62
Related to task-3129034
X-original-commit: 36a8fe44d6ec609a9bad8d960768766a44d4074e
Part-of: odoo/odoo#111289
This commit adds a new feature to the web editor of a website. A "text"
input field has been added to the link editor panel, allowing users to
edit the label of a link.
The label will only be updated when the input is changed, to prevent
loss of formatting (e.g. if one letter is bold).
However, only formatting applied to the entire selection will be kept
(e.g. if you have a "link <b>like</b> this", nothing will be in bold if
you update the label in the editor panel).
Additionally, if there is a media element (such as an image or icon)
included in the selection, the "text" input will be hidden.
task-2900529
closesodoo/odoo#99239
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website
When changing the padding of the grid items with the `Padding (Y, X)`
option (when the grid mode is toggled), depending on these items
content, the effects are not always visible.
This commit adds a highlight effect on the grid items when the padding
is changed, to better show the changes being made.
task-3058630
closesodoo/odoo#111584
X-original-commit: f3f2c4c73ce08d3898b8c88e1ef045f7bbd1f624
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit "parallax" animation was not working in modals.
This commit adds a parameter to the animation effects to enable
animations (triggered by the scroll) in the modals.
Note that for the "Newsletter" popup we have hidden the "parallax"
options. To make them work, it would be necessary to review the
structure of the "Newsletter" popup so that the vertical scrollbar is in
the same location as the "s_popup" snippet (on the ".modal" element).
task-2971402
closesodoo/odoo#111424
X-original-commit: f369686c1b74219968746a0f0a164dd6b3c5cfc6
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
The "All Websites" list of views is confusing for users with its
combination of default and specific views.
This commit makes the "All Websites" filter only available in debug
mode, and defaults the selected website on either the current website
(if one is selected) or the first website of the list.
The test is adapted because only the current website's pages are
displayed now.
task-3092786
closesodoo/odoo#110898
X-original-commit: 01cb743f1c0c22621bcfa92005a7d10dfa92e746
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
When entering edit mode on the website and discarding directly, the editor
considers that there are changes in the DOM and displays a confirmation modal.
After this commit:
When entering edit mode on the website and clicking directly on discard, the
confirmation modal is not displayed.
Task-3056463
closesodoo/odoo#110515
X-original-commit: 650a97d1bd59254cc2115d54d58940b6112a8d70
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Dhaval Baraiya <dhba@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
This basically reverts [1].
After discussion with the related team, [1]'s purpose was to prevent
merging two links together if backspace was hit at the beginning of one
mega menu item. [1] however made mega menu creation impossible as it
prevented removing any mega menu item (well, you had one possibility if
you used Chrome which was to unlink the mega menu item and then remove
it via backspace but...).
After some more discussion, we decided that allowing to merge mega menu
items seems not bad (it is the same behavior as the rest of the editor
when two links are next to each other). In any case, being able to
remove default mega menu items is more important.
[1]: https://github.com/odoo/odoo/commit/9779145d9157e9687c36d2caa0ecea2862a2ac5a
opw-3109946
opw-3120070
closesodoo/odoo#109804
X-original-commit: 7de359470fb4d8eb81f018262a5e4c66a71c7043
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the title attribute on navbar items.
The title was only repeating the content so it was useless.
closesodoo/odoo#109230
Task: 3097276
Related: odoo/enterprise#35562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When editing a website form, a `search_read` request is fired on
`ir.model` model to get the list of possible form actions (create
ticket, create opportunity, etc.).
But since commit [1] in Odoo 15, non-admin users don't have read access
anymore on this model, leading to a traceback when clicking on a form in
edit mode.
Steps to reproduce (as designer):
- Install only website and login as admin
- Make "portal" user an internal user and give him "Editor and Designer"
rights
- Login as "portal" user
- Enter edit mode on any page and drag & drop the form snippet, or
simply go to /contactus page which already has one
- Click on the form -> Traceback
Steps to reproduce (as publisher/restricted editor):
- Install website_hr_recruitment
- Make "portal" user an internal user and give him the following rights:
- Website: Restricted Editor
- Recruitment: Administrator
- Login as "portal" user
- Go to a job page like /jobs/detail/experienced-developer-4
- Enter edit mode and drag & drop the form snippet
- It will crash
[1]: https://github.com/odoo/odoo/commit/5dc4cff60a557e14b08440c227423291c407899b
opw-3098097
opw-3101884
closesodoo/odoo#109339
X-original-commit: 054c216e93b818794316bfd4b8ce56d6853a61d3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Cannot be used in v16 since some mixin don't exist anymore.
After 4 odoo versions, and now that we use bootstrap 5, we drop the
support of bs3.
closesodoo/odoo#109359
X-original-commit: 2c34fd4f031b006451305c46b99a790540c5e902
Signed-off-by: Adrien Dieudonné (adr) <adr@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
This commit allows to debounce the events of the RangeUserValueWidget so
that the user can use this widget with the left and right arrows without
having a lag effect (especially on the image quality option).
In addition, steps were added in the website_gray_color_palette tour to
let the time for the debounce to trigger the changes.
task-2601533
closesodoo/odoo#109165
X-original-commit: dddec7489f5cb4e48368684a8783015517c394ee
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before this commit, the popup snippets were configuring the modal option
for bootstrap 4 rather than 5.
The `data-focus` in bootstrap 4 becomes `data-bs-focus` in bootstap 5.
Without `data-bs-focus` option, the Newsletter popup snippet became
uneditable because any click inside popup changed the selection to be
inside the first focusable element within the modal.
The reason of the input being focused is: upon click inside the modal,
the target of the focusin event is the parent of the modal because that
parent is contenteditable="true". Because that target is outside the
modal, `_handleFocusin` correct the selection by focusing the text
input.
task-3102155
closesodoo/odoo#109148
X-original-commit: bc99f3cdb5c2fca59a24dc4970c9ca6e69721838
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since 2013 we have a kind of a URL hack that allows to redirect to the
initial URL after installing a lang through the website, see [1].
It was even tested in python unit test with [2] but sadly it was still
broken by a combination of [3] and [4] which actually broke it at the
javascript level: the python view was correctly still outputting the
correct URL and the python part was correctly handling that return URL
when passed, but the javascript was not actually passing the URL from
the view/href to the python side as the lang install wizard was now
called through JS instead of a normal backend URL redirect (since the
website frontend > backend imp at [4]).
Step to reproduce:
- Go to any page other than the homepage
- Click on footer > add a language
- Add a language
- You are redirected to the homepage always instead of the URL you came
from
Note that this is only true if done through the backend / iframe preview
as clicking on the "Add a language" from the frontend will work as it
should. Indeed, when clicking on it from the frontend, it's a simple
link redirect but when click in the iframe preview, the click is
preventend to let the JS open the action in the top window instead.
[1]: https://github.com/odoo/odoo/commit/5cfbcc3aff5a28022b397ec7a28ebaca6db43673
[2]: https://github.com/odoo/odoo/commit/269aa594111a152ad4b7714856ea745bfef57155
[3]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
[4]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#108869
X-original-commit: 05caf6e697461176326ee61beeccb1193472267c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
After [1], most snippet options should use something like
`this.$target[0].ownerDocument` to access the document properties
instead of the global object `document`. This is because the editable is
now inside an iframe.
Commit [2] tried to adapt most occurrences but missed some.
This commit adapts the leftover code and fixes 2 bugs:
1. The SCSS Variable `font` wasn't properly reset when deleting a Google
font that was currently being used, resulting in a `/` being displayed
and the variable having an inconsistent state.
2. In the Chart snippet, the color being used to represent data is
displayed inside the option as a border on the input widgets. It was
currently using Odoo's colors instead of the ones defined in website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2978623
X-original-commit: 6e0bd78e59b8352d15c9f21bf5f891924d6c3c9f
Part-of: odoo/odoo#108819
When `link_tools` was introduced at [1], `_onURLInput` did only update
the configuration form and did not touch the edited DOM. Even though its
name would be misleading for that purpose, it was therefore used without
issue as an event handler responding to the configuration form input
events and as a private method called in the `start` method of the
widget lifecycle.
At a later stage, with [2], DOM modifications were introduced in
`_onURLInput` (using the misleading `_adaptPreview` method whose
refactoring at [3] made it update the configuration form only in the
case of the "Link Dialog" but update the actual link DOM for the "Link
tools" (website / mass mailing)).
This commit fixes that behavior by touching what is strictly necessary
in stable to keep the original intend of `_onURLInput` (updating the
configuration UI) but at the same time update the DOM following
configuration form input events (as intended by [2]).
In master, all of this should be reviewed.
Here are steps which revealed the problem. Although, meanwhile, [4] and
its parents were merged which fixed other parts of this issue but
keeping the potentially problematic DOM update on selection as described
above. Notice that [4] and its parents may be reviewed further in a
future update.
- Edit Home page
- Drop a "Banner" block
- Select the "Contact Us" button
- Select "Custom" style in the link tool
- Select a fill color
- Deselect the button by clicking on the Banner's text
- Select the button again
=> Button is redrawn without its color
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
[2]: https://github.com/odoo/odoo/commit/226c4c4032c26d3d8f622b29fb151fa8e78ba70a
[3]: https://github.com/odoo/odoo/commit/4a1d776243b059d423152bd026bb8bc758477224
[4]: https://github.com/odoo/odoo/commit/eb4edac560227b46efdcfe958e3b93e0b88def64
opw-3086198
task-3096806
X-original-commit: da25eadde299b81b78d84678978b7e1f703530cc
Part-of: odoo/odoo#108812
Co-authored-by: qsm-odoo <qsm@odoo.com>
The "website_gray_color_palette" tour recently failed 4 times during
staging build on runbot, out of those 4 caught times, it seems that:
A) 3 were because the last step was marked as failed too soon
(screenshots and logs seem to indicate the editor was still loading).
B) 1 was because of a "random" asset error (traceback when lazy loading
the editor JS).
The cause of (B) was not found and should be later investigated if seen
again. This commit tries to avoid (A) which is probably related to a
known issue: when the website iframe has to reload it may sometimes take
more time than is allowed by the default timeout of tour steps. Some
improvements regarding that will be made at [1] and probably by further
PR after that (improving the editor loading speed in general).
Meanwhile, this commit reviews the tour to not save the editor as it was
actually not needed in this tour (nothing has to be saved).
[1]: https://github.com/odoo/odoo/pull/100122
runbot-14112
closesodoo/odoo#108747
X-original-commit: fa1819f09948c64ff7acf634eed075515f6a01d2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To reproduce the issue:
- Website > Edit mode > Add "Share" block > Save.
- Click WhatsApp > Missing space between page title and its URL.
Starting from [1], the `$('title').text()` value was replaced on "Share"
snippet by `document.title` (which will trim and collapse whitespaces
in the page title). This leads to a missing space between page title
and the shared URL.
After this commit, the correct spacing is restored.
[1]: https://github.com/odoo/odoo/commit/ddb2c06be4196c86ff6a2fd74874487d75b31c94
opw-3084367
X-original-commit: e7e9eb4f806680b19f3ec61fb080316a3160e7fb
Part-of: odoo/odoo#108724
The last two parent of this commit introduced fixes towards the Snippet
Cache, more specifically, the snippet cache according to the snippet
language.
Commit [1] introduced a Snippet template "Cache" that keeps the snippet
templates in memory throughout multiple instantiation of the
SnippetsMenu. Unfortunately, while this improved performance, it also
introduced bugs where the cache was not properly cleared. Starting
the edition in translate mode, then switching back to master edit mode
would sometimes lead to the Snippets being loaded in the wrong language.
The parent commits fix that but this one introduces a test to make the
snippet cache and translation more robust.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-52a4f9d2c217548e69e6b7fd097f286f1754a6389734eea254b87255e501cbefR18closesodoo/odoo#108643
X-original-commit: a066dc8319cc9c204656a25af16fc78ae618cd71
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: mass_mailing
When images are dropped from outside the browser into a website page
text paragraph, they are stored as an inline base64-encoded source.
This commit marks those images to be saved as attachments when it
happens in website. The save happens upon page save similarly to what is
done when images are transformed.
This commit also applies this behavior for pasted images.
task-2928495
closesodoo/odoo#98801
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Note: this bug is not possible to reproduce in 16.0 anymore, since the
Bootstrap 5 update. This commit is however kept as it makes the behavior
more efficient keeping the original fix's diff + it also cleans things
that were not necessary anymore since the "website-in-backend" update
that was made at [1].
Steps to reproduce the bugs (in older versions):
- In edit mode, choose the "contact" header template.
- Drag and drop a table of content snippet on the page.
- Save the page.
- Click on the table of content links.
- Bug => the links are not activated correctly.
The reason of the bug was that the scrollspy offset (calculated against
the header height) was not updating when the header height changed.
We did make a new call to scrollspy at the right time but that had no
effect because we first had to destroy the existing scrollSpy to be able
to make a new call that works.
opw-2951315
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#108223
X-original-commit: edd9d2b3df597786b2db416aed382dc5666623e2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the steps block options could not support a column
that was more than nine out of twelve (bootstrap columns) wide.
Steps to reproduce the bug:
- Drop a block step on a page
- Set a width of 10 columns on the first step
- Set a width <= 2 columns on the second step
=> the connector is not well displayed.
task-3033126
closesodoo/odoo#108362
X-original-commit: 9c4e0eaa60ad89140661e3c297ea1b4e22d6faae
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website
The fields of a form that are mandatory because of the model they need
to be used in cannot be removed. When such a field is selected, the
remove button displays a tooltip giving this information.
Disabling the overlay button is done by removing the specific class -
which makes the event selector not linked to the button, but also
impacts the applied CSS rules.
This commit adds an `o_disabled` CSS class upon disabling the button.
The tooltip is put on a `span` that wraps the disabled button because
tooltips cannot be shown on disabled elements.
Steps to reproduce:
- Drop a "Form" block.
- Select the "Phone Number" field.
- The overlay's delete icon has a reddish background.
- Select the "Your Email" field.
=> The overlay's delete icon had a dark gray background instead of a
reddish one.
task-2950433
closesodoo/odoo#107864
X-original-commit: ed3acbae6a6b2fe91c948ceeb16a5bdb3fa8f060
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, following this flow:
- Add a form
- Add a selection field
- Add an option starting with a number
- Save
=> The created form's option value is only the number
From the website_form options, the options HTMLElement of a form field
are generated using the field's records ids for their html element value
attribute (see FormEditor._renderField).
When [1] refactored the website_form options to use a generic
ListUserValueWidget, the list records id computation changed to use
parseInt instead of strings.
This commit changes the detection of parsable int to match only strings
that are made only of digits, and less than 16 of them so that their
value is not lost.
[1]: https://github.com/odoo/odoo/commit/9304f8fa7bb94f21dd4caa83f9679ffd1642691b
opw-2980760
closesodoo/odoo#108248
X-original-commit: 166f4aa4d23a01901585b60d69fac47fe70b7ebe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
This commit mitigates an issue with shape elements sometimes having tiny
spacing on their top or bottom edge.
This issue is mainly on Chrome when the user has changed the page zoom.
When the page is zoomed the elements can have a width value with a
decimal part. Because of it, the size of the SVG background images are
not correctly rounded compared to their container and therefore leaves a
visible space.
Steps to reproduce the bug:
- On Chrome, add several shapes on a website page.
- Change the zoom of the page and change the window width.
- At some points, the gap will appear.
The least bad solution we found to fix this is to ensure that the width
of the shape elements is always as close to an integer as possible.
Reminder: several commits had attempted to fix this before ([1], [2],
[3], [4]). But that wasn't enough to stop it happening. Some shapes
still need to be fixed although that will likely be done in future
versions.
[1]: https://github.com/odoo/odoo/commit/c0f62593a4da37e8404dddc0a5762879a5ebbf7f
[2]: https://github.com/odoo/odoo/commit/ac82407b259eab929486bf0a333a48bc507efa60
[3]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
[4]: https://github.com/odoo/odoo/commit/e386f318f5cff50901dba3db8a2587911ba02a6e
task-2824607
opw-3069213
opw-3057533
X-original-commit: 623db525e18931a4dd5794da78be840afc34991a
Part-of: odoo/odoo#108228
Before this commit, following this flow:
- From the documents app, click on the "share" icon of a document,
- In the website builder, in edit mode, paste the link in the link
tools,
- Save and click on the link,
=> There is a traceback coming from cross-origins errors with the iframe.
These documents should be opened in the top window, as it does not make
sense to open the pdf viewer inside the iframe. This is defined in the
website module, to avoid creating a website_documents module just to
patch the WebsitePreview._isTopWindowURL method.
[1]: 44da4bf
task-2687506
closesodoo/odoo#107860
X-original-commit: 2e8fce06cbe4e2d24dd80eca1c59a9d44d181d30
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Louis (loco)