Before this commit, when adding a new grid item in a grid by using the
"Add Elements" option, if the page was scrolled such that the top of the
grid was not visible, this new grid item may not always be visible. This
is annoying as the user could add an element and not see where it
appeared and would therefore need to look for it.
This commit fixes this by making the page scroll to the added grid item
if more than half of it is not visible. A test is also added.
Steps to reproduce:
- Drop the "Text-Image" snippet and enough snippets under it to have a
scrollbar.
- Toggle the "Text-Image" snippet to grid mode.
- Scroll the page so the top of the grid is not visible.
- Add a new "Button" with the "Add Elements" option.
=> The button is not visible.
task-3616138
closesodoo/odoo#161159
X-original-commit: 50766b74196b3cdc5ac83d7962873f4fffa4c9f6
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Since commit [1], we can now drag and drop an image column by dragging
it directly, and not only by the move handle. Commit [2] allowed the
image to be dragged from anywhere and not only from the top middle.
However, since commit [2], it is really difficult to drag a column
downwards in a grid, if the drag started from the bottom move handle or
near the bottom of the column if it contains an image, because we easily
get out of the dropzone.
Indeed, since the positioning of the column now takes into account the
mouse position on the column where the drag started, the mouse cursor is
therefore located under the column (or almost under in the second case).
This is why it gets out of the dropzone before a new row could be added.
For the second case, new rows can be added, but only if the drag is slow
enough, which is not convenient.
This commit bounds the vertical position of the mouse when dragging, in
order for it to always be considered inside the column, so it cannot
escape the dropzone anymore. A safety margin of one grid row is
considered, to not escape when dragging rapidly.
Steps to reproduce:
- Drop enough snippets to have a scrollbar or select the "Sidebar"
header template.
- Drop a "Text-Image" snippet
- at the top of the page if the header was changed at the previous
step, or
- at a place where the top of the snippet can be hidden with a scroll.
- Toggle it to grid mode.
- Start dragging any column with the bottom move handle or drag the
image column by clicking near the bottom of the column.
- Go over the grid dropzone if the move handle is used.
- Drag towards the bottom of the grid.
=> The mouse easily gets out of the dropzone, making it impossible to
add new rows and drag further down the grid.
[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9
task-3601336
closesodoo/odoo#144427
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Since commit [1], we can now drag and drop an image column by dragging
it directly, and not only by the move handle. Commit [2] allowed the
image to be dragged from anywhere and not only from the top middle.
In grid mode, in order for the column to stay well inside the grid when
dragging, its computed position was originally bound horizontally, to
the left and the right of the row. With commit [2], it is now also bound
vertically, to the top and the bottom of the row.
While it makes sense for the top, because we need to take into account
from where we dragged the image, it should not have been the case for
the bottom, as we need to overflow in order to add new rows. This
resulted in the drag towards the bottom becoming jumpy, because it locks
on the bottom of the grid until a new row is added, when the mouse
pointer is down enough.
This commit removes this bottom bound, in order for the drag towards the
bottom to be smooth again.
Steps to reproduce:
- Drop the "Text-Image" snippet and toggle the grid mode.
- Drag a column towards the bottom in order to add new rows.
=> It is not smooth: it locks on the bottom of the grid.
[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9
task-3601336
Part-of: odoo/odoo#144427
When a background video and an animation coming from the left or the
right are on a page at the same time, there sometimes is a horizontal
scrollbar that appears for no reason. It can happen at any screen size
but more frequently near 1000px and below. This issue seems to happen on
Chrome only.
It seems to be a race condition between the calls to the `_adjustIframe`
function in the `backgroundVideo` public widget. Indeed, this function
is called when the video is added in the DOM and each time the screen is
resized. When an animation is played, it triggers a resize of the window
when it is over, which therefore calls `_adjustIframe`.
When the animation comes from the right/left of the screen, the animated
element is translated from outside the page; the page width is therefore
bigger but its overflow is prevented. When the video is loaded, the
loading placeholder is removed. Depending on the time it takes to it to
fully load, if the animation ends before it, the iframe is adjusted
before the placeholder removal, leaving the iframe wrongly adjusted when
it is finally removed.
Note that it is hypothetical, as everything refreshes when inspecting
the DOM, making the scrollbar disappear. But this proves that no element
is really overflowing, so it seems to be a value refreshing issue.
This commit adds a call to `_adjustIframe` when the video has loaded, to
make sure its dimensions are recomputed/refreshed, preventing the
scrollbar to appear.
Steps to reproduce:
- Drop a "Text-Image" snippet.
- Set a background video to it.
- Add the "On Appearance" > "Fade" > "From Right" animation to the image
column.
- Save and then resize down the screen to 1000px or below.
- Refresh.
=> When the video is loaded, a horizontal scrollbar may appear. If not,
refresh until it does.
opw-3487117
closesodoo/odoo#159817
X-original-commit: 6035874e61d2bb1cecc339c4006cdcb6b4084b5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before this commit, the header was considered as mobile at the `SM`
screen breakpoint, while it is already displayed as in mobile view at
`MD`. This made some of the header behaviors inconsistent and caused
some issues:
1) A menu open at `MD` is not closed when resizing the screen:
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
- Resize back at `MD`.
=> The menu was not closed. It is when we start resizing at `SM`, which
is inconsistent as they are both displayed like in mobile view.
2) Because of the first issue, we cannot scroll the page anymore after
opening the menu at `MD`:
- In edit mode, drop enough snippets to have a scrollbar and then save.
- Resize the screen at `MD` and open the menu.
- Resize the screen above `LG`.
=> There is no scrollbar anymore and we cannot scroll.
This happens since PR [1], which redesigned the headers and changed the
"hambuger" menus so they open on the side (= offcanvas), and commit [2]
that prevented the `#wrapwrap` to scroll when these menus are open, to
prevent a bug on Safari. The issue happens because since the menu does
not close when resized, the class preventing the `#wrapwrap` to scroll
is never removed.
3) The menus are hoverable at `MD` but not at `SM`:
- Add sub-menus and mega menus with the menu editor.
- In edit mode, set the menus as hoverable (set the "Sub Menus" option
to "On Hover") and save.
- Hover the menus:
- above `LG` (= desktop view) => they open.
- under `SM` (= mobile view) => they do not open because we need to
click to open them on mobile view.
- between `SM` and `LG` => they open even though it is displayed like
in mobile view, so the behaviors are inconsistent.
4) Because of the third issue, there is sometimes a traceback when
hovering mega menus if the screen is at `MD`:
- Resize the screen at `MD`.
- Refresh.
- Open the menu and hover a mega menu dropdown.
=> There is a traceback sometimes.
Since commit [3], in order to avoid mega menu synchronization issues
between the desktop and mobile headers, the mega menus are not
duplicated anymore and they are moved from one navbar to the other when
opening them, so when hovering them if the menus are hoverable. A race
condition can happen in that case because the `hoverableDropdown` widget
tries to open the mega menu before the menu has been moved in its
dropdown, which causes a traceback. This seems to happen only when the
widgets start with the screen at `MD`, therefore, preventing the menus
to open on hover under `LG` prevents this race condition.
This commit considers the header as mobile under the `LG` screen
breakpoint, to fix these issues and to uniformize the behaviors of the
mobile header.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/389856bcd94d459d72f46c2a517afb3f6d976e38
task-3801970
closesodoo/odoo#158571
X-original-commit: 4d3c86cb33c12f0e7bbc7812452feb33ddfa8321
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
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
closesodoo/odoo#146492
Related: odoo/design-themes#756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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
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
*: 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
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
closesodoo/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>
Since commit [1], it is now possible to order the columns in mobile view
independently from the desktop view. When moving a column with an arrow,
if we are in mobile view, mobile order classes are added on the columns,
which only changes the order on mobile without affecting desktop. But if
we move on desktop view, then these classes are removed.
While it works well when using the arrows, this behavior is not the same
when moving the columns with the drag and drop. This means that drag and
dropping a column
- in the same snippet does not reset the mobile order classes;
- in another snippet does not reset the classes in it and does not fill
the gap left in the previous snippet if it was ordered.
This means that in the same snippet, there can be both columns with and
without the mobile order classes. This causes some issues:
1) Removing such snippets or their ordered columns causes a traceback.
Indeed, the `onRemove` code considers that all columns have the mobile
order classes if we remove one, which is why it fails when it is not the
case.
2) The arrows on the mobile overlay are not always correct and can also
be missing, because they depend on the order classes.
3) In mobile view, changing the order of the columns adds inconsistent
mobile classes on them, because of the columns that already have one.
This commit improves the drag and drop by also taking mobile ordered
elements into account, as it is the root cause of the mentioned issues:
- When a column is moved, the order classes of all the other columns in
the snippet where it was dropped are removed (so it behaves the same way
as with the arrows).
- When moving an ordered column in another snippet, the gap it left in
its previous snippet is now filled.
This commit also fixes the issues for already dropped blocks in existing
DBs, by
- adding a check when removing to avoid the first issue;
- removing the mobile classes at the start if they are inconsistent.
[1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba
opw-3697962
closesodoo/odoo#152487
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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
closesodoo/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>
Since commit [1], which removed jQueryUI for the drag and drop, the
history when editing breaks easily.
Steps to reproduce:
- Drag and drop "Text-Image", save and go back to edit mode.
- Click on a column, move it to the right using the arrow and then to
the left, still with the arrow.
- Undo: no issue, the column went to the right.
- Undo: nothing changed => the column should have gone to the left.
- Undo: the column goes to the left => there should not be a third undo
since we only did two changes.
- Redo: no issue, the column goes to right.
- Redo: nothing changed => the column should have gone to the left.
- Nothing to redo anymore => the column never goes to the left again.
This happens because with the new drag and drop, an `o_draggable` class
is added on the elements when their editor are started, which adds
mutations in the history. Even though it does not explicitely add a
step, these mutations are well reverted when undoing/redoing (e.g. this
is what happens when nothing changes in the steps to reproduce).
This commit fixes this history issue by ignoring the mutations linked to
the `o_draggable` class.
Note that commit [2] already fixed other `o_draggable` class issues.
This commit therefore fixes them in a more general way.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
[2]: https://github.com/odoo/odoo/commit/32a6729dd094d53eb4a653ebb9d69d2b8cbe2390
task-3698536
closesodoo/odoo#150687
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
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
closesodoo/odoo#149681
X-original-commit: 9244e85ebb9e1605292698fe31ad94da7709ab86
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "grid images" are grid items that only contain an image (i.e. the
image is alone in its column). This distinction with other images in
grid mode allows to set the `object-fit` CSS property to `cover` so they
take the whole space of the grid item (see commits [1] and [2]). In
commit [3], the "Position" option has been added, allowing to switch
between the `cover` and `contain` values for this property, to have the
possibility to still choose to display the entire image, so it can keep
its ratio.
However, only the images that are direct children of the column have
been considered when checking if it was a grid image and in the related
CSS rules. This means that an image with a link cannot be one, since
the image is the child of an anchor element `<a>` in that case. It can
therefore not be set as "cover" or have the "Position" option.
This commit adds the support for images with a link set on them, so they
can be considered as grid images too.
Steps to reproduce:
- Drop the "Masonry" snippet.
- Click on the image and set a link on it.
=> The image is now "contain" and the "Position" option disappeared from
the right panel so we cannot change it.
[1]: https://github.com/odoo/odoo/commit/e9c7e020daf88022d6e02de0a5620074e8417b5a
[2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600
[3]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
opw-3580128
closesodoo/odoo#148022
X-original-commit: 085d70cea571ea80c141ac6005e8bd8333bd269f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
When we start dragging an element with an open mega menu, the dropzones
should only appear:
- inside the mega menu: we therefore should not be able to drop a mega
menu element outside of it.
- after the clone of the element, so we can still drop it where we
started the drag (if it does not come from the mega menu).
This is well the case for normal dropzones but the grid dropzones case
was forgotten. Some "clone dropzones" are also not added for inner
contents that are in a grid mode snippet.
Steps to reproduce:
1)
- Add a mega menu with the menu editor.
- In edit mode, drop the "Text-Image" snippet and toggle the grid mode.
- Open the mega menu and start dragging one of its columns (note that it
toggles the grid mode).
=> A grid dropzone appeared in the "Text-Image" snippet, outside the
mega menu.
2)
- Drop an "Alert" snippet in "Text-Image".
- Open the mega menu.
- Start dragging the "Alert" snippet.
=> No dropzone appeared where we started the drag (so after the clone).
This commit fixes these issues. The first issue is solved by properly
filtering the `selectorGrids` when a modal or a dropdown (so the mega
menu) is open. They were already filtered for the modal case (see commit
[1] which was then refactored in [2]) but it should have been done in
`_activateInsertionZones` at the already dedicated place, instead of
before the call to this function in `_onDragAndDropStart`. This made the
siblings and children selectors filtering redundant and this code was
therefore removed.
The second issue was happening because the "clone dropzone" was only
added if there was no "closest" grid, instead of only checking the
parent. This therefore prevented it for inner contents inside grid items
instead of only for grid items. This commit fixes that. For the case
where we are dragging a grid item (still with an open mega menu), a grid
dropzone is added.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/commit/34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
task-3594979
closesodoo/odoo#146714
X-original-commit: 8eebef20de144fe223feace39546d827a0952b23
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Before this commit, when editing a snippet that is outdated, an alert
block is displayed above the options, warning about that. However, this
alert does not really catch the attention and it does not prevent the
user to still use the options.
This commit improves this alert block by making it cover the whole
outdated options section, to make it more visible. Moreover, it now
contains two buttons:
- one to replace the outdated snippet by its new version, and
- one to still access the options, despite the fact that they may not
work anymore.
task-3203590
closesodoo/odoo#117560
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In the Social Media snippet options, only icons with a `<i>` tag are
considered when updating the social media classes (when adding a new
social network by copying the first one and when replacing the icon by
another one matching the URL). However, there are cases where the icon
is a `<span>` element (with a `fa` class) and not a `<i>`.
For example:
- Replace a social network icon by a real image.
- Re-replace this image by an icon.
=> the icon element tag is `<span>` and not `<i>`.
In this case, after setting its style correctly (e.g. adding the round
shape) to make it look like the other icons, we notice that it does not
behave like the other ones:
- It is not aligned with the other icons, because the CSS rule aligning
them only targets `<i>`.
- Its icon is not replaced by a matching one when changing the URL with
a "relevant" one (e.g. google, facebook).
This commit considers `<span>` icons in the Social Media options, in
addition to `<i>` icons, in order for them to all behave the same way.
opw-3538230
closesodoo/odoo#144076
X-original-commit: a8b5c3045bea0227304306e19ed9d50cf497f518
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
When using the "Social Media" snippet, there are two situations leading
to a traceback. Here are the steps:
1) First issue
- In edit mode, drop the "Social Media" snippet.
- Add a new social network.
- Replace the icon by a real image (so not by an other icon).
- Set the URL of the new social network to a "relevant" one (e.g.
google, facebook).
=> traceback
2) Second issue
- Drop "Social Media" and change the list in order to have the first
social network with a real image as icon: either replace the first icon
with an image, or add a custom one with an image an move it to the top.
- Add a new social network.
=> traceback
Both issues happen because only icons set as `<i>` elements are taken
into account when modifying a social network (`querySelector('i')`) and
this element may not exist if the icon had another tag (like an image or
a span or even a video (as the media dialog allows to upload them)). As
there is no check ensuring that the element exists before changing the
different social media classes, there is a traceback when the `<i>` is
not found.
For the first issue, it happens because when changing the URL, we first
check if it matches with relevant ones or if an icon matching it exists.
If it is the case, we then update the social media classes to set the
matching icon => it can only work if the icon is a `<i>`.
The second issue happens because when adding a new social network, it
actually copies the style of the first one (unless there are none, a new
one is created in that case). If the first one is an image, it fails
when updating the classes because it is not a `<i>`.
This commit fixes these issues by simply adding checks ensuring the icon
element exists before trying to modify it. It also adds tests, ensuring
these use cases work as expected.
opw-3538230
X-original-commit: 0132fa38baee6501f4257dad718359400f1369ad
Part-of: odoo/odoo#144076
In grid mode, if an image is in an image column (with the class `o_grid_
item_image`), it has the "Position" image option, allowing to select
between "cover" (= the image takes the whole grid-area, which means it
could be "cropped") and "contain" (= the image is entirely visible and
keeps its ratio in the available space). When there is a shape on the
image, this option is hidden and it is "contain" by default (or else the
shapes would be cropped). See commit [1].
Commit [2] added the "On Hover" animation option, to add hover effects
on images. In order for the effect to be applied, a shape is needed and
if no shape is specified, a dummy square shape is used instead. As there
is a shape, if it is a grid image, the "position" is forced to "contain"
(because of commit [1]).
The issue is that while it is logical for some hover effects to never be
"cover", as they could be cropped (i.e. "Dolly Zoom", "Outline", "Mirror
Blur" and any effect with a shape selected), it is not the case for the
other effects when there is no shape.
This commit improves this by allowing the "Position" option to be used
with these other hover effects when no shape is selected (so only with
the dummy square shape).
Steps to reproduce:
- In edit mode, drop the "Banner" snippet.
- Add the "Overlay" hover effect on the big image.
=> The image became "smaller" because it was forced to "contain".
[1]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
task-3568406
closesodoo/odoo#141468
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Steps to reproduce:
- In edit mode, drop the "Masonry" snippet.
=> There are spaces on the left and the right of the snippet. It should
not be the case as it is supposed to take the whole space, since its
container width is full (`container-fluid` class).
This happens because since commit [1], the rule setting the `--gutter-x`
CSS variable (which manages the row margins) to 30px when the container
is full width is now overridden by the general `.o_grid_mode` rule that
sets it to 0px, making the negative margins disappear.
Indeed, in commit [1], in order to disable the grid mode when used in a
mega menu that is in an extra menu (because the layout was broken), the
CSS selector managing the `.o_grid_mode` class has been modified. This
change caused the specificity of the rule to increase (x3), which made
it override the container rule.
This commit reverts this change and disables the grid mode in the extra
menu in a better way, by adding a proper rule for this specific case.
[1]: https://github.com/odoo/odoo/commit/709bffcb6de8883b679c0fc942f45cb293621c30
task-3593697
closesodoo/odoo#142189
X-original-commit: 8381af7d9898d7502c82a6b5622b0e91734267d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In commit [1], the media dialog has been improved in order to have a
better UX when using it. However, its code is quite complex and could be
simplified.
This commit modifies again the UX of the media dialog to only consider
the addition of the "scroll button" and leaves the "Load more" button
after the attachments without making it fixed. The scroll button still
disappears once the load more button appears in the modal.
This commit also addresses the remaining review comments that were not
resolved, as it was merged in a rush.
[1]: https://github.com/odoo/odoo/commit/d1c7e371491b06176c2f5a432dccdc87b7002296
task-3580707
closesodoo/odoo#141356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When using the media dialog, the dialog always seems glitchy as its size
is always changing with the loading files. This behavior is not really
convenient as it can make the user click on unwanted images. Another
"issue" of the current media dialog is that when loading more images,
the dialog auto-scrolls to the "Load More" button, which can make the
user miss new images and he therefore needs to revert the scroll. A last
issue encountered by the users is that some of them think that the "Add"
button in the footer is used to upload files from their device, while it
only adds the selected media to the page.
This commit improves the UX of the media dialog:
- The dialog height is now fixed and has the same size as when it is
fully filled by images.
- The top bar with the search input now stays at the top when scrolling.
- There is now a small footer under the attachments (for the Images and
Documents tabs only) and containing the following:
- When there is content to scroll, a small circle with an arrow that
scrolls one row when clicking on it.
- When there is nothing to scroll, the "Load More" button which will
load more images. When new images are loaded, if we can scroll, the
small arrow is displayed again.
- When there is nothing to scroll and to load anymore, the "All
images/documents have been loaded" text.
Note that the main goal of this footer is simply to indicate to the user
when there is still content to scroll and when he can load more files.
In order to solve the "Add" button issue, this commit also enables and
disables this button, depending on whether some media are selected:
- if a media is already selected, we can click on the button;
- if not, the button is greyed out and we cannot click on it.
task-3441587
closesodoo/odoo#135875
Related: odoo/enterprise#49535
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When changing the grid gaps (see commit [1]) a grid preview is displayed
in order to visualize the changes. As it cannot be displayed in mobile
view (otherwise, the layout looks broken), some code prevents it to be
added in this case. However, a case has not been taken into account:
- In desktop view, change the gaps of a grid with the "Spacing (Y, X)"
option.
- Before the preview disappears, quickly activate the mobile preview.
=> The preview is displayed (before disappearing).
This commit prevents the grid preview to be displayed in mobile view. To
do so, its height is forced to 0. Note that `display` could be set to
`none` instead but since it prevents the animation to be played, the
preview would not be removed by its listener.
[1]: https://github.com/odoo/odoo/commit/4345df3aeeb83463d81bc24749856fef3a58fb3a
task-3555898
closesodoo/odoo#138795
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
In commit [1], the Banner snippet has been redesigned in order to be
in grid mode by default, to highlight some cool features of the editor.
However, some grid classes and attributes are missing or not well set:
- the first column has a `g-height-4` class despite having 8 rows: this
causes the vertical resize to not work correctly.
- the row does not have the `data-row-count` attribute, which is needed
to display the background grid correctly.
This commit fixes this by replacing the class by `g-height-8` and adding
the `data-row-count` attribute, which is set to 11 rows.
[1]: https://github.com/odoo/odoo/commit/3cbdf754ff8fac8a77887c4307b658cb86b0be1d
task-3369695
closesodoo/odoo#136683
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, toggling the "Text Cover" snippet to grid mode did
not produce a good-looking result: the column containing the background
image loses all its padding and therefore appears smaller and shifted
compared to the normal mode.
This commit adds a background color to the image column. Indeed, with a
background color, and more precisely thanks to the `o_cc` class, the
padding is taken into account when computing the grid items size, making
them look similar to how they were in normal mode.
task-3369695
Part-of: odoo/odoo#136683
The `display: grid` property allows to modify the spacing (or gaps)
between the rows and columns of the grid with the `row-gap` and `column-
gap` CSS properties. When the grid mode was added with [1], these
properties were deliberately ignored and the gaps were forced to 0px.
This commit adds the "Spacing (Y, X)" option that allows to modify these
grid gaps. A grid preview is also added when using this option, in order
to visualize what is being changed in the grid.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3369695
Part-of: odoo/odoo#136683
In the grid mode code, the code managing the transformation of a grid
item into a normal column (when it is dropped or when we toggle the
normal mode) is repeated at several places.
This commit fixes that by creating a function doing this conversion
instead.
task-3369695
Part-of: odoo/odoo#136683
Before this commit, when using a `we-input`, there was no way to easily
specify the min and max values that could be entered in the input, which
could be useful when too low/high values could break some behaviors, for
example.
This commit adds the support for the `data-min` and `data-max` data-
attributes in `InputUserValueWidget`. More precisely, when these
attributes are added on a `we-input`, if the user writes a value smaller
than the `data-min` or bigger than the `data-max`, the value snaps to
these bounds. When using the arrows, the value cannot be decreased/
increased beyond them either.
task-3369695
Part-of: odoo/odoo#136683
Co-authored-by: qsm-odoo <qsm@odoo.com>
When cloning a snippet, if it had some previews displayed, the previews
may be cloned with it. This is not a good behavior because the clone
is a new snippet so it should not have all the preview classes that were
added when editing. Moreover, these previews could also cause bugs.
To solve this, an idea could be to call the `cleanForSave` function of
all its options before cloning the snippet. But the problem is that in
some options, the `cleanForSave` function does more than simply clean
the UI (as it was originally supposed to) and so it cannot be used for
that purpose only.
As a solution, this commit adds a new function called `cleanUI` whose
exclusive purpose will be to clean the snippet UI. In the future, it
will replace the `cleanForSave` function.
task-3369695
Part-of: odoo/odoo#136683
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit makes the rpc call in the `loadImageInfo` method robust to
the case where an image src would be an absolute URL, by only
considering the relative part of the URL.
The images src are generally always relative but commit [1] wrongly put
absolute URLs to images in grid mode with the `_reloadLazyImages`
method. While this behavior was fixed by commit [2], the images that
were saved before this fix was available still have an absolute URL.
Hence the need to make `loadImageInfo` robust.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/commit/3528f2c3f9d3b30266f3421672986d202c724a76
task-3514519
closesodoo/odoo#136951
X-original-commit: af5ddabb0285daa9e57bc01cf21628f2f94bc18f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], which converted the wysiwyg to Owl, trying to
customize the Google Map API key causes a traceback.
Steps to reproduce:
- In edit mode, go to the "Theme" tab.
- Click on the Google Map "Custom Key" button.
=> A traceback appears.
It happens because when getting the parent with the `this.getParent()`
call, the parent is now a `WysiwygAdapterComponent` component and so,
calling the `trigger_up` function on it does not work anymore.
This commit triggers the `gmap_api_key_request` event in a way that is
compatible with the Owl component.
[1]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
opw-3489976
closesodoo/odoo#135069
X-original-commit: 355a593fe2dea05a96d0491d684722770533ab7d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: web_unsplash
Before this commit, if we were in debug mode, when we tried to replace
or add an image, a traceback appeared when selecting an Unsplash image
for the first time or when uploading an image of size 0 (also for the
first time). Note that once the traceback was closed, it did not
reappear until the page was refreshed, but the progress bar was not
displayed anymore.
It happened because in debug mode, there is a validation of the
different owl components props and some props of the `ProgressBar`
component were not correctly set when adding Unsplash images or empty
image files, causing the props validation to fail. Those props
definition were incorrectly added with [1].
The traceback was not reappearing because the `UploadProgressToast`
component (= the parent of `ProgressBar`) has been destroyed and so the
props validation was not done anymore since the components were not
there.
This commit fixes these issues by correctly setting the `ProgressBar`
props and by adding default props, in order for them to always have a
value when omitted.
Steps to reproduce:
- Activate the debug mode.
- In edit mode, drop the Text-Image snippet.
- Double-click on the image to replace it.
- Type something in the search bar and select an Unsplash image or
upload an empty image file.
=> A traceback appears.
[1]: https://github.com/odoo/odoo/commit/886f3de768b647f4b402c97098abf274d6258f75
opw-3413299
closesodoo/odoo#132377
X-original-commit: 425dfb07f21288caf56bceea3a86e0b7ecac4a91
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the `s_nb_column_fixed` class is present on the row, it should not
be possible to change the number of columns in the "Columns" option (the
option is supposed to be hidden).
However, since commit [1], this behavior is broken. It happened because
the "Columns" option needs to always be displayed in order to display
correctly the "Grid" option and this class was therefore ignored.
This commit restores this class behavior by hiding only the widget
changing the number of columns and not the complete "Columns" option, in
order to still be able to toggle between the grid and the normal modes.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
task-3369847
closesodoo/odoo#127144
X-original-commit: 8148521f052268877f36947e0533843a25d17b83
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], the text selection must be kept if there was one when
using a snippet option. However, it is not the case when toggling the
grid mode for snippets that have None columns (e.g. Text) or have some
content outside of their row element (e.g. Picture). Indeed, when these
contents are wrapped inside a new column and then in the row, the
selection is lost.
This commit, as done in commit [2], restores the selection after the
content wrapping. It also adds a test checking if the selection is well
kept when toggling the grid mode and going back to normal mode.
[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41
[2]: https://github.com/odoo/odoo/commit/e4d7fbfca85c869d3a04dc517a8ad522cb533a90
task-3324775
closesodoo/odoo#124513
X-original-commit: bcb0e9b83fcb7e3f8a66131a089b88b39f58a2e4
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
When toggling a snippet to grid mode, if it has None columns (e.g. Text)
or if it has contents located outside of the row element (e.g. Picture),
the contents are wrapped inside a column and then put inside the row.
However, after this operation, it is impossible to delete or replace the
text in this newly created column.
As mentioned in commit [1], this happens because there is an unwanted
rollback in the history, which should be prevented by resetting the
nodes unbreakable id (i.e. the `ouid` property).
This commit makes this property reset and therefore allows to delete or
replace the text after the toggle to grid mode.
[1]: https://github.com/odoo/odoo/commit/e33b802b05b41df20e13ebc44bc5b78edae50bb8
task-3324775
X-original-commit: 5bd354802a9aae9575806ad83350e0b002efa2fa
Part-of: odoo/odoo#124513
Before this commit, there were cases where toggling the grid mode did
not work correctly. These cases are:
- when a snippet has None columns (e.g. Cover) and that an inner snippet
containing a row (e.g. Form) was dropped into it,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner snippet containing a row was dropped in this outer
content,
- when a snippet has some content outside its row (e.g. Picture) and
that an inner content (e.g. Alert) was dropped in this outer content.
The first two cases happen because the row that was taken into account
when toggling the grid mode was the first `.row` element found in
general, instead of only considering the container children. Therefore,
what happened in these problematic cases is that the row found was the
inner snippet one, which should not be the case and caused the toggle to
fail because it was trying to put the element inside itself.
The third case happens because the `div` elements were excluded when
placing the outer content in a column, instead of only excluding the row
element.
This commit fixes these issues by only considering the container
children when looking for the row element when toggling the grid mode,
and by filtering out only the row element instead of every `div` when
creating a column for the outer content.
task-3279191
closesodoo/odoo#121393
X-original-commit: f94fe1d40f05a8dbb42f0f2a95d3fff68a3af0ec
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit, the input widgets that do not have units have their
text aligned to the left. However, when the content is numeric, it would
be better if the number was on the right, just as when there is a unit.
This commit also considers as numeric an input widget that has the
`data-step` attribute (and not only the `data-unit` attribute) and
forces the text alignment to the right in this case.
task-2798576
closesodoo/odoo#89055
Signed-off-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit, now that multiple files can be uploaded in a form,
we could observe that the file input is not convenient to manage this
situation:
- Clicking again on the input to choose other files replaces the
previously uploaded ones, we can therefore not upload files one by one.
- A file cannot be deleted in an obvious way: we need to cancel a new
upload, as it will replace the file by nothing and therefore delete it.
- When multiple files are uploaded, only the number of files is
displayed and not their name (they are only displayed on hover).
This commit improves these behaviors:
- Clicking again on the input adds additional files instead of replacing
them (unless the number of files allowed is 1);
- The button text content is modified after the upload of files,
displaying "Add Files"/"Replace File" (if multiple/single files are
allowed) to show its role better.
- When files are uploaded, blocks containing each files name and a
cross to delete them are displayed.
In order to make these improvements, the file input is hidden and
replaced by an input of type=`button` when files are uploaded. This was
done for two reasons:
- It is not possible to modify the content of an input of type=`file`
but we can change the value of a button.
- The input did not look good with the file blocks, because it has a
text displaying file informations, which was redundant with the blocks.
task-2798576
Part-of: odoo/odoo#89055
Currently, we can only upload one file in a form File Upload field and
this file does not have a size limit. (Note that the server can have a
limit to prevent files too large from being uploaded but the file input
itself does not have one.)
This commit adds options to the form file inputs in order to set a
maximum number of files and the maximum file size (in MB) allowed to be
uploaded in these fields. The default values are 1 file and 1 MB. Note
that the option for the number of files is not displayed for the fields
where only one file is supposed to be uploaded.
If the uploaded files do not respect these limits, the form is not sent
and a message is displayed.
task-2798576
Part-of: odoo/odoo#89055
Since commit [1], when we are in the `/shop/cart` page and if a language
selector is in the header, a cart popover also appears when hovering the
languages. This happens because the `websiteSaleCartLink` widget
selector also targets the cart links inside the language buttons.
This commit solves this issue by excluding the language selectors from
this widget selector.
[1]: https://github.com/odoo/odoo/commit/ecefa679b224ce0e4a5a7e91ce28936321132d9c
opw-3288727
closesodoo/odoo#119887
X-original-commit: bdfceb8ed274cd343d273c0a7f9bbb513617a0b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when hovering the shopping cart in the "Boxed" and
"Centered Logo" header templates, the cart popover was not appearing.
This happened because the `websiteSaleCartLink` public widget was never
started with these templates and so, hovering the cart had no effect.
This is due to this widget selector which targeted a cart link located
inside an element with id `#top_menu`, which is not the case in these
templates where the cart link is located outside of it.
This commit fixes this widget selector, in order for the cart link to be
reachable in all header templates.
opw-3267114
closesodoo/odoo#119277
X-original-commit: ecefa679b224ce0e4a5a7e91ce28936321132d9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In edit mode, if the grid mode is toggled and if there are enough
options in the right panel to have a vertical scrollbar (e.g. when we
click on an image to have the image options), a horizontal scrollbar
appears. This happens because the "Add Elements" widget is too large and
it therefore overflows.
This commit improves this widget style so it does not overflow, which
will prevent the horizontal scrollbar from appearing.
task-3098222
closesodoo/odoo#119288
X-original-commit: 784a8f36471a6b7c05452f6b39ee61f6b859d9c9
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit, some behaviors of the forms after being submitted
were problematic:
- with the `On Success` option set on `Redirect`, when going back to a
form after submitting it (with the browser arrows), the fields were
still filled.
- with the `Show Message` option selected, when going in edit mode when
the message was displayed, the submit button was still "loading", even
after saving.
This commit solves this issues by properly resetting the form at each
start and restoring the submit button loading effect when the message is
displayed.
task-2798576
closesodoo/odoo#118645
X-original-commit: ecb3bda77fab512a9790daf58447058f250f49e6
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
This commit makes the image options initialization more robust, by
- checking at the beginning if the specified `src` and `data-original-
src` attributes match with existing files.
- checking if there is a `data-original-src` attribute before applying
the ImageTools options (shape, filter,...).
This is needed because in the case of wrongly hardcoded templates (e.g.
in customizations), it is sometimes not possible to drop any snippet
after dropping an incorrect one. This happens because the image
`SnippetEditor` is not correctly created. Indeed, the start of the image
options is never completed because the promise rejections when a file
does not exist are not properly caught, interrupting the initialization.
Therefore, ensuring that the files exist beforehand prevents these
issues from happening.
opw-3137732
closesodoo/odoo#118546
X-original-commit: 93ddaac87a76d6d1775e0b3e30bb66ca85147503
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- In a snippet in grid mode, resize a column.
- Drag and drop this column in a non-grid dropzone.
- Undo.
=> The column is back in the grid but is still a normal column. The same
happens when doing these steps with a normal column to a grid.
This happens because the class changes are not observed in these cases.
When fixing the drag and drop history in [1], only the style changes
were observed because the class changes are automatically recorded. But
it is not the case after a resize.
This commit fixes that by also observing the class changes.
[1]: https://github.com/odoo/odoo/commit/1dfb127f70832aa9e9022ac337af343b7dc17729
task-3151207
closesodoo/odoo#117854
X-original-commit: 48b3683c4753f1e385ea1692db9c1a15d32cae30
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
This commit fixes some mistakes that were found in the code of the grid
layout option. More precisely:
- When a column was dropped near a grid dropzone (so not inside it), and
if its height was bigger than the grid, the `rowCount` attribute of the
row was not updated to the correct number of rows => there was one extra
row.
- When we start dragging a grid item, if we do not go over the starting
grid at all (it happens if the move handle is placed outside of the
row), the `rowCount` of the starting grid was never updated. This is
because the resize is done at the "out" of the dropzone so if there was
no "over", it cannot be done.
=> As a fix, the starting grid is now always resized when we drop the
column.
- When dropping a grid item inside a non-grid dropzone, its `z-index`
CSS property was not removed.
- When a grid item becomes a normal column, when dropping it in a non-
grid dropzone or when toggling the normal mode, the resize classes
(`g-col-lg-*` and `g-height-*`) were not removed from it.
- When a normal column becomes a grid item, the padding and offset
classes were not removed and the `col-` class was not systematically
synchronized with the `g-col-lg-*` class.
=> The two previous points need to be fixed because after doing multiple
drag and drops, the classes could become inconsistent. This happened
especially with columns whose width changes a lot between snippets (like
with Masonry columns, because of the padding).
- When going back to normal mode, the `--grid-item-padding-*` CSS
variables were not removed from the row.
- In commit [1], a comment that should have been modified has been
forgotten.
[1]: https://github.com/odoo/odoo/commit/67d1b078329600efce414974307d74e9fa9ba9fe
task-3151207
X-original-commit: 4afd418e1a1d4231369aab08dfa5c2d10ca9a310
Part-of: odoo/odoo#117854
Since commit [1], which updates jQuery to version 3.6.3, when dropping a
dynamic snippet (Events, Blog Posts), it appears broken. This happens
because in jQuery 3.5.0, the `htmlPrefilter` function (which is called
when the dynamic snippet content is rendered) has been modified.
The dynamic snippets are broken because auto-closed tags are contained
in the data that are fetched from the server and without the jQuery
regex to fix them, they are never closed properly, which breaks the
rendering. Indeed, the `etree.tostring(...)` function auto-closes the
tags of elements having no content when no method is specified as a
parameter.
This commit prevents auto-closed tags to appear in the data sent by the
server when rendering the dynamic snippets, by enforcing the fact that
they will be used as HTML.
[1]: https://github.com/odoo/odoo/commit/ae1cd3d5bb99b9835501144522b71f152aaf8e34
task-3199318
closesodoo/odoo#116929
X-original-commit: f6cbec8d0116305041f018870ab63e26c8cbef41
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When using the 'toggleDeviceVisibility' option, we can see that there is
a mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> at 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding/showing an
element in the mobile/desktop view (for example, if it does not look
good in one of them) has no effect until the screen reaches 768px.
This commit increases the screen breakpoint at which the 'toggleDevice-
Visibility' option is applied, that is, at 992px instead of 768px, in
order to be consistent with the display.
task-3110770
closesodoo/odoo#114977
X-original-commit: b062b280fdadcde857fff4f7a57876da50542cb3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Since [1], some mass_mailing snippet templates now have images with
shapes by default. However, the shapes were not added correctly:
- for the Blockquote snippet, the files specified are not correct (wrong
names and wrong extensions).
- for the Team snippet, the shapes are not present when dropping it.
This commit fixes that by properly adding the shape images as defined in
the commit [2]. It also removes the "circle images" files as they are
not necessary anymore. The basic shapes were also fixed by removing
their width and height, since the dropped snippets looked weird because
their images have a default width smaller than the shapes.
[1]: https://github.com/odoo/odoo/commit/f4995f560003c2180ad3cef50e1b172a151e50c8
[2]: https://github.com/odoo/odoo/commit/eb1262960f54fd81424a86ef4d6693a950e76cb4
opw-3137732
closesodoo/odoo#114966
X-original-commit: b1a3a3b18370ad76280726298602815769dce1c2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
From BS4 to BS5, the `form-control-file` class has disappeared and
became `form-control`.
This commit replaces the occurrences of the old class by the new one.
It is necessary because by letting the old class, it is impossible to
place a form label above a `File Upload` field.
Indeed, since the `.form-control-file` CSS rule setting the `display`
property to `block` has been removed, the file input now has `display:
inline-block` by default, which is why the label would end up on the
same line as the input, instead of on top. With `.from-control`, this
rule is back, allowing to place the label on top again.
After this commit, the look of the file input will change. This is
because in BS4, with the `form-control-file` class, the input was the
browser native one. It could be customized using `.custom-file` (and
the associated `custom-file-*` classes). But in BS5, the file input is
directly a custom one, thanks to custom styles added on top of `.form-
control`.
task-3071151
closesodoo/odoo#114261
X-original-commit: 7dcfe19c15bd96d65e5fda463ad65d083c6b8fcf
Related: odoo/enterprise#37744
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since commit [1], an `align-items-start` class is added when going from
grid mode to normal mode in order to always have one of the four choices
of the Vertical Alignment option selected. Indeed, without this class,
none of them are chosen. However, only a few snippets have this option
and it is therefore not possible to modify this class easily in the
snippets that do not have it (except removing it from the DOM manually).
The real issue in fact comes from the computation of this option widget
state, which should select the last button (so the `align-items-stretch`
one) if no class is present, since the behaviors are equivalent in these
two situations.
This commit removes the addition of this `align-items-start` class and
fixes the `_computeWidgetState` of the Vertical Alignment option.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3142615
closesodoo/odoo#113949
X-original-commit: 75ef0d5d7ed000cf55b47bebb00cc2d0bb34b581
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
When drag and dropping a grid item and then undoing the operation, it
is not undone correctly, causing the grid items to be broken. This
happens because since `observerUnactive` is called at the start of the
drag, the style (like the `grid-area`) and the grid classes changes are
not recorded and therefore, undoing does not restore them.
This issue was previously fixed in [1] by removing the call to
`observerUnactive` but it should not have been done and this call was
restored in [2].
This commit solves this issue by activating the observer for the
changes that have to be recorded when drag and dropping in grid mode,
in order to undo them properly afterwards.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/pull/106029
task-3074139
closesodoo/odoo#113384
X-original-commit: 1dfb127f70832aa9e9022ac337af343b7dc17729
Signed-off-by: Outagant Mehdi (mou) <mou@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>
In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: website
When dragging inner contents, dropzones appear in the Carousel snippet,
allowing to drop them directly in the element with the `row` class,
where it should not be the case. This is due to the `content` class
present on these elements and to the drop-in rule for inner contents
that allows them to be dropped in elements having this class.
This commit fixes this issue:
- in stable: as the XML files cannot be modified, the drop-in rule is
patched in JS to exclude the elements having both the `content` and
`row` classes.
- in master: it removes the `content` classes from the rows of the
Carousel snippet. It also removes this class from the drop-in rule,
as only Carousel was concerned by it.
See [1] for the following of this fix in design-themes.
[1]: https://github.com/odoo/design-themes/pull/603
task-3011192
closesodoo/odoo#108646
X-original-commit: 882c483ec1107879cd1c5693ea5cfce08e3220cc
Related: odoo/design-themes#628
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When trying to replace an image with the media dialog, there is first a
click on the image, which activates the options of the image, and then
a double-click, opening the media dialog to choose the new image.
However, the media dialog does not wait for the image options to be
completely initialized before opening.
This behaviour is in general not problematic but if it happens quickly
enough, in a tour for example, it might cause a traceback. This happens
because the renderings (in `_renderCustomXML`) of the image before and
after replacing it happen too closely, making the first one lose the
reference to the image parent.
This commit fixes this issue by waiting for the options to be fully
initialized before opening the media dialog, that is, by adding an
empty action in the mutex and waiting for it to complete.
runbot-10692
closesodoo/odoo#108738
X-original-commit: 7667ba149aaf179f430615c4aba4b963d1d167c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when dragging/resizing a grid item, the background
grid that appears was not clearly visible if the background color was
dark.
This commit adds a light line next to the dark background grid lines in
order to make them always visible. It also moves the CSS rule about the
grid cell inside the background grid rule, as it is more correct
like this.
task-3060593
closesodoo/odoo#107576
X-original-commit: 1aa81243b7c80069c576381e2f3b04281455794f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When we are in grid mode, if we decrease the screen size small enough,
the display is back to `flex` and the columns are displayed one above
another (-> mobile view). However, the columns in normal mode do that
for screen sizes higher than the breakpoint set for the ones in grid
mode, which is inconsistent. Moreover, as the images have their
`object-fit` property set to `cover`, they become really deformed and
therefore do not look good.
This commit solves these issues by increasing the breakpoint at which
the grid mode switches to the mobile view, that is, from `md` to `lg`.
opw-3069234
X-original-commit: 1ec3c4726ea92452dfe091eac96bcc9f3fdfa589
Part-of: odoo/odoo#107172
In commit [1], a check was added to see if a media is editable in order
to prevent its edition if it is not the case. However, this also had as
effect to block the edition of some grid images. Indeed, as the columns
in grid mode containing only an image have their `contenteditable`
property set to `false`, the images don't pass the check because their
parent is therefore not editable.
This commit removes the `contenteditable` property from these columns
in order to make their images pass the check and therefore allow their
edition.
Tests are also added, ensuring that these grid images can be correctly
replaced.
[1]: https://github.com/odoo/odoo/commit/ddade4346347266b7f699d05865578dc96e2bf98
opw-3028116
Fixes#103234closesodoo/odoo#104899
X-original-commit: d8c374e3e6b31bf88aa42952aadf3379936f7600
Related: odoo/design-themes#617
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Some snippets have a "hard coded" background color which doesn't change
when we want to put a preset color (theme). We have to delete the back-
ground first before being able to choose a preset color.
This commit fixes this behaviour by putting a preset color by default
on the concerned snippets (instead of a fixed color). These snippets
are searchbar and text highlight.
task-2824393
closesodoo/odoo#103123
X-original-commit: 4a1442679bb1058d08428e08bec3433e968fb64b
Related: odoo/design-themes#604
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The Masonry and Big Boxes snippets don't have a background option
because their blocks are supposed to take the whole space, so a
background is not really necessary. But since the addition of the grid
mode, these blocks can be placed more freely and a background may
therefore be necessary.
This commit adds the background option to these snippets.
task-3014939
closesodoo/odoo#103109
X-original-commit: 019f6824caafdf2cdc79babcbe45af3db0df1550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When two building blocks are one above another, if there is no padding
between them, we notice that the move handle of the columns of the
lower block is located on the upper block. This is a problem when the
upper block is in grid mode because since the mouse is above it, the
drag is considered over this grid, instead of the block from which
the column comes from. The column is therefore "trapped" in the grid,
which is unconvenient.
This commit solves this issue by "canceling" the over if the start of
the drag falls in this situation. More precisely: if the first dropzone
to detect the "over" event when we start to drag a column is a grid
dropzone that is glued to this column, then the over is canceled.
task-3013882
closesodoo/odoo#103107
X-original-commit: 122eb3821a9294e4f6e2d346df942b394ca039dc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1], the Masonry snippet is in grid mode only and its templates
have been modified to allow this mode. However, some of them don't look
good and have to be improved.
This is what this commit does:
- some text blocks were too small so their height has been increased
- the Masonry second default image has been replaced by another one
that looks better.
[1]: https://github.com/odoo/odoo/commit/85b352af319edec84407f2046cf795b4e5503460
task-3013055
closesodoo/odoo#102984
X-original-commit: ad8926eafd34c2743e1a5247f6171fd183e6e506
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In [1], the resizing and the drag and drop of a grid item both put
it in front of all the other items and in front of the background grid
(thanks to the `z-index` property).
This commit changes that behavior: now, the grid item stays at the same
z-index if we are resizing it or if we are dragging it over the grid
from which it is coming. In the case of a drag over an other grid, it
is placed in front of all its grid items. In all these cases, the grid
item is placed behind the background grid.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
closesodoo/odoo#102525
X-original-commit: 67d1b078329600efce414974307d74e9fa9ba9fe
Related: odoo/design-themes#601
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In grid mode, when a grid item width is one (grid) column, if its
content is bigger than a column size, it makes the column
grow with it while the other ones are shrinking.
This issue was solved in [1] by using the `word-break` property but it
is not the best solution. This commit fixes the issue by setting the
`min-width` property to 0 instead.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
X-original-commit: 5d37ada861bf5de348de54d5d7de0d06e14ed28e
Part-of: odoo/odoo#102525
When the footer has the "Slide Hover" and the "Shadow" scroll effects,
and if it is in grid mode, the grid dropzone flickers a lot when we
drag a column over it. This happens because the scrolls caused by the
dragging, the growth of the grid and the scroll effect all happens at
the same time.
This commit removes temporarily the scroll effect of the footer during
the drag and drop to avoid this situation. It also has the advantage of
displaying the footer entirely, making it easier to see where we are
placing the elements.
task-2973198
X-original-commit: bbde919634aeaffcf421283445e25181a522f287
Part-of: odoo/odoo#102525
When going from a dropzone to an other, and if it is done really fast
or if the dropzones are really close (glued to each other) or if they
are overlapping, the order of the "over" and "out" dropzone events is
not the one expected.
Indeed, instead of having over > out > over, we have over > over > out.
This resulted in a traceback when using the grid as the listeners and
properties were therefore not removed correctly when such a case
happened.
This commit adds the support for this situation by first detecting if
two "over" are following each other and then making a virtual "out" if
this is the case.
task-2973198
X-original-commit: c6886410603a16b6a3c5fe459d273dd883c110c7
Part-of: odoo/odoo#102525
When removing all the columns of a block with no parent, like the
footer, a traceback was appearing because updateUIVisibility was trying
to access the properties of an inexisting parent. This commit
fixes that by first checking if the parent exists.
task-2973198
X-original-commit: 3e7ad08581295af6a986ba2b81ec25d9cd78e91d
Part-of: odoo/odoo#102525
This commit modifies the Masonry snippet, along with all its templates,
in order to always be in grid mode.
A change worth noting is that the images are now real images and not a
background and text can be added over them with the "Add Elements"
option. This change happened mainly for the look of the mobile view but
also because it is more logical since the snippet is supposed to
contain "images" and "text".
The themes extending Masonry have also been adapted in [1].
[1]: https://github.com/odoo/design-themes/pull/592
task-2973198
X-original-commit: 85b352af319edec84407f2046cf795b4e5503460
Part-of: odoo/odoo#102525
When dragging a grid item downwards in a grid, an infinite number of
rows can be added. This is unconvenient because it is difficult to
escape a grid if the snippet is "container-fluid" for example.
This commit limits the number of rows that can be added at once when
dragging downwards. The limit is fixed to 10 rows. Of course, it is not
a total limit, this means that after dropping, if the grid item is
dragged again, 10 additional rows can be added.
task-2973198
X-original-commit: 888f522aa812136f10af1c5fad8f17eea0c3b5b6
Part-of: odoo/odoo#102525
When dragging a grid item and dropping it outside (near) a dropzone,
and then undoing the operation, the grid item didn't return to its
original state: some removed classes and style properties were not
added back. This would cause the item to be broken and trying to drag
it had unexpected results that could even lead to a traceback.
This behavior was caused by the fact that the grid item was not
attached to any element when these attributes were modified, so the
changes happened "nowhere". This commit fixes that.
task-2973198
X-original-commit: 83c07fcce898225f06f1ba84059a031409db0627
Part-of: odoo/odoo#102525
Currently, the toggle to grid mode is not the same process for all
snippets: some have both the option 'Layout Grid/Cols' and the ability
to toggle on drag but other don't have the option, making it
complicated/impossible to leave the grid mode. Also, the snippets for
which the grid mode has been blocked don't have their move handle
anymore, which prevents them to use the normal drag and drop (it was
hidden because dragging them would toggle the grid mode).
This commit uniformizes the grid mode for all snippets and adds the
move handle back to the ones that cannot use this mode. It also
improves the grid mode of the 'Items' and 'Carousel' snippets.
More precisely:
- All the snippets that are allowed to have the grid mode now have both
the option "Layout Grid/Cols" and the ability to toggle on drag.
- The snippets who cannot toggle the grid mode have the move handle
back but it doesn't toggle on drag and they don't have the option. They
use the "normal" drag and drop.
- The drag and drop has been improved to allow normal columns to go
inside the grids. Indeed, since the drag was previously blocked, this
case could not occur but now that it is possible, it had to be taken
into account.
- The grid mode of the Items snippet has been improved by removing the
"hardcoded" height that was breaking the grid.
- The vertical dropzones of Carousel appearing when dragging inner
content have been removed because they appeared in grid mode and were
breaking it. It is also more logical because now that this snippet has
a column option, vertical dropzones should only appear when dragging a
column.
task-2973198
X-original-commit: 84d684d8bdf43d3db11defd8174dee44775085c2
Part-of: odoo/odoo#102525
The 'Picture', 'References' and 'Pricelist' snippets have some of their
content placed outside the row element, causing them to not be in the
grid when activating the grid mode, which is unconvenient.
This commit allows these contents to be placed in the grid when the
grid mode is toggled, by creating a column and putting them in it.
task-2973198
X-original-commit: 6f3041f9015c50b4986b3c26aad86da4a0a04d50
Part-of: odoo/odoo#102525
*: website
In grid mode, the images take the whole space in their column so they
always have the same size as them. However, if text was added in the
column (before or after toggle), it always looked like it was
overflowing and the overlay would not cover it even after resizing.
Also, since these images have the value of the `object-fit` property
set to `cover`, the images are cut if they are too big for the column.
This is problematic if the image has a shape because the shape is cut
too, ruining the visual effect.
This commit solves these issues by distinguishing the images that are
alone in their column from those that are not. An image is considered
alone if it is a direct child of the column and if there is no text in
it (the line breaks and empty lines are excluded). Now, only this kind
of images, if they have no shape, take the whole space in the column
and have `object-fit` set to `cover`; the other ones behave like the
columns in normal mode.
This distinction also allows to block the edition of the columns
containing only an image. Indeed, adding text or dropping inner content
in them had the same overflowing effect.
task-2973198
X-original-commit: e9c7e020daf88022d6e02de0a5620074e8417b5a
Part-of: odoo/odoo#102525
The grid mode allows some snippets to move and resize their columns in
a grid. However, some of them were blocked because they don't look good
in this mode. This is the case of the Big Boxes snippet: because it
contains two blocks full of padding and since toggling the grid mode
removes this padding, it ended looking weird.
This commit allows the previously blocked Big Boxes snippet to toggle
the grid mode. More generally, this commit allows snippets having only
columns containing a background color to look good in grid mode by
keeping a more logical padding for them.
task-2973198
X-original-commit: a051922f8359178f4abe578ce9555d34cbb02613
Part-of: odoo/odoo#102525
The merge of [1] happened before its code was totally cleaned. This
commit makes up for that: the variables have been correctly renamed,
the comments have been cut at 80 characters and useless blank lines
have been removed.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
X-original-commit: 98741204c7b15cadeb22d6b536b0027327ba69fe
Part-of: odoo/odoo#102525
This commit fixes the issue where the undo of the resizing of an
element is not done in one step.
Steps to reproduce:
- drop a snippet (like text-image)
- resize the image
- undo
=> you have to click multiple times before going back to the initial
size.
task-2968749
closesodoo/odoo#101693
X-original-commit: c4b8a2a6a7548e8a81d1ded58e6bc0e309b02975
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds the possibility to use a grid to move and resize
columns inside some building blocks.
More precisely, for the majority of the building blocks having columns,
it is now possible to toggle between the current layout (= normal mode)
and the grid layout (= grid mode). The grid mode can be triggered in
two ways:
- by using the "Grid" button in the options (when available),
- by dragging a column using the move handle.
The toggle places the different columns in the grid as close as
possible as how they were placed in normal mode.
The normal mode is toggled back by clicking on the "Cols" button (when
available).
Since the move handle is now used to trigger the grid mode, the columns
in normal mode are now moved using the arrows.
NB: to avoid any confusion with the word 'column' in the explanation
below, the BS column will be called 'grid item' and the grid column
will be 'column'.
When in grid mode, the building block is a grid with 12 columns and a
number of rows which depends on the height of the grid items.
This mode offers the following functionalities:
- Moving a grid item:
When a grid item is dragged, it can be placed anywhere in the grid. If
it is dragged towards the bottom, new rows are added in the grid to
increase its height and to place the grid item lower. These added rows
are removed when it is dragged towards the top.
A grid item can also be placed over an other item (-> they can overlap)
and their order can be changed using the two new buttons to place an
item in front of/behind all the others.
A grid item can be moved from a grid to another, and also from a grid
to a building block in normal mode.
- Resizing a grid item:
A grid item can be resized vertically, horizontally and diagonally with
the help of the grid. When resized towards the bottom, new rows are
added in the grid and they are removed if it is towards the top (like
with the drag and drop).
- Adding elements:
The "Add Elements" option allows the user to add as many images, text
blocks or buttons as wanted in the grid.
Inner contents can still be dragged and dropped inside a grid item.
- Changing the padding of the grid items:
The padding option allows to change the vertical/horizontal padding of
all the grid items at the same time.
- Mobile view:
When in mobile view, the grid items are not in a grid anymore (the
display is back to flex) but they keep their grid properties. They
cannot be resized, nor dragged and dropped but they can be moved using
the arrows. By moving this way, it does not impact the desktop view.
task-2825241
closesodoo/odoo#93144
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now trigger an UI update for all the options when clicking on the mobile
preview button. This is at least important for the next commit in this
PR to update the visibility of the different overlay elements as some
will be shown in desktop and some other on mobile.
task-2825241
Part-of: odoo/odoo#93144
Co-authored-by: qsm-odoo <qsm@odoo.com>
When adding an option, using data-select-style with a CSS variable in
data-css-property does not work. This commit adds the support for the
use of these variables.
task-2825241
Part-of: odoo/odoo#93144
In the Firefox browser, when in edit mode, if we click on an input
element, a traceback sometimes appears for no apparent reasons.
The error comes from the fact that when calling the getRangeAt function
on the selection, it sometimes returns a "restricted" range.
Ex: Range { commonAncestorContainer: Restricted, startContainer:
Restricted, startOffset: 0, endContainer: Restricted, endOffset: 0,
collapsed: true }
And so, trying to access a container property (ex: nodetype) will
trigger a "Permission denied to access property "nodetype"" error.
This commit provides a solution to bypass the error. It consists in
redefining the getRangeAt function as the following:
- A range is created by calling the original function that was saved
beforehand
- We check if the range is restricted (the same way as what was done in
this issue: https://github.com/tinymce/tinymce/issues/2194)
- if it is not restricted, the range is simply returned
- otherwise, a new range is created manually, based on the selection
Steps to reproduce the bug:
- Install website
- Drop a form snippet
- Click on the input fields
-> Sometimes a traceback appears
task-2810365
closesodoo/odoo#92097
X-original-commit: c32f6efa956ae9affbb80f84b66118e343268eff
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Soukéina Bojabza