pengyuthon/odoo_source
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
169,760 Commits 1 Branch 0 Tags
da287cc2f71a47c4f00aeea5aa3a549e5ffe029c
Commit Graph
4498 Commits
Author SHA1 Message Date
Benjamin Vray dfe0466e47 [FIX] web_editor, website: fix undo after enabling hover effects. 
Steps to reproduce the bug:

- In Website edit mode, drag & drop a text-image snippet onto the page.
- Click on the image of the snippet.
- In the image options, select "On Hover" for the "Animation" option.
- Click on the "Undo" button in the top bar of the editor panel.
- Bug: The "Animation" option has not been deactivated, the "Hover
Effect" is still present when hovering over the image.

task-3495241

closes odoo/odoo#134979

Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
 2024-02-27 11:21:25 +00:00
Benjamin Vray 5d83672e0a [IMP] web_editor, website: preview hover effects 
This commit adds the possibility to preview the various effects
available in the "effect" option for 'on hover' animations when hovering
over the dropdown. The sub-options of these effects are also previewed.

This commit also prevents the user from seeing the different changes
that occur to an image with a shape while changing one of its options
(e.g., changing the shape, previewing hover effects).

task-3495241

Part-of: odoo/odoo#134979
 2024-02-27 11:21:25 +00:00
Benjamin Vray 37599dea0c [IMP] web_editor, website: improve on hover animation 
This commit makes improvements as requested in the following pull
request [1] ("allowing the ability to flip/rotate image shapes" and
"adding an 'on hover' option for animations").

It mainly focuses on refining the code for better organization.

[1]: https://github.com/odoo/odoo/pull/119197

task-3495241

Part-of: odoo/odoo#134979
 2024-02-27 11:21:25 +00:00
Robin Lejeune (role) bb745dd603 [FIX] website: show bg video in RTL languages 
Background videos' dimensions are adapted according to the screen size.
This could lead to the video not showing in RTL languages, because the
computed position was coded for LTR languages.
This commit replaces the `left` and `top` CSS properties with logical
properties to account for language directions.

Steps to reproduce:
1. Add a Cover snippet
2. Add a video to it (use any sample videos from the selector)
3. Save > Check mobile view, video shows fine.
4. Add a Right to Left language to the website (Persian, Arabic...)
5. Switch to the RTL language > Check mobile view
=> video doesn't display properly.

opw-3688660

closes odoo/odoo#155478

X-original-commit: e75ff0792376621f5335a5955ce32a54a1a5c441
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
 2024-02-27 09:35:50 +00:00
Soukéina Bojabza 389856bcd9 [FIX] website: fix duplicated mega menu synchronization issues 
Since PR [1], which redesigned the headers, there are now two navbars:
one for the desktop view and one for the mobile view. This also means
that the different menus are in both navbars at the same time. However,
this causes some issues with the mega menus.

Indeed, since each mega menu is in both navbars, the changes made in one
are also made in the other (since it is a field in the database). This
causes issues when drag and dropping:
- Drag and drop a mega menu element.
- Re-drag it and drop it somewhere else.
=> We notice that the element was cloned and each drag and drop adds a
new clone. Moreover, when clicking on a link inside these elements, a
traceback appears.

This happens because since both mega menus are synced, the drag and drop
clones are also synced and so the dragged element is dropped multiple
times (after each clone).

This commit fixes these synchronization issues by adding the mega menus
only once in the DOM, in the desktop navbar. They are then moved from
one navbar to the other when we open them.

[1]: https://github.com/odoo/odoo/pull/119650

task-3609531
opw-3730165

closes odoo/odoo#146492

Related: odoo/design-themes#756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-26 21:22:46 +00:00
Soukéina Bojabza c32dfae175 [FIX] website: fix the history of some changes in the header 
The changes happening in the header often break the history, because a
lot of them add steps in it while they should not be observed at all.
This results in losing the redo history, having to click multiple times
to undo one specific change or even seeing some intermediate states that
should not be appearing, every time we interact with the header (e.g. by
opening/closing a dropdown or a burger menu, resizing or scrolling the
window).

This commit fixes these history issues by not observing some problematic
changes. Note that this commit only fixes the most "annoying" ones (i.e.
the ones that break things) that prevented the other commits of this PR
to work correctly. A second pass will be needed to remove other useless
mutations (i.e. that do not break things but should not be observed
either). This commit will also need to be backported, as these issues
are also present in earlier versions.

Here are the changes that are not observed anymore:
- When we open/close a "burger" menu (i.e. the "Hamburger menu" or in
mobile view). It was adding a step in the history, so if we opened and
closed it in the middle of a redo, we would lose the remaining "redo".

- When the extra menu is added/adapted. When resizing the window, which
also means toggling the mobile view, if there is not enough space for
all the desktop menus to be visible, they are moved in an extra ("+")
menu (they are moved out when there is enough space). This resulted in
the intermediate state where the menus are not in the extra menu yet to
be visible when undoing at some point, which did not look good.

- When hiding a dropdown by scrolling the page and hiding a hoverable
dropdown by clicking somewhere on the page. When they are hidden this
way, undoing the change that will be done after that would reopen the
dropdown, which could be annoying if the dropdown was a mega menu for
example.

- When showing a hoverable dropdown. This added a step in the history,
and since opening a "clickable" dropdown does not do it, this also
should not be the case for a hoverable one.

task-3609531
opw-3730165

Part-of: odoo/odoo#146492
 2024-02-26 21:22:46 +00:00
Soukéina Bojabza 2d33dc64e9 [FIX] website: consider BS Offcanvas instead of Collapse in header 
With the headers redesign in PR [1], the "collapse menus" (e.g. in the
"Hamburger menu" and the mobile menu) are now `Offcanvas` elements
instead of `Collapse` elements (see `data-bs-toggle="offcanvas"` in the
headers XML templates). As such, when they are toggled, it is now
`bs.offcanvas` events that are fired, instead of `bs.collapse`.

However, the code using these elements and handling these events has not
been adapted and is therefore never executed, which causes some issues.

1) First issue:
- In edit mode, drop enough snippets to have a scroll bar.
- Toggle the mobile preview and open the menu or resize the screen so it
is smaller than the `SM` screen breakpoint.
- With the menu still open, go back to the desktop view or resize it up
beyond the `SM` breakpoint.
=> There is no scrollbar anymore so we cannot scroll.

This happens because the selectors and event listeners managing the
collapse menus and the scroll do not target the right elements/events.
- On toggle, the `overflow-hidden` class should be added on the body to
prevent the scroll.
- On hide, this class should be removed to re-allow scrolling.
=> Here the scroll is prevented by chance thanks to commit [2] but it is
not the right flow.
- On resize, when the screen becomes bigger than `SM`, the collapse menu
should be closed and the `overflow-hidden` class removed from the body
(see the `_updateHeaderOnResize` function).
=> Not happening because the collapse menu selector is not the right one
and commit [2] does not take the resizing into account.

2) Second issue:
- Change the menu to "Hamburger menu".
- Set the background to a dark color (so that the text is white).
- Set the "Header Position" option to "Over The Content".
- Open the menu.
=> The menu is still considered as transparent so the text is dark on a
dark background, making it difficult to read.

This issue was originally fixed by commit [3], by adding the `o_top_menu
_collapse_shown` class when the menu is opened. It happens again because
since the event is not the right one anymore, the class is never added.

This commit adapts the menus public widgets code in order to consider
these `Offcanvas` elements/events and restore the needed behaviors.

Note that the `NavbarDropdown` public widget (added in commit [4]) is
now useless. Indeed, it was added in order to prevent the dropdowns to
be hidden when opened inside a burger menu, but this issue does not
happen anymore when following the steps. It has already been removed in
master by commit [5].

The same goes for the `TopMenuCollapse` public widget, which was added
in commit [6] to avoid having a scrollbar when opening a sub-menu after
resizing up the screen with the mobile menu open. It is not even started
because its selector is not valid anymore (the `top_menu_collapse` id
only exists in the "Hamburger menu", where the issue cannot happen), and
the issue is not there anymore when following the steps, which makes the
widget useless. It will be removed in master.

[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510
[4]: https://github.com/odoo/odoo/commit/ce9b350403ff7c1004b50b39588891ee652e0a3a
[5]: https://github.com/odoo/odoo/commit/39b79832a0cd3e191077a11a485de78365928feb
[6]: https://github.com/odoo/odoo/commit/b7a4538c51aacca666920bdd9496ee575ab12e7a

task-3609531

Part-of: odoo/odoo#146492
 2024-02-26 21:22:46 +00:00
Soukéina Bojabza 9baf37a75b [FIX] website, website_blog, *: fix duplicated navbar ids 
*: test_website_modules

In PR [1], the headers have been redesigned. One of their major changes
is that now, they have two navbars: one for the desktop view and one for
the mobile view.

However, the `o_main_nav` and `top_menu` navbar ids are also duplicated,
meaning that there are multiple elements with the same id in the DOM,
which is not a good practice.

This commit fixes this by replacing the ids by classes in the navbar
templates, since their use does not really require for them to be ids
(e.g. `#o_main_nav` is mainly for styling). For the desktop view, the
ids are still kept (for stability purpose).

Note that the CSS rules and the selectors in the JS files (except for
the tests) now take into account both the ids and the classes (to be
safe).

[1]: https://github.com/odoo/odoo/pull/119650

task-3609531

Part-of: odoo/odoo#146492
 2024-02-26 21:22:46 +00:00
qsm-odoo c91ffa3bdb [FIX] web_editor: prevent crash with some options applied on 404 images 
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]).

closes odoo/odoo#155275

X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-25 08:40:49 +00:00
qsm-odoo ad5875ae0c [FIX] website: restore missing images post upgrade + proper updatable 
Commit [1] introduced default images changes for the website library.
The problem is that the ir.attachment definitions are in a non-updatable
environment by mistake (apparently since forever)... so they are not
updated after update/upgrade.

This commit moves the definitions to its own updatable file, in 17.0 and
above only (ignoring potential other changes that were made in 15.0/16.0
at the time but apparently led to no issue). But this is not enough:
upgraded users will still have those ir.attachment records marked as non
updatable and will thus not be updated. Meaning that the ir.attachment
record will still reference path to images that do not exist anymore
(since [1]) and thus not display anything in related snippets, or worse:
crash on some non-robust-to-404-images options (This will be made more
robust in another update).

Note that, at the moment, we cannot solve this issue by making the
/web/image route not return a 404 but a placeholder image in that case,
for technical reasons (even though it would be consistent as this is
what is done if you try to reach `/web/image/something_with_a_typo`).

It would also be annoying to solve this problem by adding a migration
script inside the Odoo repo itself:
- It would only work if upgraded users do a -u again (unlikely).
- That would mean an upgrade script rotting in the main repo forever.

Instead, this commit chose to restore the removed images so that
upgraded users will be able to use the outdated paths. In master, an
upgrade script will be made (in the upgrade repo) to properly update all
those attachment records and be able to finally remove those outdated
images. Note that this may also be fixed without upgrade script if
non-updatable records whose XML declaration is moved out a non-updatable
area become updatable (under discussion with the framework team... we
will see when this lands in master).

Steps to reproduce:
- Install a 16.0 with the website module
- Upgrade to 17.0
- Drag a "Blockquote" snippet on a page
=> Crash and the image is missing (in the DOM but invisible and
   impossible to edit). Note that the crash itself will also be fixed by
   the later update that will be done to make editor options more robust
   to 404 images.

[1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757

opw-3693055
opw-3723895
opw-3744257
opw-3747348
opw-3749764
...

closes odoo/odoo#155015

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-22 17:46:53 +00:00
Benoit Socias 871b2ecaea [FIX] web, website: further neutralize BS dropdown when editing submenu 
Since [1] when the mega menu were first introduced, to make their
edition possible, the bootstrap dropdown behavior was neutralized by
removing the `data-[bs-]toggle` attribute.

In [2] when Bootstrap was upgraded to version 5.1.3, the
`dataApiKeydownHandler` event handler that is called when up, down or
escape are pressed raises an error if `data-bs-toggle` cannot be found
on a previous sibling of the dropdown. This makes the approach chosen
in [1] incomplete.

This commit avoids this issue by temporarily adding a class that
is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because
the event handler is registered right after the method is defined and
we have no way to access the registered event handlers afterwards.
This makes it impossible to patch the called method from outside, nor
its associated selector.

We cannot simply update the selector that was already patched by [3]
because it is also used by other methods.

A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.

Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.

=> An error dialog was displayed.

The same issue happened with a nested menu instead of a mega menu.

[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc

task-3614926
opw-3741670

closes odoo/odoo#155019

X-original-commit: 48f0c4203ceb5e770fed6193bd6382690b1b62fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
 2024-02-22 16:24:01 +00:00
qsm-odoo 019aeb057b [REF] website: temporarily disable problematic test step (4) 
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.

Of course, a solution will have to be found to re-enable that step.

Note: this commit was not needed in previous version.

runbot-57204

closes odoo/odoo#154679

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-20 14:57:30 +00:00
qsm-odoo 61b22e4081 [REF] website: temporarily disable problematic test step (3) 
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.

Of course, a solution will have to be found to re-enable that step.

Note: this commit was not needed in previous version.

runbot-57204

Part-of: odoo/odoo#154679
 2024-02-20 14:57:30 +00:00
qsm-odoo f49fa7f832 [REF] website: temporarily disable problematic test step (2) 
See parent commits for more details. These commits disable the remaining
problematic steps in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.

Of course, a solution will have to be found to re-enable that step.

Note: this commit was not needed in previous version.

runbot-57204

Part-of: odoo/odoo#154679
 2024-02-20 14:57:29 +00:00
qsm-odoo 4ac006d434 [IMP] website: mark check steps with isCheck: true in link tour 
Related to runbot-57204

X-original-commit: 072a94f81b6d24e3ec1a823826753b46d65a8847
Part-of: odoo/odoo#154679
 2024-02-20 14:57:29 +00:00
qsm-odoo 4558fc2687 [REF] website: temporarily disable problematic test step 
See parent commit for more details. This commit disables the remaining
problematic step in the test_15_website_link_tools test, so that it can
be re-enabled on runbot.

Of course, a solution will have to be found to re-enable that step.

runbot-57204

X-original-commit: 60b2b182473beaa4e338d8345f8aa4a5984336dd
Part-of: odoo/odoo#154679
 2024-02-20 14:57:29 +00:00
qsm-odoo 034d78b316 [REF] website: unify link_tools test 
The test `test_15_website_link_tools` associated with the 'link_tools'
tour has been problematic for a long time. Many fixes have been made
already, mainly [1] but also [2], etc.

As of today, the test now succeeds 100% of the time in 16.2 and below.
Starting from 16.3, the tests still contains race conditions. As a first
step towards fixing those, we will first disable the problematic steps
so that we can re-enable the test on runbot. First, this commit is about
unifying the 16.3 version of the tour with the previous versions (16.2).
Indeed, while the test currently tests the same things as 16.2, for no
apparent reason (see [3] and others):
- Some phases of the test were reordered during the forward-port that
  introduced them.
- A new "Popover should be shown" step was added during some
  forward-port (it is actually one that is the cause of a race
  condition, see below).
- 16.4 and above: many new steps which save/re-enter edit mode were
  added, random clicks were added, trigger were changed, check were
  rewritten for no reason, etc... none changed the race condition rate
  (if anything, it worsened in 16.4, see below).
- 17.0 above: some useful steps were added and do not seem to impact the
  success rate, this commit of course keeps them.

This commit thus:
- Reorders the steps the same way as 16.2.
- Temporarily disables the problematic new step.
- Removes all those useless changes.

Here are some tests made in all those versions (before this commit):

=> 16.2 and below:
- Tested: 100% working

=> 16.3:
- Tested: 162
- Failed: 88
  - 57 on "Check popover content is up-to-date"
  - 31 on "Popover should be shown"

=> 16.4:
- Tested: 30
- Failed: 28
  - 24 on "Check popover content is up-to-date"
  -  4 on "Popover should be shown"

=> 17.0:
- Tested: 80
- Failed: 80
  - 69 on "Check popover content is up-to-date"
  - 10 on "Popover should be shown"
  -  1 on "Check that links's href was updated"

=> 17.1:
- Tested: 83
- Failed: 83
  - 64 on "Check popover content is up-to-date"
  - 17 on "Popover should be shown"
  -  2 on "Check that links's href was updated"

=> master:
- Tested: 37
- Failed: 37
  - 26 on "Check popover content is up-to-date"
  - 11 on "Popover should be shown"

Note that this commit actually seems to reduce the race conditions...
which is of course not a solution on its own. The next commit will
disable the problematic steps to have the test pass 100% of the time,
until a real solution is found.

=> Tests with this commit:
- Tested: 11
- Failed: 4
  - 4 on "Check popover content is up-to-date"

[1]: https://github.com/odoo/odoo/commit/da9afc46e32111afbe0f4bdae6d539795239290a
[2]: https://github.com/odoo/odoo/commit/06f9a21c60b4bf7d375bdaba3fd4c8bc89d16b54
[3]: https://github.com/odoo/odoo/commit/9fc283b514d420fdfd66123845d9ec3563572692

runbot-57204

X-original-commit: 155bfd45b0678d69ed34d4e832df5a331a91a551
Part-of: odoo/odoo#154679
 2024-02-20 14:57:29 +00:00
Robin Lejeune (role) 9a207c8e50 [FIX] website, web_editor: fix mobile orders > 12 
Commit [1] introduced mobile orders for columns in flex containers
snippets. This was later amended with commit [2] to use Bootstrap's
`order-X` classes. Finally, to be complete, commit [3] also added some
manipulations around mobile orders.
Those classes are limited to 12 possible orders, which means the feature
stops working for any column over that threshold: a column with
`order-13` will appear as if it didn't have any order.
In the end, it has been decided that the trade-off of being capped at 12
mobile orders (and so 12 columns) and the behavior it causes isn't worth
using the classes: we will use inline style instead.

[1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
[2]: https://github.com/odoo/odoo/commit/143bdfa13d331b93b88e207f181840d91796cdce
[3]: https://github.com/odoo/odoo/commit/7b27385dba36c2e741d96e76ad5d847d09f2b084

task-3666688

closes odoo/odoo#152024

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
 2024-02-19 15:02:19 +00:00
Soukéina Bojabza a4804e0ab9 [FIX] website: outline the hoverable dropdowns when using the Tab key 
Since commit [1], there is no outline when focusing a hoverable dropdown
by using the Tab key. This happens because of a CSS rule that was added
so no outline would appear when hovering the dropdown menus with the
mouse. However, it should still be displayed when using the keyboard,
for accessibility reasons.

This commit fixes that by always allowing the focus on the hoverable
dropdowns, except when they are hovered. If a focus was present on an
element in the document when hovering, its focus is kept (to have the
same behavior as in previous versions).

Steps to reproduce:
- Add a submenu and a mega menu with the menu editor.
- In edit mode, set the dropdowns as hoverable (set the "Sub Menus"
option to "On Hover") and save.
- Use the Tab key to navigate through the menus.
=> The simple menus have an outline but this is not the case for the
dropdowns.

[1]: https://github.com/odoo/odoo/commit/5846a05fe7bf587d3bfb3ace3e863cb4abd52132

task-3709755

closes odoo/odoo#154505

X-original-commit: a8b3e589cd7e6c9ecfd33ba4ae9883e7ade2e599
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
 2024-02-19 09:06:56 +00:00
Antoine (anso) d7371fc32c [FIX] web, website: restore background to notifications in front-end 
Before this commit, `.bg-view` was set to `.o_notification`. This was
creating an issue in the front-end where `.bg-view` doesn't exist,
making the background of the notification transparent and ultimately
causing readability issues. Issue introduced in [1].

This commit changes the way we apply the background from a utility
class approach to a SCSS approach. That way, we can easily override
in `website.scss` with the `$body-color` of the website.

task-3716367
[1] 4e1f0b8ea522accae4860937c2fb3815281e8483

closes odoo/odoo#154081

X-original-commit: f8f8d2905db633cfaaa93b6cd163f4ab55dc4c8f
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
 2024-02-16 08:58:16 +00:00
Mehdi Outagant (MOU) c462d28e5b [FIX] web, web_editor, website: fix menu auto hide in edit mode 
Steps to reproduce:

- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.

On [15.0 - 16.4]:

The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).

In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:

- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.

- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.

- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.

Starting from 17.0:

The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.

This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.

[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b

Related to opw-3484742

closes odoo/odoo#153566

X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-13 17:59:57 +00:00
Louis (loco) 6f97b60477 [FIX] website: correctly update carousel thumbnails on image insertion 
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

closes odoo/odoo#153717

X-original-commit: 3c4239212e7bedc3cb49f34d9eb0a23c3de0cbd6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
 2024-02-13 14:14:54 +00:00
Robin Lejeune (role) d5232aebf9 [FIX] website: prevent duplicate code in embed snippet 
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.

This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.

Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.

Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>

<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.

[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d

opw-3513760

closes odoo/odoo#152502

X-original-commit: e6fe14dc90af6782693fd5e9dca6f18ecfe7c89a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-12 20:24:04 +00:00
Soukéina Bojabza 47ede112ed [FIX] website: remove only the "history" carousel listeners at destroy 
In order to not add steps in the history when changing the slides of a
carousel, commit [1] added listeners that would deactivate the observer
when sliding and reactivate it when the slide is over, in the `slider`
public widget. These listeners are then removed at destroy.

However, the way they are removed breaks some of the carousel behaviors:
- Drop a "Carousel" snippet.
- Change any "Carousel" option (so not a "Slide" one). For example, set
  the "Height" to 50% or add a conditional visibility.
- Slide the carousel (with any arrow).
=> The slide number did not update correctly.
- Remove a slide with the "-" button.
=> The slide was not removed.

It happens because, when this widget is destroyed, it removes all the
`.carousel` listeners, which means that it also removes the listeners
added at the `Carousel` options start. And since the widget is destroyed
and restarted every time an option is changed, but the "Carousel"
options are started only once at the beginning, the removed listeners
are never added back (until the next start of the options).

This commit adds an id to the events managing the sliding history, to
make them more specific, in order to only remove these ones when the
widget is destroyed.

[1]: https://github.com/odoo/odoo/commit/14bc1a9bd1ebdec3b73e268450267320b79d01cd

opw-3675019

closes odoo/odoo#153578

X-original-commit: 041935aff660ae5df1220e3d844d2a2cbcf4ee5c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
 2024-02-11 21:56:51 +00:00
Benjamin Vray ed732ab4ca [FIX] website: fix removing a local google font 
Steps to reproduce the bug:

- Enter edit mode.
- Click on the "Theme" tab in the options panel.
- Click on "Add a Google Font" in the "Font Family" select.
- Paste the address of a font page in the input.
- Disable the "Serve font from Google servers" toggle.
- Save the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Click on the "Remove" button for the recently added font.
- Confirm your choice to close the dialog.
- After the reload, click on the "Theme" tab.
- Open the "Font Family" select.
- Bug: the font has not been removed.

This bug appeared with commit [1]. With the transition to the Owl
render engine, the 'true' value passed as a parameter in the
'delete_google_font_btn' template, defining whether a font is local,
wasn't being set as the attribute value in the template.

In this Owl context, 'true' indicates the attribute's presence, not its
value. To address this, we replaced the boolean 'true' with the string
'"true"' to ensure the parameter value is correctly passed to the
template.

[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b

task-3714768

closes odoo/odoo#152715

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-02-06 15:59:56 +00:00
Louis (loco) 5357f77333 [FIX] website: keep image links and config after reordering in a gallery 
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

closes odoo/odoo#152365

X-original-commit: e73a1a96dcf8786c01205ae0a97b10e38ab9afeb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-02-05 23:51:13 +00:00
Benjamin Vray 02b87f5e89 [FIX] website: fix full height snippet option when a modal is open 
Steps to reproduce the bug:

- In Website edit mode.
- Drag and drop a "Cover" snippet into an empty page.
- Sets the "Height" option of this snippet to "100%".
- Drag and drop a "Media List" snippet into the page.
- Drag and drop a "Popup" snippet into the page.
- Save the page.
- Scroll quickly the page to the bottom before the popup appears.
- When the popup is open, resize the window to trigger a "resize" event.
- Close the popup.
- Scroll the page to the top.
- Bug: the height of the "Cover" snippet is a way too high.

This bug occurred because the height of the snippet with the "Height:
100%" option enabled is calculated based on the scrollable element it is
in (since this commit [1]). However, when a popup is opened, the
detected scrollable element was incorrect due to the "overflow: hidden"
rule added to "#wrapwrap" by the "modal-open" class on the <body>.

[1]: https://github.com/odoo/odoo/commit/b371cb42cb67115692464c102813b7ebd54785d9

opw-3643498

closes odoo/odoo#152402

X-original-commit: 35b3f676820f7a19e842b3403a5ebcf956714a70
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
 2024-02-05 08:34:53 +00:00
Deependra Solanki d824587776 [FIX] web_editor: should select only selected node in destroyLinkTools 
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

closes odoo/odoo#151752

X-original-commit: e88ffecc4bdb0480fc1d47af14558f28f72a665d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
 2024-02-01 09:49:54 +00:00
Romain Derie 50e27b3c84 [FIX] website, *: make custom search model work when no website_id 
*: test_website

Commit [1] modified the custom page search model so it is adding the
current website in the search domain.

But it was not considering the case of models not having a website_id
field.
The only case was the appoitment.type model.

Steps to reproduce:
- Install website_appointment (enterprise)
- Click on Website > Site > Appointments
- Crash

[1]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84

closes odoo/odoo#151686

X-original-commit: 247a5e157f14ce2cd8fbbe8d191abcb3c2e4ec0d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-01-31 06:59:10 +00:00
Romain Derie 21c25a7ccd [FIX] website: select correct website in page list/kanban view 
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

closes odoo/odoo#151269

X-original-commit: 0128beed551395b30f957a5edc1a23a6f3d0ba31
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-01-30 06:52:00 +00:00
Louis (loco) 59813f0cff [FIX] website: destroy widgets before instantiating the wysiwyg 
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#useeffect

closes odoo/odoo#151411

X-original-commit: 723c0dfeb7d39ca2522e65cf021664aacfc7099c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-01-29 23:16:16 +00:00
qsm-odoo 7931d1a14a [FIX] website, web_editor: review "small" font-size behavior 
Before this commit, since [1], the "small" class behavior of Bootstrap
was changed to use a fixed value instead of being dependent on the
context (using `em` units).

This was a bad choice, given the fact that the "small" class could
be used in the past with its previous behavior in custo but also in
default Odoo layouts, where it could be use in more legit cases that the
one Odoo currently offers: instead of applying the class to a whole
paragraph, applying it to part of a title.
In that case, since [1], we can have a big title ... with a very small
text next to it, which may be strange. Of course, the proper way to
achieve a big title with a smaller text next to it would be to not use
"small" but another hx font-size, but the legit bootstrap behavior which
is to use their "small" class is thus broken.

This commit keeps the current possibilities (big title with very small
text next to it) but does it by using new custom Odoo classes instead of
changing the Bootstrap "small" one. That way, legit custo in previous
versions (or trying to use default Bootstrap in this version) will be
supported.

Note that this commit will impact existing 17.0 users though: if they
actually configured a big title with small inner text... those will
become big title with slightly smaller inner text (the default Bootstrap
behavior). Worse: a big title whose size was reduced using the font-size
selector and choosing "small" will now become a big title. We think this
is worth the risk (see PR description for more visual details).

However, notice that "legit" use case of the "small" font-size in 17.0
will be kept untouched: e.g. adding a small text on its own or next to
a paragraph: the "smaller" Bootstrap behavior is now computed based on
the ratio of the configured base and small font-sizes.

Note that some additional "bugs" were found investigating this:
- Form descriptions use the "small" class for no reason and should
  probably not be possible to customize ("font style"-wise) anyway.
- The use of the "small" *tag* should probably be reviewed in all Odoo
  layouts and/or its interaction with the editor be fixed.

[1]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0

closes odoo/odoo#149590

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-01-29 12:05:12 +00:00
qsm-odoo e40cfe8495 [FIX] website: prevent toolbar flickering when entering edit mode 
Steps to reproduce the bug (starting from saas-16.4 only!):
- Go to the website app
- Enter edit mode
=> Bug: the editor toolbar appears for a few ms, then disappears.

This bug occurs since [1], whose original commit was actually merged in
16.0 with [2]. The reason the bug only appears in saas-16.4 and not 16.0
is because of [3].

Commits [1] and [2] change the elements that are considered "tab-able"
and thus the elements that can be auto-focused by the `useActiveElement`
hook. That hook is actually used when we enter edit mode since [4], as a
way to declare the editor as the active element so that keyboard
shortcuts work (as indicated by the related commit).

What actually happens thanks to the hook is that once we enter edit mode
the "Block" button of the right panel is focused. This is because it is
considered to be the first "tab-able" element (with or without [1]/[2]).
Then keyboard shortcuts work as expected as the right panel is focused.

However, since [3], the `useActiveElement` hook is called "too soon".
Indeed the right panel is not actually inside the "auto-focused" editor
container yet**. The result is that what is now "auto-focused" is the
editor toolbar***. Before [1], the element in the toolbar that was
focused was an invisible one, so no bug appeared. Since [1], we only
auto-focus visible elements... so we now focus a visible element in the
editor toolbar, making it visible during editor instantiation.

This commit fixes the issue independently of [3] (which is why this
targets 16.0: to consolidate the codebases). Actually, the use of the
`useActiveElement` hook added by [4] is useless. It was fixing the
issue at the time, but the real solution was to do what was done since
at [5]. Indeed, the keyboard shortcuts were not working because the
backend navbar was still visible (even if outside of the viewport) so it
was its keyboard shortcuts that took precedence. Since [5], the use of
`useActiveElement` actually has not benefit anymore. The editor is part
of the backend UI, the backend UI is still focused after entering edit
mode, shortcuts targeting the editor panel are thus working naturally.
Removing the use of the `activeElement` hook only has one side effect:
the "Block" button of the right panel is not auto-focused anymore...
which is not needed.

Notes:

- The `useActiveElement` hook also has another purpose: allowing cycling
  using tab and shift-tab, it should work naturally as with the backend
  UI anyway but mainly: tab and shift-tab do not seem to be working with
  the editor UI anyway.

- Another hint that [4] was not right way to go is that this is the only
  use of the `useActiveElement` hook in the whole codebase, except for
  the framework use for dialogs.

- ** That should maybe be solved on its own, although maybe it is not
  important and risky at best.

- *** The editor toolbar should not even be instantiated that way in the
  first place since it will be attached to the right panel later... but
  that is another issue.

[1]: https://github.com/odoo/odoo/commit/c631bf09b927003edc4c2b85e8790e8e2e8c044a
[2]: https://github.com/odoo/odoo/commit/57452ee59c3e33eaa219d8d7b8d82239fd33b722
[3]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
[4]: https://github.com/odoo/odoo/commit/b0108e1876a27e83231e176cdca3e2d67d6a2a9c
[5]: https://github.com/odoo/odoo/commit/cdc8d4c889b316664323afad0d848403960150d5

task-3686730

closes odoo/odoo#151373

X-original-commit: aa168b5583b9b437fcf83c2f7b2d256ec66e4c79
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-01-27 01:29:53 +00:00
Romain Derie 26c849ac99 [FIX] website: prevent parallax to wrongly set dirty and save wrong css 
This commit does 2 things:
- It prevents saving the parallax bg css properties which does not makes
  sense as those properties are related to the current screen scroll
  position. Each scroll position has its own css properties.
  Saving those did no harm tho, as on start those were recomputed.
- It prevents flagging that parallax bg css properties change as a dirty
  change by stopping the observer while changing those properties.
  This is not really helping much apart from being right, since when
  discarding, to know if something is dirty, it's not considering the
  `o_dirty` class but doing some DOM comparison before/after, so:
  - In this case, the css options are most likely still not the same,
    see below "O_DIRTY EXPLANATIONS" for explanation about that part.
  - There is still some stuff that will get in the way and make the
    before/after DOM not the same:
    - Scrolling a few px will hide the navbar and reveal the other one,
      flagging it as a dom diff
    - When having a few menu end entering edit mode, some will end up
      in the "extra menu area" (grouped inside the "+" menu entry),
      which will also be considered as dom diff

Step to reproduce:
- Enter edit mode and drag & drop a parallax snippet
- Update its "Parallax" sub-option from "Fixed" to "Bottom to Top"
- This option change adds some css properties to the `s_parallax_bg`:
  top, bottom and transform. Each time you scroll, those are updated.
- Save and then inspect the source code of the page (CTRL-U)
- BUG 1: The `s_parallax_bg` was saved with those css properties set to
  the values related to where the scroll was when saved.
- BUG 2: Now enter edit mode again and check that the `#wrap` is
  automatically and directly set as `o_dirty`.

--------------------

O_DIRTY EXPLANATIONS:
- The "cancel" is comparing dom before and after edition to know if it
  is dirty or not (and thus to know if it has to show that pending
  changes modal)
- The "save", to know is something has changed and need to be saved, is
  not doing that dom comparison
- Before this commit, the "o_dirty" class would be added when entering
  edit mode, as the parallax would recompute its css top/bottom values,
  which would differ from the ones saved in DB (because of the right
  panel reducing the content size)
- Before this commit, on top of the "o_dirty" class, there would be the
  top/bottom style diff too, as explained above
- After this commit, the o_dirty class is not added anymore
- After this commit, the top/bottom style is not saved in DB, but it's
  added when the widget is started, meaning that there will also be a
  DOM diff (before: no style, after: top/bottom style)
- On cancel, the snippets are not destroyed, meaning the style added on
  the start of the parallax is not removed before considering the dom
  diff

--------------------

Related PR about mitigating dirty issues: https://github.com/odoo/odoo/pull/144121
Related PR which should solve this kind of issues one day: https://github.com/odoo/odoo/pull/74923

opw-3672851

closes odoo/odoo#150994

X-original-commit: 4f8d8072a87ad0a67fbe5e61c5845d18c0e05d71
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-01-25 13:42:48 +00:00
Benoit Socias caf01f9bb2 [FIX] website: repair registry calls for model-based forms 
Since [1] when the legacy registry was replaced for website forms,
model-based forms cannot be created anymore because the legacy registry
getter returned a falsy value upon missing keys, while the new registry
raises an error.
Commit [2] already fixed one of the wrong calls but there were two other
ones.

This commit specifies a default values on the calls to the registry to
avoid the error.

[1]: https://github.com/odoo/odoo/commit/2d9f6fb32441b5db386e35200a5aab6b11b840dd#diff-59b3bc5742547152ea8d3248e1bd6606fbace25e572d7ca6c50c61e5847d184fL3-R3
[2]: https://github.com/odoo/odoo/commit/38155143dc67cee86fef50af8e164f063e5413bb

opw-3677790
opw-3683466

closes odoo/odoo#150659

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-01-24 10:44:39 +00:00
Mehdi Outagant (MOU) 124bbda127 [FIX] website: prevent using multiple content menus with the same DOM id 
Steps to reproduce (17.0+):

- Go to an event website page > go to “Site” > “This Page”.

- The menu item used to edit the page content menu “Edit Event Menu” is
duplicated.

After the event page refactoring in [1], a second template using the
same content menu ID was added to customize the UI for mobile.
And since the “Edit Menu” items generation is based on detecting current
sub menus from the DOM using the same ID (`data-content_menu_id`), we
get a new menu item in the nav bar for every menu template using it.

The goal of this commit is to fix this behavior by simply ignoring the
duplicated menu IDs (The same menu record will be edited anyway).

Remark: the behavior fixed by this commit was detected in 17.0, but we
target 16.0 to prevent any potential issue linked to duplicated menus in
the DOM, also, the duplicated data attribute will be removed in master
(one ID is enough for the content menu to be detected and edited.)

[1]: https://github.com/odoo/odoo/commit/9f2442d09b62fcb3f687ec39928ea0e3ac49557e

task-3645985

closes odoo/odoo#150568

X-original-commit: e8ebb33269cbb8d049ca3e4749c486b6d137e044
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
 2024-01-23 22:52:02 +00:00
qsm-odoo 941f63aa2a [IMP] website: support all menus edition from a mobile device 
Commit [1] (later refactored by [2]) hid the buttons which allow to
edit the main website menu and custom website menus (as the ones in
event pages), when using Odoo on a mobile device. Reading the code and
related commits, this seemed to have been done for no apparent reason.
After testing 16.0, it appears that menu edition from mobile devices was
actually not working: the re-ordering UI was strangely hidden.

After investigation, it appears that this was solved by chance, thanks
to the unrelated commit [3] in 16.2. That commit indeed removes legacy
CSS which was hiding all jQuery.ui.sortable UI elements by mistake.

In 17.0, this was further improved anyway by not using jQuery.ui anymore
(with [4]) and thus editing website menus from a mobile device works now
perfectly... except that the buttons to open the menus edition dialogs
were still hidden. This commit enables them. It was chosen to do it in
17.0 and not 16.2 as it is more an improvement than a fix in the end.

[1]: https://github.com/odoo/odoo/commit/78c59afd133de8308f4eeb6e1a2a930d870878e7
[2]: https://github.com/odoo/odoo/commit/2dc82504e08cc370b67cdf1d580f26705870a085
[3]: https://github.com/odoo/odoo/commit/ee3e28987eb1ec23b8bacc7c4043d9690aada144
[4]: https://github.com/odoo/odoo/commit/a4b1c268131ed771dd68616a26a9f1ce50a189f0

Related to task-3645985

closes odoo/odoo#150530

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-01-23 22:52:00 +00:00
Louis (loco) be782ddde5 [FIX] web_editor, *: correctly display the hierarchy between elements 
*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

closes odoo/odoo#150512

X-original-commit: c8f247ee5fa178f012b2852cba3d0e9322a2c3a6
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
 2024-01-23 16:01:50 +00:00
Romain Derie 41e2c4859b [FIX] website: properly filter website.page records on list/kanban view 
Note: This fw-port commit cherry-picked and squashed commit [2] directly
      as it was fixing this original commit before it had the chance to
      be forward ported.

Since commit [1], which adapted the website pages list view to OWL, the
records listed on screen are filtered according to the active website
filter. However, the full list of records is still used behind the
scenes for all potential actions.

Steps to reproduce:
1. Go to the pages list view.
2. Select a specific website (if it's not already the case).
   => The total of records in the upper right corner does not match the
      number of pages on that specific website.
3. Click on the "Select all" checkbox.
   => All the pages are selected, including those that do not appear on
   screen.

This is because the records were just visually hidden with a `t-if`.

[1]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
[2]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84

Courtesy of @robinlej and @detrouxdev

Related to task-3676124
opw-3554064
opw-3658648

closes odoo/odoo#149547

X-original-commit: 8d78a916dc8c0eca82e8a6a2c6f5541938709930
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
 2024-01-22 21:10:46 +00:00
Mahamadasif Ansari 7842deecd1 [FIX] mass_mailing, website: add markup in tour content 
Current behavior before PR:
  - HTML tags are displayed in the onboarding tour.

Desired behavior after PR is merged:
  - Display the HTML tag effects instead of showing it in the onboarding tour.

After the https://github.com/odoo/odoo/pull/107618 web_tour was converted into
Owl, 'markup' was required to show the html tag effect instead of htm tags.

Related Enterprise PR-https://github.com/odoo/enterprise/pull/53893

Task-3457112

closes odoo/odoo#149957

X-original-commit: c26ba2943317e82388bc05adfd64fa729923a86b
Related: odoo/enterprise#54622
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
 2024-01-19 21:25:47 +00:00
Serge Bayet (seba)andqsm-odoo 2b7303ca46 [FIX] website: address test tour issue with links href updating 
This commit resolves an issue in the `link_tools` test, specifically
addressing a failure that arises when verifying the synchronization
between the link's href and the content of the `<a>` tag. The failure
was attributed to the oversight of not clicking outside the popup to
close it before interacting with the link.

Note: the race condition that occurs in this test was very rare and was
reduced a lot by [1], its parent commits and their related forward-port.
The last version of this commit here actually does not seem to change
much but the code speaks for itself: this is how it should be written.
Further race conditions need to be fixed in this test again anyway.

This also modifies some steps to make them clearer.
In this forward-ported version, it actually patches what was done at [2]
by adding back the "input" trigger that the original commit added with
commit [3]. It also removes the outdated wait for popup opening that was
fixed the right way with [1] and its parent commits.

Final note: in this forward-ported version, the test systematically
fails on the same step, with or without this commit. Further PR will be
made; but for now, this unify what we have in all versions, hopefully.

[1]: https://github.com/odoo/odoo/commit/9b26aafbc1576b08c409344d22ec179bd32a3bd7
[2]: https://github.com/odoo/odoo/commit/7d26c7b666033a16acfb430b6bf06235dd7d88ea
[3]: https://github.com/odoo/odoo/commit/b2a79ed9960d88d1bdf6465389f4ef720f6bc235

runbot-24929

closes odoo/odoo#149871

X-original-commit: b38b40fde5cc2396b0b8b20332a5b80935eb1814
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
 2024-01-18 12:01:06 +00:00
shsa-odoo fc27a3d452 [FIX] web_editor, website: text selection issue in font size dropdown 
This commit addresses an issue where the text selection would disappear from
editor when clicking on the font size option from the toolbar.

Modifications:

- The issue of text selection disappearing when interacting with the font size
dropdown has been fixed.
- A new toolbar option, `customFontSize`, has been added. This option is
exclusively enabled for editor that have a toolbar in the same document.
The `readonly` attribute has been added to the input field to make it read-only
in our scenario, providing dropdown functionality for font size in the editor.
However, the functionality remains unchanged for the website.

task-3500827

closes odoo/odoo#142808

Signed-off-by: Antoine Guenet (age) <age@odoo.com>
 2024-01-18 12:01:00 +00:00
Serge Bayet (seba)andqsm-odoo 6fdb086a1f [FIX] website: resolve issue with logo transformation from text to image 
This commit addresses an issue when the logo is in text mode and we
want to click on the `logo` check button under the `Header`/`Elements`
options.

The bug manifested itself in [this commit] during the redesign of the
website template headers. The logo button, initially assumed to have two
states, is, in fact, comprised of three: None, Text, and Logo. To
address this issue, a workaround has been implemented, treating None and
Text as a single state. Consequently, if the current state is Text or
None, toggling will transition to Logo, and conversely, if it is Logo,
the toggle will shift to None.

Steps to reproduce:
- Enter edit mode.
- Click on the header navbar.
- Click on the logo.
- Go to navbar brand options and choose "Text" in the dropdown Logo
  selector.
- The website is now saved. click on the button `LOGO` under the
  "Header" -> "Elements" option.
- An error occurs: the template is not well-formed or wrong.

[this commit]: https://github.com/odoo/odoo/commit/e5380a8e40be47cddf53aa24ff01e7c6802bbdb7

opw-3624285

closes odoo/odoo#146839

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
 2024-01-18 03:48:00 +00:00
Soukéina Bojabza 30ec9ffa2d [FIX] web_editor, website: improve grid image code 
Commit [1] added the support for images with a link set on them in grid
mode.

As a follow up, this commit does the following:
- Removes the `!important` from the grid image anchor CSS rules, as they
were not really needed.
- Checks if the image has a closest `o_grid_item_image` column instead
of checking the parent in the `GridImage` options. Indeed, this class
already guarantees that the image is well a grid image; we can therefore
simplify the code.

It also removes a comment that was forgotten in commit [2].

[1]: https://github.com/odoo/odoo/commit/085d70cea571ea80c141ac6005e8bd8333bd269f
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600

related to opw-3580128

closes odoo/odoo#149681

X-original-commit: 9244e85ebb9e1605292698fe31ad94da7709ab86
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-01-17 13:04:01 +00:00
Benjamin Vray 18263b6805 [FIX] website: fix video in Image Gallery and Images Wall 
Steps to reproduce:

    bug 1:
    - Enter edit mode.
    - Drag and drop an "Image Gallery" snippet onto the page.
    - Double-click on an image within the snippet.
    - In the media dialog, click the "Video" tab.
    - Copy-paste a YouTube video URL into the URL input.
    - Save the media dialog by clicking on the "Add" button.
    - Bug: The video is very small.

    bug 2:
    - Drag and drop an "Images Wall" snippet onto the page.
    - Double-click on an image within the snippet.
    - In the media dialog, click the "Video" tab.
    - Copy-paste a YouTube video URL into the URL input.
    - Save the media dialog by clicking on the "Add" button.
    - Bug: the spacing around the video is not correct and the "spacing"
    option does not work for the video.

Note that the "image gallery" snippet (also the "image wall" snippet)
was not initially designed to handle anything other than images. When
you click on the "Add" button of the snippet, you can only add images.

However, by following the steps described above, it's possible to work
around this limitation and add a video to the snippet. Since this was
not part of the original plan, several options do not function correctly
with a video.

Instead of preventing the addition of videos, we have chosen to allow it
and focus on fixing the main issues (the small size of the video and the
"spacing" option which does not work with videos). So, if someone
specifically wants to add a video, it's currently possible, though some
features may not work as intended.

task-3597156

closes odoo/odoo#149679

X-original-commit: 73f60e97a1b534b5f8dd3759bd631f9aac095426
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
 2024-01-17 09:15:34 +00:00
Arthur Detroux (ard) 94cae965a4 [FIX] website: properly check if all snippets have their data-snippet 
Commit [1] changed the class from .ui-draggable to .o_draggable in the
`snippet_version` test, specifically in the run function that checks
if all snippets have their `[data-snippet]` properly set.

Indeed, `.o_draggable` is set on the parents of draggable elements and
not on the elements which are draggable themselves. This lead to a
`.every` on an empty array which returns `true`, and therefore avoids
the `console.error` but did not properly check the snippets.

This commit changes the selector to all snippets which do not have
a [data-module-id] which should be all snippets that are draggable.

[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76

Related to task-3079246

closes odoo/odoo#148824

Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
 2024-01-16 11:39:59 +00:00
qsm-odoo 2487d8d278 [FIX] web_editor, *: restore change checks on link tooltip open/close 
*: website

This basically reverts the parts of [1] that are the known cause of race
conditions in runbot tests (in particular, the link tools one:
`test_15_website_link_tools`). But more importantly, this just did not
make sense to stop observing changes for async period of time, at least
unless there is no alternative given the state of the related code.

Commit [1] test-hack was actually adapted with [2] which probably made
it even more unreliable and hacky.

On top of that, this commit is of course trying to restore whatever
purpose this was made for ("dirty" flag addition, the history steps
recording, etc). Although fixing those the most robust way would
probably require a deeper refactoring in master and other stable fixes.

Note: in this forward-ported version, the test is still disabled on
runbot and broken for other reasons. Those will be fixed later.

[1]: https://github.com/odoo/odoo/commit/8cab404dce3a65c0bdd635a93682ee14282a3ebb
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35

runbot-18747

closes odoo/odoo#148728

X-original-commit: 003422a73f0b5fb5540fbf2bd95a26a6dd663530
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
 2024-01-10 10:28:17 +00:00
qsm-odoo f44ae60235 [FIX] web_editor, *: do not observe changes related to link edition 
*: website

Commit [1] and [2] modified the link edition code in stable and tweaked
the DOM at multiple places... without disabling the main edition
mutation observer. Later, [3] tried to fix that but missed some
occurrences. Hopefully, this solves the remaining ones.

Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the button 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/99bc9b115dbdfc29260b4ccdb55ffa2ed16dffb3
[2]: https://github.com/odoo/odoo/commit/d00fc75ffdbda1286e4fdb2793cb74fa78f6860d
[3]: https://github.com/odoo/odoo/commit/33ef91cc577d8b397a948c430b77c2e038013d2d

Related to runbot-18747

Courtesy of @SergeBayet for the test step.

X-original-commit: 2a535dfe655bc6a4f4a2d46a6b06a4b8b8029204
Part-of: odoo/odoo#148728
 2024-01-10 10:28:17 +00:00
qsm-odoo 0a948a8386 [FIX] website, *: review text selection on click and dirty editable area 
*: web_editor

The editor has a feature that allows to automatically select a whole
paragraph on click when that paragraph contains text by default. At the
origin, this happened at every click on the element, until its content
was replaced, by typing something while it is selected or the cursor is
inside. Placing the cursor inside was actually impossible by clicking on
the element, since this forced a selection on the whole text again.

Since [1], that behavior changed (for no apparent reason): only the
first click forces a selection on the element. This is done by removing
the marker class from the element ("o_default_snippet_text"). Also, the
code which removed that class while typing was left behind... even
though it did not work anymore due to a code typo.

This commit fixes that without changing the main behavior:
- On click, we do not remove the marker class anymore, but only force a
  selection on the text if it was not already seen before. Small change
  of behavior: not changing the text and coming back later in edit mode
  will force a selection on the text again on click.
- While typing, the code removes the marker class and thus the text will
  never have a forced selection again (fixed the code typo).

Note: we may reconsider restoring the behavior there was before [1], in
master. Automatically selecting default text that was never changed
could indeed be better, although it will require better code to allow
placing the cursor inside easily anyway.

The main purpose of this fix is to avoid a mutation of the DOM on click
(removing the marker class). Indeed, this wrongfully marked the page as
dirty.

Steps to reproduce:
- Enter edit mode
- Add a "Text - Image" snippet
- Save
- Enter edit mode again
- Click on the first paragraph of the snippet (=> it is auto-selected)
- 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/912996fe902c41cafa12dcfe09713ce9857f95ab

Related to runbot-18747

X-original-commit: 3cc5bbcab641d7d436ebfbb0f160c9e0d77da142
Part-of: odoo/odoo#148728
 2024-01-10 10:28:17 +00:00
qsm-odoo 32a6729dd0 [FIX] website, *: do not observe changes of drag and drop initialization 
*: 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
 2024-01-10 10:28:17 +00:00