The dynamic placeholder result was not added in the
editable dom in some situation. When the editor was
in rollback mode `true` after a `commitChange`
( maybe because of a `_toInline` called) the result
of the dynamic placeholder was rollback.
task-3044924
closesodoo/odoo#104343
X-original-commit: e9bd4f020ff4a5dd4240fde9caef0bded9a2e28c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
When checking whether an element was removable or not, we failed to
check whether it was within the editable area. As a result it was
sometimes possible to accidentally delete something outside of it. To
reproduce the bug, insert a link in a blank editor, then press delete
repeatedly until the whole link is gone, and then one more time. This
deleted an element from Odoo's UI.
task-2993740
closesodoo/odoo#104268
X-original-commit: 55e4e0577ac8a62d57f759572b8a5e608c7582b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: mass_mailing, website
Commit [1] introduced data-option-name allowing to name snippet options
without data-js so that their automatic snippet-option-XXX class was
not snippet-option-undefined. This was indeed useful to target specific
options in tours.
The attribute is however a complete duplicate of data-js (if you use
one or the other, it does exactly the same thing). Indeed, you can
define a data-js without a linked JS class (as it is already done). And
if you define both expecting the class using data-option-name but the JS
used from data-js that won't be the case, data-option-name is simply
ignored.
This removes data-option-name. This prepares refactorings that will be
done in the future:
- The way to define option in XML will be reviewed (probably client
side definitions, probably OWL templates).
- Adding data-js will probably require a JS class to exist, but all
option definitions of Odoo will declare one to ease extensions and
stable fixes.
Those are theoretical at this point though. This commit main focus is
simplifying the code.
[1]: https://github.com/odoo/odoo/commit/7b0a147cd43e8e890ebe5a882292a69a5c8c90acclosesodoo/odoo#103988
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.
This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.
Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:
- Current height is 700px
- There is some code that forces a min-height on all carousel items so
that they are the same height. As the gallery image dimensions depend
on the block forced height (this is how the snippet work), the forced
min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
is already set)... it ends up removing it as it thinks that setting
that height is not needed as the snippet is now "naturally" 800px tall
thanks to the carousel items' min-heights.
opw-2838774
closesodoo/odoo#104068
X-original-commit: d4d0da320d42093e720c7d440cf6611249c0295a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When trying to edit a link with mailto, there is an "https://"
added and preventing the link to work successfully
After this commit:
The mailto part of the link is correctly kept as is and the link works.
Task-2961012
Task-2977682
closesodoo/odoo#104064
X-original-commit: a22d6d1859a8f97c3cccdba755392cd13d7eb866
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit, the table border color was only applied to the
columns (left and right borders).
This commit applies the border color to all borders and adapt the color
to be consistent with the dark mode.
task-2710677
closesodoo/odoo#103162
X-original-commit: fc8a0653c2e98cbda9c1ff60f3a5ea7347aadd48
Related: odoo/enterprise#32786
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit:
The behaviour of the text were not identical in edit mode and after save, the
word was wrapped in edit mode.
After this commit:
To make the behaviour identical by unsetting the default overflow property
in edit mode.
Task-2878307
closesodoo/odoo#103975
X-original-commit: 6177fac863a29c86ed4e5ede8d48aa31da3a8508
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When a change was made on the same record, the editor could wrongly
be reset.
Step to reproduce:
- Go in knowledge app
- Click inside the editor outside a template block
- Click on inside a template block
- Click inside the editor outsie a template block
=> The editor is reset
closesodoo/odoo#103947
X-original-commit: d0a079a76c3f5078178717966e3d4caf0987ebf9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Edit
- Add a snippet with columns
- Save
- HTML editor
- Set up a border on one column of the snippet with different colors for
the top/right/bottom/left sides
- Edit
- Click on the column => crash
This is only an example, but if a colorpicker widget is linked to a
SnippetOption instance's `selectStyle` method designed to handle the
"border-color" property of an element, the value received can be split
if the item uses different colors for its top/right/bottom/left borders.
For instance, you could receive "red blue" if the item has red top and
bottom borders and blue left and right borders. In that case, the
colorpicker widget code would try to add the class "bg-red blue" on its
preview item which would crash because of the space inside).
After this commit, we simply do not show any color for this case.
opw-2803311
closesodoo/odoo#103842
X-original-commit: 484230481cd7195e2c992e673a2b6e627baf505d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When a table isContentEditable=false:
- Don't show the resize cursor
- Don't show the table ui menu (which allows to move columns/rows)
Currently in Knowledge, when an embedded view contains a `<table>` element, it
was possible to use the editor to edit rows and columns of the view and it is
not intended. Those table are not editable, and as such the menu to edit them
should not be shown.
Task-3000318
closesodoo/odoo#103805
X-original-commit: aec6b02dacf02f18b53cb8b31ffbb52772f5ac27
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reprodue:
- enable any rtl language (arabic)
- move to the product page for exemple
- the page is frozen (dependecy loop in css)
Bug:
when the CSS gets minified the missing semicolon error spreads and
produce an invalid file
Fix:
added the missing semicolon
opw-3019173 3032064 3032250 3035077 3034712 3035077 3023730 3022962
closesodoo/odoo#103699
X-original-commit: 8048bdac4cec56edd92c68f7041b802376f9372c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: website, test_website
Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.
With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).
But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).
This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.
Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.
Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
task-2687506
closesodoo/odoo#103562
X-original-commit: 931d488af0d4dce529e4ea4ab3c8b827bda0d699
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
In the Website Builder, when clicking on the THEME tab, and clicking on
the "Switch theme" button, the loader behind the dialog was not placed
correctly.
After [1] moved the manipulators inside the iframe, the css rule for the
loading elements was not updated to remove its right value, used to
position the loading element next to the right panel.
[1]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
X-original-commit: 106a5a56a96090ae4adfd9e7b3ea2f93d69dca22
Part-of: odoo/odoo#103562
* web_unsplash, website_forum
With [1], the access errors when a portal user were using the media
dialog got fixed. It also came with the unsplash capability for portal
user in the media dialog.
Still, there was a remaining problematic point: an internal user can't
upload an unsplash image in the backend through the media dialog. It
doesn't really make sense for an internal user to have less right than
the portal user.
This commit corrects that part.
Note that only unsplash images were problematic, not regular uploaded
image as the difference was that unsplash images attachment are saved
with an `url` property, which was triggering due to [2].
Finally, it was chosen to make that "bypass" more robust and opt in, so
forum and unsplash are allowing their use cases to go through, it's not
done in a generic way anymore.
Also fixing a small issue about the res_id not being sent when editing a
forum post, because it was assuming that the URL would end with the ID
which is not the case when you edit your answer.
[1]: https://github.com/odoo/odoo/commit/e10493711879c7f0cc8832db3f1936c622ea605c
[2]: https://github.com/odoo/odoo/commit/bfffe39f1376a56226572295b945a2cc73ba50ce
task-3007844
closesodoo/odoo#103138
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>
Before this commit
1) click on a record in a list view
2) change the html field of a record
3) click on the top right arrow to change the next record
4) click on the top right arrow to change the previous record
5) click on the top right arrow to change the previous record
The value is not updated corretly at step 4, retaining the value from the
previous record. The wrong value is then saved at step 5.
After this commit
Properly reset the HtmlField property `currentEditingValue` when
the update of props value does not comes from the editor.
X-original-commit: 39d02c3cdc2d4256b62cd6414369a8cf82efff48
Part-of: odoo/odoo#103034
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting.
That fix prevents attachments from 'dangling' and being garbage collected later.
That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now.
related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4
task 3003939
closesodoo/odoo#103038
X-original-commit: 69fdca133b06eb66443635bc52d380233580ef51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this fix it was possible to edit a media that was not editable
because no check existed for such a thing.
task-2962912
closesodoo/odoo#103035
X-original-commit: ddade4346347266b7f699d05865578dc96e2bf98
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Followup of #102259
Instead of adding a class to remove field borders, we want the opposite: hide the borders by default, except when specified specifically with a `.o_field_highlight` class (on a parent or the field itself). This makes it much easier to add field borders on specific parts of the ui (just add the class in the template), rather than having to _remove_ the class through a js override, which is far less discoverable.
I converted all the new rules to work opposite as before, same for the JS logic which added the class based on mobile device detection (size + touch support).
closesodoo/odoo#102977
Forward-port-of: odoo/odoo#102823
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
This commit adapts the module in order to correctly handle color-scheme
variations.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Add 'black' and 'white' color in the list of backend's $theme-colors to
preserve during website's customization.
This commit is preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
This fixes a bug that occurred when using BACKSPACE to remove the last
character of a text node, if said character was preceded by a space and
said text node was succeeded by a <br>. The space was removed along with
the character. This was simply due to a missing state restoration rule
to handle this specific case.
task-2990229
closesodoo/odoo#102974
X-original-commit: 5e90529388095321da8b504ebf543c4c3054845e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a new .o_field_highlight class which can be used on fields and field
containers to force having a border on fields (e.g. in places where they
are heavily used inline, like Settings, or where it might not be clear
that you are using a form and that these are fields; e.g. sidepanel,
etc.
This class is automatically added when the device size goes below the
XSS breakpoint, or when the device has touch input (our best metric for
mobile device detection, where hovering is not possible).
X-original-commit: 0f0c8e3b9f7c42c5126dc49d3378d41ad76afbf3
This commit refactors the style for borderless inputs and
adds a special class to better manage where they should be used.
closesodoo/odoo#102848
X-original-commit: 6b45cd5f3fbe0986e36401308d19214b689adc45
Related: odoo/enterprise#32609
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
The RPC that the m2o widgets used by snippet options make are cached at
the widget level. When two m2o widgets make the same RPC, they are
indeed made twice. This commit just move the cache outside of the
widget instance and thus makes it so the same RPC made across multiple
m2o are cached.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC. Then each further drop of snippet made the exact
same RPC for no good reason.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
closesodoo/odoo#102800
X-original-commit: 8e08c896df9ed5a7a0e559f1dbd8812f87908a39
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a snippet option uses a m2m widget, the domain used for the
internal m2o widget which allows to select records evolves to receive
the subdomain `['id', 'not in', <selected-ids>]` with `<selected-ids>`
indicating the m2m records which are already selected.
M2o rpc are cached... based on the whole query object from which they
are created. The domain is part of that query object.
Both those concepts actually conflicted: the initial RPC when no ID is
selected was made with no subdomain, while the subsequent RPC when no ID
is selected were made with the `['id', 'not in', []]` subdomain. The
cache system did treat the resulting domains as different requests. Now
we avoid adding the useless `['id', 'not in', []]` subdomain as it
should already have been done without a cache system in place.
Note: this was particularly visible because all main snippets have the
"Conditional Visibility" option which uses 3 m2m widgets. At each drop
of such main snippet in the page, the option is created and the 3 m2m
widgets made their RPC with the initial domain. Then on click on the
snippet, a new RPC was made with the problematic subdomain, making the
first click on snippets being needlessly slower.
In the future, the system should be further improved to not require
those RPC on initial drop and clicks, especially as the "Conditional
Visibility" m2m widgets are hidden by default. This fix focuses on
fixing the generic m2m widgets.
X-original-commit: 017a468547eafa3e34f584379d3f05b3ed1db487
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In mass_mailing, the paragraph alignment dropdown menu is wrongly
positioned by Popper since the upgrade to Bootstrap 5. Other dropdowns
in the toolbar had the `data-bs-display="static"` attribute but it seems
that paragraph alignment was omitted by mistake.
task-3002168
X-original-commit: 8a372800b9a035893d9f9ecdf7afce17aef3f1b2
Part-of: odoo/odoo#102734
The iframe in mass_mailing is self-resizing in order to avoid having two
vertical scrollbar side by side. This failed since the conversion to OWL
due to the vertical offset added when resizing having become
insufficient. This adds a class to the <html> element of the iframe to
identify when it's in the context of mass_mailing so we can remove the
overflow visible style that is not needed in this context. This allows
us to remove that vertical offset altogether since the scrollbar
disappeared.
X-original-commit: 4f538911d68afdeca0253f15c9e8ffdbed4e995c
Part-of: odoo/odoo#102734
Before this commit
When clicking on "create" from a form view in mass_mailing, the
"template picker" was not presented.
task-3002100
closesodoo/odoo#102725
X-original-commit: 664d5982663517e8e2f2f87b355fd7d3c72285f1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The `scrollTo` method and related utils (jQuery animate, ...) were not
properly adapted to work in the context of multiple documents. E.g. the
website editor code (outside the website iframe) is calling the
`scrollTo` util to scroll to added snippet elements (inside the website
iframe). In that case, the util was performing some searches in the DOM
outside of the website iframe while it was meant to be done inside. The
result was that the scroll was not considering the website fixed navbar
and scrolled "too far".
Another bug is visible only when the scrollbar is left to be the natural
browser one (not on the `#wrapwrap`). In that case, the `scrollTo` util
simply had no effect anymore as the `animate` override of jQuery was not
adapted.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
X-original-commit: ab417de98068afaaa12995726c7c6445f075ca4f
Part-of: odoo/odoo#102785
Due to the 'transform: none' applied on images and icons on mobile, some
animations do not work in mobile. This commit makes an exception to this
rule for animated images/icons.
task-2984828
closesodoo/odoo#102713
X-original-commit: 78098b3db96e796ae6a09bd0f4bec1eb0c384d28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the autocomplete dropdown no longer had a maximum
height, which meant that when it contained a lot of elements, it hid the
entire editor panel.
Indeed, since the CSS of the menu snippet is no longer that of the
"frontend", the 'max-height' CSS rule defined for the autocomplete
dropdown in the frontend (introduced by this commit: [1]) was no longer
applied on the autocomplete dropdown of the backend.
In this commit, we therefore moved this css code of the
'ui-autocomplete' defined for the frontend into the common css file
(backend + frontend) in order to return to a situation where this code
was applied to all autocomplete dropdowns in Website. And thanks to
that, we were able to remove the css file "edit_menu.scss" which
copied/pasted the frontend 'ui-autocomplete' code for only one of the
backend 'ui-autocomplete'.
[1]: https://github.com/odoo/odoo/commit/032dd007157de00b683a9d753aa929741c107c01
task-2900529
closesodoo/odoo#102719
X-original-commit: cce26d7697c73326e0a6f2ec81e01b56b4156ad4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Allow the mail templates to activate the dynamic placeholder
like in mass_mailing.
task-2978722
closesodoo/odoo#102603
X-original-commit: f98c472a6d3cd79c28b7b91bdc8359c45c4d3c7a
Related: odoo/enterprise#32484
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Ensure the wysiwyg.js focus() method will actually
restore the cursor in the latest selection inside the editor.
X-original-commit: 54877ecd8bf2454a7023e74aa739921e1468dad8
Part-of: odoo/odoo#102603
Add missing feature of the ModelFieldSelector popover :
* keyboard navigation
* additional debug value
* add default value page ( for dynamic placeholder)
* add validate callback
Migrate dynamic placeholder to be compatible with new OWL field.
task-2978722
X-original-commit: 929108e29168058fad5da85e0ff9c66d2c5b2525
Part-of: odoo/odoo#102603
Avoid having multiple tooltips. We keep only one "t-field"
in the template. The other are replaced by a "t-out".
We also add a specific message when the datetime format is not
respected.
task-2942617
X-original-commit: a99d684507782cd0d9ff700dc7a12f7a46442403
Part-of: odoo/odoo#102545
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
Sébastien Geelen (sge)