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
In some themes, RGBA colors were used to define the colors of shapes.
However, adding this color in the parameters of the background image URL
of a "shape" element was not valid. This caused several bugs, such as
the colorpicker not finding the colors of the shape used, as well as the
colors of the shape being lost after the application of a "flip".
Steps to reproduce the bug:
- In website edit mode, open the homepage page of the Nano theme.
- Drag and drop a Banner snippet onto the page.
- Bug: The colorpicker does not recognize the four colors used by the
shape.
- Click on one of the two "Flip" buttons.
- Bug: The colors of the shape are lost.
task-2824607
closesodoo/odoo#117652
X-original-commit: 0661aa0bbb4751866cfcc9a320a8eff473ba0442
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: website_blog, website
Before this commit, when clicking on a column in the "Blog Posts"
snippet (only with the "Big picture layout" template), the options for
that column were displayed in the editor panel, even if options should
never be displayed for the columns of dynamic snippets.
We had already prevented the appearance of options for elements in a
dynamic snippet in this commit [1] and also in this one [2], using a
'pointer-events: none' to prevent clicking on the elements. However, as
this also removed the mouse hover effect, the 'pointer-events: none' was
changed to 'pointer-events: auto', in this other commit [3], for the
"Big picture layout" template of the "Blog Posts" snippet, so that the
user could see the hover effects in edit mode. And by doing so, we
inadvertently allowed the options to appear again.
In the end, this 'pointer-events: none' was not the right solution, as
for example, for the dynamic "Products" snippet, it may be useful in
edit mode to be able to switch between slides by clicking on arrow
buttons, or to see the mouse hover effects on images (slight zoom).
In this commit, we proceeded differently by hiding the options for
elements that are inside an 'o_not_editable' element (unless they have
the attribute and value 'contenteditable="true"'), excluding them when
generating options so that they don't have associated options.
Steps to reproduce the bug:
- In edit mode, drop a "Blog Posts" snippet in the page.
- Click on the first blog image ("Sierra Tarahumara").
- Bug => Resize options are visible when they shouldn't. The options in
the "column" part of the right panel should also not be visible.
[1]: https://github.com/odoo/odoo/commit/64b663fb42ddca67a06cb067c897abb5a3c4dd70
[2]: https://github.com/odoo/odoo/commit/1345e879d809f811641ea3ad388b5d2c0b16f005
[3]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
task-3054763
closesodoo/odoo#117407
X-original-commit: 80f841e5e33f4694361730d3e015a6a813261685
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reproduction:
1. Switch to French, create a /heading 1, and input nothing
2. The placeholder “Heading 1” is not translated
Fix: add translate function around the terms and manually add the
translations in pot
Note: since OdooEditor.js is under web_editor/static/lib/web-editor,
only the js code under /static/src/ is considered for translation export
The translation is manually added with specific path. In Odoo 16, the
path is changed to /static/src/ and translations can be exported
correctly. The translation code paths added here should be changed in
Odoo 16
Related PR adding translations: https://github.com/odoo/odoo/pull/93272
opw-3224482
closesodoo/odoo#117142
X-original-commit: 5f297854348e073a3915bca5cec13066f6abe90e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Click on "Remove all" to remove all the images of the IG snippet.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).
When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.
When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.
To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.
task-3147271
closesodoo/odoo#116352
X-original-commit: 1c99ab2bc04f65999098f70d062d24ed1ac4a9c3
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>
This removes the `clearEmpty` util which was only used in the `enter`
command.
closesodoo/odoo#114178
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This removes a parameter in `isVisible` that made it consider (wrongly)
all blocks as visible. This made it confusing to use because it was
effectively returning fake news by default.
Part-of: odoo/odoo#114178
When pressing enter at the end of a heading, we want to insert an empty
paragraph instead of a new heading. This failed when the paragraph had
a zero-width space in it because we didn't recognize it as empty.
closesodoo/odoo#116558
X-original-commit: 228e7937f818f5606601e575b1d9a2bb87cda99d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a block ends with a zero-width space, the mechanism that skips these
characters when using the arrow keys should not skip all the way to the
next block. This is because this mechanism happens before the browser
applies its own behavior for the arrow key so we want to let it skip to
the next block instead (or we'll end up navigating too far).
X-original-commit: acae237410e43e1cf97fc023568f49cc2e974db4
Part-of: odoo/odoo#116558
Make sure not to remove inline styles when emptying an element.
task-3102841
X-original-commit: 8d0397c99798f05a41276d62a66f47c41f255ef8
Part-of: odoo/odoo#116558
Before this commit:
When we select text and take the selection to the hex input box and then try
again to add a solid color, it gives us a traceback.
After this commit:
Now it did not give traceback.
Task-2965091
closesodoo/odoo#116539
X-original-commit: 981713bd024a98f5d9099bfec8458224dac32a32
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit:
Applying color on empty selection generate traceback.
After this commit:
Now, able to apply color on empty selection.
Task-3089214
closesodoo/odoo#116435
X-original-commit: b4793caddc52b7f4a6a3510a04604b88387e767e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: web_editor
The table of contents menu entries are generated automatically which
poses a problem in translation mode. The menu translation entries
are not be editable separately, but the users might be trying to.
This commit shows a notification when the user clicks on the menu
entries while in translation mode, explaining that they are generated
from the title entries.
It was initially intended to use a tooltip - but the amount of code
needed to display a tooltip without marking the DOM as modified is
needlessly complex.
To avoid that styles applied on a plain text during translation were
also appearing in the navigation menu, an attempt at adding a span
around them to make sure that their translation was distinct from the
one inside the main content. But this led to the risk of losing
existing translations.
Because of this, and because that situation seems unlikely, any
remaining style in the navigation menu is instead stripped when the
table of content is started to maintain consistency with what is shown
during translation.
An `o_translation_without_style` class has been introduced to indicate
to the synchronization mechanism that only the text must be replicated
for those elements.
For labels that have a different `data-oe-translation-initial-sha` than
their related header, that value is temporarily kept in another
variable, the value is replaced by the one from the header, which make
the synchronization mechanism properly associate them, then on save
the initial value is restored so that the translation is saved for the
right slot.
task-2752391
closesodoo/odoo#116270
X-original-commit: 5776a358e1b42186d2c26c9bc25010a12811f416
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Before this commit:
The traceback appears after cropping an image and then trying to crop it again.
After this commit:
Cropping an image and then cropping it again won't give us tracebacks anymore.
Task-3134764
closesodoo/odoo#116262
X-original-commit: 83cf218b131c47b711327a224b0a0fd81406e8c3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, error messages appeared when a user tried to put an
unsupported video on a page of his website, but the user could still add
this bad video on his page, which broke it.
Steps to reproduce the bug fixed by this commit:
- On a page of a website in edit mode, double-click on an image.
- Go to the video tab and type an unsupported URL like google.com.
=> An error message appears but the user can still add the media on his
page which will break it.
opw-3167707
X-original-commit: 32cd18895ffcf40e4fec4c5674fa97f6663c7f0d
Part-of: odoo/odoo#116128
An error during the conversion of the html field to Owl caused the
embedded style of the Mail Debug tab to be lost because they were inside
a `<link>` element rather than in a `<style>` element.
closesodoo/odoo#115863
X-original-commit: 218909a339b2f3937e6d6f72fd0c6ff62aa305ce
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit is the first step towards the addition of various SVG shapes
for the website app.
The purpose of this commit is to add the new shapes SVGs and to sort the
current shape menu into new categories.
The avoid duplicating the shapes added in mass_mailing, the 3 shapes:
- Circle
- Slanted
- Triangle (corner)
Are now in the web_editor, their existing reference in mass_mailing
template have have been changed to their new locations. To adapt to
`b1a3a3b18370ad76280726298602815769dce1c2` the paths have been changed
and a new record for `s_tech_default_image.jpg` have been created in
the new file `mass_mailing_themes/data/ir_attachment_data.xml` since
it's an image only used in themes. (Also removing `noupdate=0` from
the data element in `mass_mailing/data/ir_attachment_data.xml`
since it is the default value).
I also removed the .png and old .jpg of this image since now the shape
is applied directly on the image.
Since the shapes + their image are converted in a base64 img+svg on
save, we can move the assets of the current website shapes in use
without compatibility issue. Therefore these shapes were renamed and
moved their new folder category.
The SVG width and height of the new and previous shapes was set to
600x600 since they are mostly squarish and are going to be rendered in a
square preview in the future.
To simulate the future preview of the shape selection menu, the
`we-button img` width was set to
`$o-we-sidebar-content-field-dropdown-grid-item-height` and the
`we-button` width to `1/4` in the file `wysiwyg_snippets.scss`.
It makes the preview 60x60 and displayed in a four tiles layout.
Note :
- If later on the SVG are rendered as inline-svg rather than base64
the current IDs inside the .svg might conflict if multiple svg are
on the same page.
- The previous shapes might look a bit weird with the squarish ratio
in preview, alternatives solutions should be explored during the
implementation of the new UI.
task-3094258
closesodoo/odoo#110673
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes an issue that causes thin spacing to appear between
two snippets containing shapes. This bug had already been fixed in this
commit [1] but the theme snippets have not been adapted to the changes.
With this commit, the shapes of theme snippets are automatically adapted
when they are dropped on the page.
Steps to reproduce the bug:
- Choose the "Clean Theme" for a website.
- Drag and drop a "Call to action" snippet on the page.
- Drag and drop a "Text" snippet with a dark background before it.
- Resize the window to change the window width.
- At some points, the gap will appear.
[1]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
task-2824607
opw-3069213
opw-3057533
closesodoo/odoo#115004
X-original-commit: 256ff539afe331544ccb58848f1ecd0eecbe4daa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The insertHTML test file was named too specifically while we want it to
test the recently renamed `insert` command, which doesn't only insert
HTML.
closesodoo/odoo#114176
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
In mobile view, when text as well as link is in range the unlink button
in the toolbar was visible.
After this commit:
The unlink button is only displayed when link is in range
Task-3184393
closesodoo/odoo#115161
X-original-commit: 5cab1c90b13074e642f3da3a773c55d37419f90b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
By default, clicking on links in a contentEditable context does not open
the link because it would make it hard to edit it otherwise.
This is a problem now that the views are always in edit mode because it
means the user cannot quickly and easily click on links to open them.
This commit aims to solve this conundrum by finding a middle-ground
between these two use cases, that is reintroducing the oh-so loved
Ctrl+Click behavior that was commonly used in previous versions.
This required two changes:
1. Explicitely implementing the behavior of opening the link in a new
tab in that case since it is not the native behavior in a
contentEditable context.
2. Giving special treatment to links inside a contentEditable context in
the `globalClick` listener introduced at [1] such that the event can
actually reach the custom handler in the editor.
task-id 3188438
[1]: https://github.com/odoo/odoo/commit/47acba560a8954f10bfa97b28daf90047005fdf1#diff-ce4923ebad38db28d4fc17267c93d147c4404feefd42eb140ef990bddbe1a9ffR93closesodoo/odoo#115428
X-original-commit: 8bd6b28f7915d7d84ff42722e5cb4b6f798cb81d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When the selection is outside the editable and the `autohideToolbar`
option is false, `_updateToolbar` will perform computations in order to
update a toolbar that is not visible.
In fact, trying to do so can lead to a traceback, as `getComputedStyle`
is called with a null argument when the selection is not contained in
the editable.
This commit avoids such useless computations and tracebacks by returning
from the function when the selection is not inside the editable element.
task-3171892
opw-3161789
X-original-commit: d4b13a147f2a69628c050a04655452fcb2e6d759
Part-of: odoo/odoo#115299
Before this commit:
When we add a single / on editor and add any extra character immediately after
the first / and press up/down arrow key it throws a traceback error.
After this commit
Now, if any new characters is added after the first / and press arrow key then
it does not throw any traceback error.
Task-3193362
closesodoo/odoo#115202
X-original-commit: 10fc8ecd67687f8bbdbb741664968b513063c824
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In order to make the model reactive, it must not be an EventBus. An EventBus cannot be reactive. So we will add a key bus to the model that will always trigger all events that were triggered on the model before.
Part of task 3179751
closesodoo/odoo#114975
Related: odoo/enterprise#38032
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Many of our users have a default OS/browser zoom of 150% when using a
1920x1080 (Full HD) screen. One cause is that this is the recommended
zoom when using Windows. Whatever the reason: many users have a
1920x1080 screen combined with a 150% zoom... and in that case, entering
edit mode would display the website as it would be on "mobile" devices.
This is because since [1], the website is actually reduced in size when
entering edit mode since an iframe is used, whose size is reduced by
the size of the right panel. Before [1], the right panel would be
*included* in the website which would appear reduced but using CSS rules
according to the full screen width (which also led to other issues but
this is in the past now).
The sidebar was actually 3px too wide. Reducing it from 291px to 288px
solves the issue (at least if the OS task bar is not anchored to the
left/right). Indeed 288px is 1920px / 150% - 992px, where 992px is the
current minimum width the screen must have for our websites to be in
"desktop" mode (below, columns break over multiple lines).
Notice that 1920px / 150% = 1280px which gives the minimum size of the
screen that will display the website in "desktop" mode in the editor if
no zoom is used, which seems like an acceptable value.
Note: reducing the sidebar width even further to support more devices or
more zoom / OS task bar configuration would be problematic as the
sidebar would become too small. It is currently kinda at both its
maximum and minimum authorized value.
We tried solutions to virtually "de-zoom" the website iframe to display
the website in "desktop" mode no matter what but this did not give great
results. On problematic devices, the user still has the possibility to
de-zoom its browser by himself.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#114873
X-original-commit: e3ab91188173a47bdc827d8f0e45efcf7b246a4a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, only the immediate parent of a selected node was
checked for HTML content support in order to determine the toolbar's
visibility. This led to incorrectly displaying the toolbar for fields
like the 'list-price' on an e-commerce product page, whose text content
is wrapped in an extra 'span' element inside the field's span element.
This commit fixes it by checking all of the node's ancestors up to the
editable root for the attributes that determine if a field supports HTML
content.
This commit also prevents a server error if the user somehow styles the
product's price (with ctrl+B for example. It's worth noting that such
style would not be kept in the saved version of the page).
lxml.HtmlElement's `text` property has `None` value if the span element
does not contain any text before its first child element
(see https://lxml.de/apidoc/lxml.html.html).
Therefore an element like `<span><strong>42.00</strong></span>` would result
in `None` when reading its `text` property.
The `text_content` method is more suitable for such task as it returns the
text content of an element and its children.
task-3188550
opw-3171669
closesodoo/odoo#114867
X-original-commit: 524ba7f89286aa03ed6a4da30177c9ce7018c59a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
unable to remove blockquote and heading element if first element.
After this commit:
removed element on backspace even if first element.
Task- 3004556
closesodoo/odoo#114727
X-original-commit: f0bbf1aab823524a74a52f694c0564dd23618a90
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit transforms the OdooEditor test utils file into an
odoo-module and makes it available for importing in QUnit tests.
closesodoo/odoo#114643
X-original-commit: df2125b7ce50031f0de8f5d78536d50e6c688dd1
Related: odoo/enterprise#37896
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, whenever a peer had no selection in the editor, no
selection would appear to the other collaborators. It was therefore
visually impossible to know excaltly to how many people someone is
connected.
Now, we set the default selection to be in the first node of the
document.
Additionnaly, some selection were not displayed because the call to
`getClientRects` did not return any rect. By creating a deep range
through the use of `getDeepestPosition`, we ensure to retrieve the
selection rect.
task-3217719
closesodoo/odoo#114583
X-original-commit: f47b306c5f37a43849975e4b7afb2819c80c809e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet <nby@odoo.com>
The comment that describe the
`missingSteps === -1 || !missingSteps.length` condition was wrong.
task-3217719
X-original-commit: 8396878160eceb974c02273f846c180ae4945a7c
Part-of: odoo/odoo#114583
Before this commit, any history step received before the history is
fully synchronised (`historySyncFinished`), would not be processed.
As a fail safe, this commit adds a buffer that will be processed as
soon as the history synchronization is finished
(`historySyncFinished`).
task-3217719
X-original-commit: acb58f921721b162954146f3c5364cb26823265f
Part-of: odoo/odoo#114583
In the method `isClientFirst`, if
`clientA.startTime === clientB.startTime` is true (which should happen
exceptionally), the code calling `localCompare` would fail as the
method name is `localeCompare`.
task-3217719
X-original-commit: 974e6a5d98b4ab6dc73d63e4acd4c4d3f11a6f0f
Part-of: odoo/odoo#114583
Before this commit, the mutation that add `data-last-history-step` was
added to the history. Without the collaboration, it would not be
problematic but when the collaboration is activated, that step is
broadcasted to the other peers but shouldn't as the mutation is
considered to be technical and should not be included into the
undo/redo mechanism.
task-3217719
X-original-commit: bf45295821495375784f2f817448e2c63f892510
Part-of: odoo/odoo#114583
Steps to reproduce the bug:
- Add multiple images on a product page
- Go to the shop and edit an image of this product by double clicking
on a small image on the carousel thumbnail
- Save
-> Nothing happens and the image is not updated
The goal of this commit is to ensure that a field of type image is not
`readonly` before adding the `contenteditable` attribute to its image.
task-3122670
closesodoo/odoo#114598
X-original-commit: 36fb7654b785888f100d5163e6cebd788c3c042a
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, the customize panel backdrop did not fully cover the
customize panel when the vertical scrollbar was scrolled to the bottom.
Steps to reproduce the bug:
- In website edit mode, add a table of content snippet to the page.
- Add a three columns snippet within the table of content.
- Click on an image in the three columns snippet.
- Scroll the customize panel to the bottom and open the filter selector
of the image.
- Bug: the backdrop does not fully cover the customization panel.
task-3090626
closesodoo/odoo#114517
X-original-commit: 672a8cb1632b2e61b87834b47e16e3b2f1c57ad9
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
In the model, we trigger events RELATIONAL_MODEL:NEED_LOCAL_CHANGES,
RELATIONAL_MODEL:WILL_SAVE_URGENTLY and RELATIONAL_MODEL:FIELD_IS_DIRTY
on env.bus. That means that if we have two instances of the model in //
(e.g. two views, or two Record components, or a mix...), their fields would listen and react to events
triggered for another model. Trigger those events on the model instead,
as it is an EventBus.
Because the events are directly triggered on the model, we can remove
"RELATIONAL_MODEL:".
Part of task: 3179751
closesodoo/odoo#113880
Related: odoo/enterprise#37727
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce the issue:
- Website (edit mode) > Drop a snippet with icons (e.g. "Steps").
- Open mediaDialog to change an icon.
- Select the same one (or click immediately on "ADD") > This will set an
empty icon (without any "fa" specific class).
The code on `MediaDialog` > `save()` adds CSS classes from the original
icon to the new created one then removes the old 'fa' classes from it.
(see `initialIconClasses`), as a consequence, the class will be deleted
(not replaced) when the selected icon is the same as the old one.
The goal of this commit is to fix this behaviour by simply closing the
dialog if the selected icon remains the same as the old one.
task-3210472
closesodoo/odoo#114345
X-original-commit: 0515e987b985622bc7b913dbbb37c0d0cd69eb4b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
This commit fixes an issue with the width of items in the we-list not
being correct when they are being dragged using jQuery's sortable
feature.
Steps to reproduce the bug:
- Drop a "Form" snippet on a page.
- Add a "Multiple Checkboxes" field in the form.
- Move an option from the list using the move button.
- Bug: while dragging the item, the width of the items is too small.
When an element is dragged, it is given an absolute position which takes
it out of the normal flow of the document, causing the input element
within the list item to no longer be able to correctly occupy 100% of
the available width.
task-3138662
closesodoo/odoo#114343
X-original-commit: e0a4ed0b21a9f87678e13609ff597cf1b3ae4189
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Soukéina Bojabza