Steps to reproduce the bug:
- Go to an event "Introduction" page
- Enter edit mode
- Click on the pre-existing "Introduction" title (note that it cannot
be removed because of the way the page is built, we might want to
improve that in master)
- Save it as a new custom snippet
- Go to your homepage
- Drop that new custom snippet that was saved
=> It cannot be removed, the rest of the content is kinda broken as
wells, etc etc.
This is because the original branding was saved with the snippet.
Indeed the event pages are made in such a way those pre-defined titles
are snippets but which are "editable root elements", i.e. elements
whose ancestors cannot be edited since themselves or their neighbors
contain dynamic elements.
opw-3633326
closesodoo/odoo#157191
X-original-commit: 356b8ce1070243ce69b5ba75d4988fcee6bc6190
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Go to website (Homepage) > Switch to "Edit" mode.
- double-click the "Contact Us" button in the header or keep clicking it
many times > Traceback: Cannot read properties of undefined (reading
'find')...
After converting the `linktools` widget to Owl in [1], the DOM element
of the component [2] was retrieved in an async process after it was
mounted, (some legacy code can trigger the instantiation of the
`linktools` when its parent component is not in the DOM and
`this.linkComponentWrapperRef.el` won't be returned, see: `Link` >
`onMounted`).
When double-clicking the link, This implementation will lead to a race
condition where the `onWillUpdateProps()` (mainly triggered by the click
to focus the URL input...) will try to access the DOM element from [2]
before being correctly set in `onMounted()`.
The goal of this commit is to fix this behaviour by simply waiting for
`onMounted` changes to be done before doing any adaptation on the
`linktools` DOM.
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
opw-3706902
closesodoo/odoo#155418
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit and most likely since commit [1], the "Open in new
window" option of link would not persist through editions.
Steps to reproduce:
- Create a link in the website builder
- Set its "Open in new window" property to true
- Save, and see that it works as expected
- Now enter edit mode again, the toggle will be off and not on as it
should be since the `target="_blank"` was correctly added.
For easy of debugging and understanding, you can just grep this line
```js
this.initialNewWindow = this.initialNewWindow || this.linkEl.target === '_blank';
```
[1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#
opw-3781477
closesodoo/odoo#156739
X-original-commit: 5ea2e015a8faed502c378d4e5042f8a0cf50cbf9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
Ctrl+clicking on a styled link is ineffective since the target is the styled
element, which lacks an href.
After this commit:
The target should be set to the nearest `<a>` tag rather than on the styled tag.
task-3773924
closesodoo/odoo#156544
X-original-commit: baf0a2f1e77b2f7aeb7f9fd657650829e5ba5e13
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Steps to reproduce:
- Go to a website page (in "edit" mode) > Add a "Text Image" block > Add
other blocks before and after the snippet so you can scroll the page
content.
- Scroll in a way that makes only a part of the image visible.
- Select the image and click on the "Crop" button > The crop widget is
applied to the image in its current position (partially visible), which
makes it impossible to crop it correctly.
The goal of this commit is to prevent the issue described above by
simply scrolling to a position that allows to correctly edit the image
before applying the crop widget and also allowing the widget element to
scroll when trying to crop an image that overflows the current viewport.
task-3420186
closesodoo/odoo#155094
X-original-commit: 8ef34c15336c6938f40c15dbcc64c025b24d5808
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
When inlining styles for e-mails, some styles could be lost if they were
defined in css but also had an inline style that started with the same
characters. For example, a node with a style attribute defining
`margin-top: 10px` and a css style defining `margin: 5px` would end up
with `margin-top: 10px` and losing the rest of the information.
opw-3650141
closesodoo/odoo#156177
X-original-commit: f2d2531125af90bd2a20e0e1a5cb5e44e7b4a02b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
=====
Clicking on hex color or rbga in colorpicker will reselect the inital
selected text and not the value if hex or rgba.
Steps to reproduce the issue:
=============================
- Create a note , type anything and apply custom color
- When clicking on the hex color code , the cursor is alwyas set back to
the text.
Origin of the issue:
====================
The behavior was introduced by
https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3
In the click listener, we always reset the comuted selection wich
reselects the original text. When clicking on empty space on the
dropdown menu, it happens too but it doesn't matter since the menu
closes anyway, but clicking on text input fields that you want to update
will be a problem since the menu doesn't close but the text get
reselected.
Solution:
=========
To overcome the problem of resetting when clicking on the dropdown, we
first check if the click is on the colorpicker or not, if Yes do nothing and
skip this.
task-3648629
closesodoo/odoo#155947
X-original-commit: 2c0a68df214f69b3d459507a6ce867620bf0513f
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current behaviour before commit:
When text is selected, applying table command through
powerbox makes toolbar appear along with tablepicker.
This happens because selection is not collapsed.
Desired behaviour after commit:
Now applying table command through powerbox opens
tablepicker only.
task-3482230
closesodoo/odoo#155504
X-original-commit: d090b889f648d1f454d7af0bab828dc57b2df167
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Current behaviour before commit:
When text is selected, applying table command
through powerbox throws error.
Desired behaviour after commit:
Now when text is selected, applying table
command through powerbox creates new table
without any traceback.
task-3482230
X-original-commit: a3384f8708c07b25d092b03b671198fd6877d1d1
Part-of: odoo/odoo#155504
Steps to reproduce the bug:
- In Website edit mode, drag & drop a text-image snippet onto the page.
- Click on the image of the snippet.
- In the image options, select "On Hover" for the "Animation" option.
- Click on the "Undo" button in the top bar of the editor panel.
- Bug: The "Animation" option has not been deactivated, the "Hover
Effect" is still present when hovering over the image.
task-3495241
closesodoo/odoo#134979
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit adds the possibility to preview the various effects
available in the "effect" option for 'on hover' animations when hovering
over the dropdown. The sub-options of these effects are also previewed.
This commit also prevents the user from seeing the different changes
that occur to an image with a shape while changing one of its options
(e.g., changing the shape, previewing hover effects).
task-3495241
Part-of: odoo/odoo#134979
This commit makes improvements as requested in the following pull
request [1] ("allowing the ability to flip/rotate image shapes" and
"adding an 'on hover' option for animations").
It mainly focuses on refining the code for better organization.
[1]: https://github.com/odoo/odoo/pull/119197
task-3495241
Part-of: odoo/odoo#134979
Commit [1] changed the behavior of `setTagName` to only carry the attributes of
paragraph related elements. Ideally, this should not carry the attributes of
`<li>` element only.
[1]: fcb3846
task-3764154
closesodoo/odoo#155448
X-original-commit: 0a47626dba4019fabaf4e399db3369b3db2e712e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Issue:
======
Invisible whitespaces at the start gets deleted by one by one with
delete forward.
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add any text
- Make sure you have an empty line before it
- Change the html of the added text and add some spaces at the start
(this is the easiest way to reproduce it)
- Go to the line before and keep deleting forward
- The invisible spaces will be deleted one by one.
Solution:
=========
When the selection is at the start of the node and it contains
whitespaces, `parentState` whill have undefined node when deleting
forward since we are at the first leaf. We need to keep deleting forward
with the text node instead of parentElement because calling delete
forward with the parent will do a 1 delete backward call from the
specified offset and it will not propagate forward anymore.
task-3629743
closesodoo/odoo#155435
X-original-commit: 6cfe30b1f194f7c53e8f91dde3251d7ba327ec56
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
Delete forward on emoji dosn't work
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add an emoji and put the cursor on the left of the emoji and delete
forward
- only half of the emoji gets deleted
Solution:
=========
We need to get the correct offset and correct charsize because not all
of the items of the sliced string had char size equal to `1`. So we
slice the string and get the offset corrosponding to the target offset
and of course we need to handle the directions differently
task-3629743
X-original-commit: 80a5b41b85c7f6732407bec80c8e6117ae795333
Part-of: odoo/odoo#155435
Commit [1] introduced a way to copy translations from a (view) record to another (snippets to their real life use).
The core function that was implemented is the low level `ir.ui.view:_copy_field_terms_translations`. However, that function
did not support inputting a hierarchy of views.
Indeed, since translations are stored on the view record, each view that is part of an inheritance tree has its own translations.
So, to copy the resulting translation of an inheritance tree to a record that contains all the tree in itself, as it is the case in web_studio's ReportEditor since commit [2], there was a need for that method to support the input of a record set of potentially many records.
Hence this commit proposes to modify that method that now takes a record set of potentially many records as input and
still copies to a single record.
opw-3746922
opw-3724701
opw-3719157
[1]: cfc90c0b2f30c9e5b6aae29958997298196ee952
[2]: odoo/enterprise@b7d0d3034dclosesodoo/odoo#155346
X-original-commit: 2d58b1c65be65297cb17818c0c21dbf2b84b664b
Related: odoo/enterprise#57490
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit [1] introduced some code that relied on a cache we currently have
for processed** images. In case of 404, that cache is not filled... and
relying on it thus crashes.
This commit circles around the issue by taking profit of [2] which now
forces `loadImage` to load a placeholder image in case of a 404. This
makes sure that in case of a 404 during the initial call to `loadImage`,
the rest of the stack works with the loaded placeholder image.
**Note: the current cache is not filled at the `loadImage` level, but
later when processing the fetched image. This should be changed in the
future (a task has been created).
See [3] and [4] which are example of unwanted 404 images due to other
issues, which allowed to discover this bug to fix here.
Steps to reproduce:
- Go on the `website.s_picture_default_image` ir.attachment form view
- Change the URL value to a relative path that does not exist
- Go on a website page and edit
- Drop the "Picture" snippet => Crash
=> After this fix, no crash but you can also edit the image if you were
able to click on it, it would use the placeholder image as source.
[1]: https://github.com/odoo/odoo/commit/567e5b58d544e4e56c3a68d148e862a516d77c4f
[2]: https://github.com/odoo/odoo/commit/0639c5028c69d8e29c8438b741cc4713d875b06d
[3]: https://github.com/odoo/odoo/pull/155015
[4]: https://github.com/odoo/design-themes/pull/767
Related to opw-3693055 and others (see [3] and [4]).
closesodoo/odoo#155275
X-original-commit: fbc6a697c1adf67ee8a90c49b0150d6ca170e081
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit:
When using the removeFormat button, the backgroundColor and
foregroundColor were not completely removed.
After this commit:
The removeFormat button will completely remove all the styles applied to it.
task-3344762
closesodoo/odoo#155146
X-original-commit: 9c4194ad3387c55d39ec7bbef1c6414893098c6e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
===================
- Open any app (sales for example)
- Toggle studio
- select reports tab
- Select any report
- Select some text and open any dropdown (font size or color)
- Click somewhere else on the document
- Select some text again
- The dropdown stayed open from the first select
Origin of the issue:
====================
Clicking somewhere on the document in studio doesn't trigger the events
`defined in bootstrap/js/dist/dropdown.js` because of the iframe.
Solution:
=========
Trigger click event on toggle button for the opened dropdown when hiding
the toolbar to close them
task-3674736
closesodoo/odoo#154969
X-original-commit: 878f3b27966a278a9332ef43e827eb2006911583
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
Articles were erroneously marked as changed,
leading to unnecessary autosaves. Part of this was
caused by the inclusion of history IDs in the
content comparison process, which differ even
without substantive content changes.
Solution:
Applied `stripHistoryIds` to the content obtained
from the WYSIWYG editor before performing the
dirty check. This ensures that comparisons focus
solely on actual content changes, eliminating
history IDs as a factor in the dirty state
determination.
opw-3707380
closesodoo/odoo#154068
Related: odoo/enterprise#56626
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Issue:
=====
When you undo a column command, you won't be able to write on that line
anymore.
Steps to reproduce the issue:
=============================
- Go knowledge
- Use column command to add columns
- Do ctrl+z
- Try to write anything
Origin of the issue:
====================
When we apply a columns operations , it will use the current block and
insert it under the first column so the `ouid` of the block will change
to the `oid` of the div (the column) so will will have 2 mutations : one
to remove the block from the root and one to add the block under the
column.
Reverting history will do the operations in reverse order, so it will
remove the block from under the column and the add it under the root but
the `block.ouid` is already set to `oid` of the column which is
different from the actual `ouid` which is `root` so adding any text to
the block will first add a textnode with `getOuid(node,true) =
block.ouid) != "root"` and `getOuid(node,false) = "root"` so it will
mark `this._toRollBack` as true and the operation is rolled back that's
why we can't add anything anymore.
Soltuion:
=========
Mark the `ouid` of the removed elements as undefined so when we insert
them again we can recalculate it correctly.
task-3693076
closesodoo/odoo#154815
X-original-commit: 16163f135d4fc215361dddf2f4520d08a3b0ac1c
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This commit resolves a bug related to zero-width spaces within the inner
content of a link. The bug led to a systematic test failure in 17.0
link_tools when comparing the input value with the expected value.
The bug originated from [1] that manipulates zero-width spaces to allow
users to select the edges of the link.
Steps to reproduce:
- Navigate to the Project app and open a random task (create one if none
exists).
- Select the "Description" tab.
- Enter "/link" and press "Enter" to activate the link tools dialog box.
- In the link label field, input "The Website".
- In the URL or email field, input "localhost:8069".
- Save the changes.
- A new div is generated with the class "note-editable".
- Click on the newly created link.
- Edit the link by clicking on the edit icon in the popover.
- Direct the focus to the link label field at the end of the string "The
Website".
- Press the "Backspace" key — observe that nothing happens.
This fix is actually a complement to [2].
The test added in [3] eliminates zero-width-spaces prior to asserting
the equality of values. This was appropriately addresses and handled in
this commit.
In version 16.2 [4], they refactored and improved the handling of
zero-width spaces (ZWS). As a result, ZWS in the link are now escaped
when the selection is made, eliminating the need to filter out these
empty characters. So, I added two assertions that provide more
comprehensive test coverage. The previous test only accounted for one
way to open the LinkDialog: selecting a part of the link and clicking on
the toolbox icon. Another method is to simply click on the link. In this
case, a popover appears, allowing link editing via the edit-link icon.
In the latter case, the test fails without the fix.
In version 16.4, the link component was migrated to OWL. So the bug
isn't there anymore. The new test is kept. Note that after this commit's
merge in 16.4, it was patched with [5]. This forward-ported version
includes the patch directly.
[1]: https://github.com/odoo/odoo/commit/99bc9b115dbdfc29260b4ccdb55ffa2ed16dffb3
[2]: https://github.com/odoo/odoo/commit/71feab51f41f0658f4ad61f99386c9c6978c6025
[3]: https://github.com/odoo/odoo/commit/a56586119845969e9d867a220f5330a6c7daa5c2
[4]: https://github.com/odoo/odoo/commit/89b0ce0c74458342fea5e1b093e9383f82e2440f
[5]: https://github.com/odoo/odoo/pull/154644
runbot-44779
closesodoo/odoo#154474
X-original-commit: 9db065e75d7b31febe4a42138308b47d0fa46508
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Rodolpho Lima <rcdl@odoo.com>
Reproduction:
1. In project -> task, create a new task
2. In the description, make a table of 1 row 2 columns, type two line
long string in the second cell
3. Create a row above, type anything short, save
4. Add the portal user as follower, e.g. search user joel
5. In an incognito tab log in with portal portal, check the task and the
table is out of the field
Fix: we should not fix the columns' width when create a new head row in
the table, for extra long table, it should be scrollable
task-3559104
closesodoo/odoo#154715
X-original-commit: 997b2f2817efe06ea37e5aca278507e0ef878635
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In cases where the cursor is at the end of the current block and the next block
begins with a zero-width space, the mechanism that skips these characters while
using arrow keys should not traverse all the way to the end of the zero-width
space in the next block. Because this mechanism operates before the browser
applies its own behavior for arrow keys, potentially causing the cursor to jump
to the start of the third block when second block only contains a zero-width
space, completely bypassing the second block. Conversely true for the arrow left
keys.
This commit ensures that the navigation does not extend beyond the current block
when searching for a `newFocusNode` when moving with arrow keys near zero-width
space.
task-3653307
closesodoo/odoo#154676
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
=====
Undo of resize operation on table do 2 undos in a row.
Steps to reproduce the issue:
=============================
- Go to website editor
- Add a text block
- write `/table` to insert a table
- Resize the table
- Press `ctr+z` to undo
- The table is removed
Origin of the issue:
====================
The resize operation wasn't saved a step and is considered as draft
then it will be discarded and then the undo applied on the last saved
step that's why it appears as 2 undo in a row.
Solution:
=========
Call `historyStep` when we stop resizing.
task-3743697
closesodoo/odoo#154402
X-original-commit: 836a68e29c8fa881854b19c7489086537127d4a3
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
1. Type a backtick
2. Type "A"
3. Type a backtick
4. Hit Left Arrow key
5. Hit Right Arrow key 2x
This led to a traceback ("Cannot read properties of null (reading
'isContentEditable') at OdooEditor._onKeyDown") because using `nextLeaf`
without specifying the editable bounds returned a node that was not
within these bounds, and a subsequent call to `closestElement` on this
node returned `null` as a result.
task-3749506
closesodoo/odoo#154484
X-original-commit: ec1fe7b05e0d91605f78dd1844c7d2222671eab3
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] added a rule whose intention was to unify the way our editor
labels look: capitalized. However, this is not working as intended for
translations as some languages have different rules for capitalization.
In the future, we will rely solely on the labels being written with the
intended capitalization in the first place (which is currently not the
case for dozens of English labels). As a fix, we keep the auto CSS rule
for English languages only. Hopefully, the amount of translations made
by translators being better than their auto-capitalized versions is
greater than non-capitalized English labels translated by mistake
without the auto-capitalization.
Note: this is the way python fields work too, they are not displayed
auto-capitalized in the webclient, although we want them to be.
[1]: https://github.com/odoo/odoo/commit/5db73c12d3ed14239dc81f60eec6c21d0f65af26closesodoo/odoo#153732
X-original-commit: 453b1e86840d81ffeff4d182b161b0ea50a38486
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Current behaviour before commit:
In v17.0 and above trying to open emoji-picker
throws traceback. This happens because not able
to find input element inside onPositioned method.
Desired behaviour after commit:
Now there is no traceback when opening emoji-picker.
task-3729610
closesodoo/odoo#153186
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
-On inserting icon in note, it replaces another icon.It occurs because
`isEmpty(block)` returns true, when block element was font-awesome, which
causes the code in `insert` method to remove current node, resulting in removal
of previous icon.
After this commit:
-Now icon is added without replacing the another icon.
task-3482264
closesodoo/odoo#152929
X-original-commit: 9a9487752131fddaf9ff163cb22226b256cef81d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Reproduction:
1. Install Sales, Email Marketing
2. Go to Email template by searching
3. Click the Sales: Send Quotation template and make a duplicate
4. Add empty lines in the template, till it almost reaches the end of
the page
5. Use slash command to add a Dynamic holder, and it’ll be positioned
below the page
Fix: compute the position by consider the height/width of the popover to
make sure it’ll be always in the page
opw-3373403
task-3442559
closesodoo/odoo#153969
X-original-commit: 583ef2441e6aa9a6d13f50991a0d1d3a54c31db1
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Steps to reproduce:
- Go to Website > Add menu items in a way that activates “auto-hide” (to
set the overflowing menu items in a “+” dropdown) if the viewport was
resized.
- Go to “edit” mode (adding the sidebar reduces the current window
width) > The “auto-hide” menu adaptation is disabled, and overflowing
menu items are still visible.
On [15.0 - 16.4]:
The original commit fixed the behavior described above by preventing the
unbreakable mechanism from detecting header changes and canceling the
auto-hide updates (see: [X-original-commit]).
In addition to the main fix, some other changes were also added to allow
correct editing of extra menu items [1]:
- The `_adapt()` debounce was replaced by a throttle that applies the
first menu adaptation immediately.
- We remember the state of the extra menu dropdown (open or not) if it
is there, which will be restored after the menu adaptation.
- When clicking inside an extra menu item, The extra menu is closed. We
prevent this default behaviour in "edit" mode.
Starting from 17.0:
The code from [2] fixed the same editor's rollback issue by using a
`withoutRollback()` to ensure that the `_adapt()` is called without
triggering any rollback.
This commit will only forward-port the adaptations from [1] since the
rollback issue was fixed using the new `withoutRollback()` tool.
[2]: https://github.com/odoo/odoo/commit/cbed990924887eb529056d89a042a92ba27b825b
Related to opw-3484742
closesodoo/odoo#153566
X-original-commit: 4713f95f18d7326b553464c0be6fdcd68b330292
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
The goal of this commit is to improve the comment in the `loadImageInfo`
method.
We decided to retarget [1] to master for a potential merge over there,
although it might just get cancelled entirely. We leave the small
regression in stable: not being possible to customize an image (filter,
optimization, etc) of an image-added-by-url when the URL is actually...
an image in a static folder of your own instance's website. This worked
in the past but this is kinda a weird use case which has alternatives.
Fixing it in stable would be choosing between two possibilities:
- Checking that the URL is actually a "local" URL -> this is exactly
what we cannot do anymore if we want another bug fix to remain: the
updated comment explains why.
- Also supporting customizing images added by URL for "external" URL
-> this is too risky in stable, that is why [1] will be considered in
master only, although it will not be strictly necessary over there
since the improvements made with [2].
[1]: https://github.com/odoo/odoo/pull/151858
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5aclosesodoo/odoo#153716
X-original-commit: 9d827cc22245a6706d5b6b94ac3c30a3d8cb238b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Specification:
This commit target the scenario when image is in selection and the toolbar
displays AI option for it, which made no sense as the generated response
will replace the image.
After this commit:
The toolbar has been updated to show AI option only for text based scenario
task-3733320
closesodoo/odoo#153190
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Previously, when changing the tag of a text node within a list, it transferred
the list's attributes to the newly created tag. Ideally, this should only carry
over the attributes of paragraph-related elements and not of lists.
task-3609500
closesodoo/odoo#153328
X-original-commit: 58829be8fee0d3330427a467c62280b6d6edb147
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Commit [1] changed the code in toggleList such that variable block could not be
a block. This commit updates the name of variable block to nodeToToggle.
[1]: d314fb6a6ceb6bade38a2a6b3e0e2e3fd016b7d9
task-3609500
X-original-commit: b863fff7d8e62dc28d8e5de20dffea6896dc188a
Part-of: odoo/odoo#153328
Previously, In RTL mode, the table columns menu were misaligned, causing a
visual discrepancy in the UI.Now, Implemented a fix to correctly position the
table menu columns in RTL mode, ensuring proper alignment and resolving
the visual misalignment issue.
task-3695715
closesodoo/odoo#153327
X-original-commit: 331f95265f6ba04369b654811cd594cc083a54d9
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Aashish Thakur (aath) <aath@odoo.com>
This commit fixes the problem of selection change on colorpicker fast
hover.
Before this commit, hovering too fast on the colors of the colorpicker
unselected text that would be on the edge of the selection and
uncolored. This is fixed by deep ranging the selection at the moment we
limit it to fonts. This improves the accuracy of the history as, in case
the font tag has been removed, it saves the text node as the current
selection. And since hovering updates rely on it, it prevents losing the
selection when unhovering fast (which is the cause of the bug).
We noticed two behavior when dealing with this bug. When hoving on a
color cell and exiting out of the colorpicker altogether, no bug
appears. But when switching between two cells, multiple selection issue
happen. After analysis of the performance graph, we believe that this is
due to the fact in the first case, onSelectionChange events are fired
and the handler is called, whereas in the other case it doesn't happen.
That handler particularly reacalulates the latest selection. And this
doesn't happen in our pathological case. After testing this theory, we
view that the problem is solved.
task-3295858
closesodoo/odoo#153212
X-original-commit: 9e3ee2563021b70ce64e7ec010b149820014bf8d
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: Hamza Maimoune <hmai@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Previously, sanitize would remove the `<p>` tag if it was a child of an `<li>`
element. This commit makes sure that the `<p>` tag which is a child of `<li>`
with class `nav-item` does not get removed.
task-3609500
closesodoo/odoo#153211
X-original-commit: bbc980637bd104b69fcbe0452fad9be0d92288d2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The mega menu templates on the website, like `s_mega_menu_multi_menus` and
`s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`.
This div has multiple block type anchor nodes. When a list is added to the mega
menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then
adds the `oe_edited_link` class, resulting in the centering of the A tag due to
the `inline-block` display of the `oe_edited_link` class. This commit fixes the
issue by adding display `inline-block` when not with nav-link.
task-3609500
X-original-commit: d2d9e53b9165ab51078a9035850182132fa4a75c
Part-of: odoo/odoo#153211
Commit [1] implemented an approach to preserve all the attributes when
converting to a list. This is beneficial for `p` elements since they will no
longer be in the DOM. However, elements other than `p` will always remain,
requiring only dir attribute and not other attributes like href, data-name,
describedby, etc.. to transfer to the list.
[1]: c422db596d909efc5ae0ba049f8f9f5b80a90883
task-3609500
X-original-commit: 3b1cd38bf69cb91789d2b66070effab465a2a6c6
Part-of: odoo/odoo#153211
When inserting a list to a mega menu, the closest `LI` is a nav-item within the
navbar. We aim to prevent the toggling of this list. This commit ensures that
lists with class nav-item in the navbar are not toggled.
task-3609500
X-original-commit: a64a37aeeb5c6f6eb838cf5b9c4221e8522721cf
Part-of: odoo/odoo#153211
Before this commit:
When creating a nested checklist within another checklist and subsequently
changing the direction of the parent list, the direction of the parent element
would reverse alongside the pseudo element. However, in the case of nested
checklists, only the content's direction would change, while the pseudo
element's direction remained unaffected.
Afte this commit:
When altering the direction of the parent checklist's content, both the content
itself and the associated pseudo element's direction is changed alongwith the
nested checklist.
task-3461806
closesodoo/odoo#152890
X-original-commit: f46e1f0c5b00f2e289feef5e35f3fea6fb477104
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
qsm-odoo