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 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>
Since commit [1], which removed jQueryUI for the drag and drop, the
history when editing breaks easily.
Steps to reproduce:
- Drag and drop "Text-Image", save and go back to edit mode.
- Click on a column, move it to the right using the arrow and then to
the left, still with the arrow.
- Undo: no issue, the column went to the right.
- Undo: nothing changed => the column should have gone to the left.
- Undo: the column goes to the left => there should not be a third undo
since we only did two changes.
- Redo: no issue, the column goes to right.
- Redo: nothing changed => the column should have gone to the left.
- Nothing to redo anymore => the column never goes to the left again.
This happens because with the new drag and drop, an `o_draggable` class
is added on the elements when their editor are started, which adds
mutations in the history. Even though it does not explicitely add a
step, these mutations are well reverted when undoing/redoing (e.g. this
is what happens when nothing changes in the steps to reproduce).
This commit fixes this history issue by ignoring the mutations linked to
the `o_draggable` class.
Note that commit [2] already fixed other `o_draggable` class issues.
This commit therefore fixes them in a more general way.
[1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76
[2]: https://github.com/odoo/odoo/commit/32a6729dd094d53eb4a653ebb9d69d2b8cbe2390
task-3698536
closesodoo/odoo#150687
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
While applying font color, when multiple picture snippet is selected the
color was not properly applied to the selection. It was observed that the
font was unintentionally applied around the figure which was preventing the
proper application of selected color.
After this commit:
It has been made sure that whenever the figure element is enountered it
should not be appended inside font tag.
task-3640901
closesodoo/odoo#152660
X-original-commit: 09a9dede95fbcc230a468913d188988cb9ad01e2
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Emoji picker opened at an incorrect position.
After this commit:
- The Emoji picker now opens precisely at the cursor location
task-3569967
closesodoo/odoo#152645
X-original-commit: 7fd291355d555af229a33665f472db0811876299
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- When a banner was inserted at the first line and Ctrl+A and backspace
is performed, nothing happens.
After this commit:
- Now, all the content except banner will be selected and removed.
task-3432167
closesodoo/odoo#151735
X-original-commit: 530f102720458e5e1c224bf38073cd763309bf0a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
- Performing ctrl+a and backspace inside a banner would unintentionally remove
its first element, which could be a block tag
After this commit:
- Now performing ctrl+a and backspace inside the banner will no longer remove its
first element if it's a block tag.
task-3432167
X-original-commit: ddc8587f8a712fdddaa714bee2931cb149c03a38
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner did not set focus inside the banner; instead, focus
was placed after the banner.
After this commit:
- Now, upon creating a banner, focus is now correctly set inside the
banner.
task-3432167
X-original-commit: 7327d20626ec9164f47e00f7094a36b8794db5de
Part-of: odoo/odoo#151735
Before this commit:
- Inserting a banner after already existing content it's impossible to
go to the next line of the banner.
After this commit:
- It's now possible to navigate to the next line of the banner.
task-3432167
X-original-commit: 05a879f81ac59d47b718abbb5966fd4f8214e1de
Part-of: odoo/odoo#151735
Before this commit:
- In the project module, when a user opens the color picker, it opens as
a dropdown even if there is not enough space available, resulting in
some parts of the color picker being inaccessible.
- In the project, when a user opens the color picker a second time, it
always opens as a dropup, even if there is space available for it to
open as a dropdown.
After this commit:
- Now, when a user opens the color picker, it opens as a dropup when
there is not enough space available for the color picker to open as a
dropdown.
- The color picker will open as a dropdown when there is enough space
available.
task-3608803
closesodoo/odoo#152337
X-original-commit: b60aa4f4effcec38d0e18707ce268c0cc07a2515
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In form views, when the user closes the tab while having unsaved
changes, and if those changes are valid, we want to save them
automatically before leaving.
Before this commit, there could be situations where the changes
weren't actually saved. For instance, if they involved an heavy
payload for the write rpc, or if the network connection was poor,
it might happen that the xhr is killed. Or at least, browsers do
not offer any guarantee to wait for those xhr to reach the server.
Instead of a classical xhr, we thus use navigator.sendBeacon which
ensures that the data will be sent reliably [1]. There's a drawback
though, as its payload is limited. When the payload is too heavy,
sendBeacon simply returns false and does nothing. In this case,
we prevent the page from unloading and display a notification
suggesting the user to manually save his changes before leaving.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
Task 3537838
closesodoo/odoo#151834
X-original-commit: 0b53daa60ee5b370def21c8e0e30a6819597a0e4
Related: odoo/enterprise#55457
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit:
When in a checklist where first and second checklist are marked done after
selecting first and second checklist and deleting it the third checklist would
be marked as done.
After this commit:
Deleting previous done checklist would not affect the current checklist.
task-3203889
closesodoo/odoo#152387
X-original-commit: 2ddda7a66076ef99e1aa4ba9d463b0fd2f73626d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Commit that introduced the issue: fbc167bf84340b4bb6d0f8c59f2734814f56c6df
Issue:
======
Adding a table in a long chatter message with scroll raise a traceback
Steps to reproduce the issue:
=============================
- Switch to RTL lang
- Go to any form view and open the editor composer to create a log note
- Write a lot of lines so that the scrollbar appears
- Add a table
- Log the note
- Try to scroll -> traceback
Origin of the issue:
====================
The `_onScroll` method is called and it has `this._rowUiTarget` as the
row from the composer dialog which is not in the ui anymore so
`closestElement(row, 'table')` will return `null`.
Solution:
=========
We just do nothing when the element is not connected.
task-3707808
closesodoo/odoo#151800
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
======
Discard changes of form having html field doesn't remove the changes
applied in the html field.
Steps to reproduce the issue:
=============================
- Open any mail template
- Add modification on the template
- Click on discard changes
Origin of the issue:
====================
The function `this.props.update` is responsible of updating `_changes`
and updating the record which is called for usual input_field using
`useInputField` hook, but since this html field isn't of the same format
we didn't use it and it's only called in `commitChanges`
Solution:
=========
We update the value of in `_onWysiwygBlur` in case we are `inlineStyle`
so we don't commit but we save the changes for the discard to work
properly.
task-3453497
closesodoo/odoo#151993
X-original-commit: 1624da6f42561792be816836c6d88bc986c3538a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Before this commit:
if you have <p> within <li>,sometimes removing the <p> will result in the loss
of all classes.
After this commit:
Replace p inside li with span while preserving classes.
task-3546209
opw-3602047
closesodoo/odoo#152104
X-original-commit: e396a1097463d014a1aba553022451365b31f5f3
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
`destroyLinkTools` function sets the selection to entire link. However, in
case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be
updated correctly, also one could not change the a tag of a single element
within the link.
After this commit:
`destroyLinkTools` selects the `anchorNode` and the `focusnode` of the
selection instead of entire link.
task-3245819
closesodoo/odoo#151752
X-original-commit: e88ffecc4bdb0480fc1d47af14558f28f72a665d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Adnan Saiyed