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>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
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>
Commit [1] introduces an approach to preserve the cursor in `setTag` when new
node is inserted. It used `setStart` at `firstLeaf` of `startContainer` and used
offset of the `startContainer` similarly for `endContainer` which is incorrect
and would throw traceback regarding no child at that offset.
This commit fix it by getting the correct startContainer and endContainer when
new node is created.
[1]: d04e32c
task-3245819
X-original-commit: d9095d277e4dbfa318ff6ddd2692dbb3c71e4775
Part-of: odoo/odoo#151752
After upgrading (specifically following this [upgrade PR]), when editing
an element, the editor may be tricked into considering that the page
isn't correct even though it is. It causes the "discard" dialog to open.
Steps to reproduce after the [upgrade PR]:
- Remove the CTA in 16.0 with the bin icon (on the button itself, or
from the edit panel, next to the "Block" section).
- Upgrade to 17.0.
- The button is back. Edit the header and click to hide it.
=> a dialog opens "Are you sure you want to discard your changes?".
- Click either "yes" or "cancel".
=> either way, nothing is discarded nor cancelled.
[upgrade PR]: https://github.com/odoo/upgrade/pull/5500
Related to opw-3644220
closesodoo/odoo#151291
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
When pasting using CTRL+SHIFT+V, if the textFragment includes linebreak(\n),
each textFragment is divided, and each seperated fragment is inserted using
`insert` command, followed by `oEnter` command. However, when `oEnter` is
UNBREAKABLE, the inserted text is ROLLBACKED.
After this commit:
We now check whether the anchorNode's closestBlock is UNBREAKABLE. If so use
`oShiftEnter` command; otherwise, use `oEnter` command which avoids ROLLBACK.
task-3563785
closesodoo/odoo#151911
X-original-commit: f1e35ca82cf72ffb21c586d9bf1714bb388fe257
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
When a button is updated, its `btn` classes are stripped by the editor.
However, in so doing the regex replaces `btn_cta` by `_cta`. This commit
fixes it.
Related to opw-3644220
closesodoo/odoo#151803
X-original-commit: 61735c84445606b97fdf95f35b6e3dd1384b7ea5
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
This commit fixes an issue related to the colorpicker component, present
in both back-end and front-end. They use the same XML template but they
have two different selectors within our SCSS files.
Some months ago, commit[1] removed some `@extend` rules related
to button design within the `web_editor`, and replaced them
with a `.btn` BS class. This affected both colorpicker and causes layout
issues on the "front-end web editor", which was not the expected output.
The issue was fixed directly with commit[2], but by removing the `.btn`
class from the template, it removed the whole styling on the back-end
color picker, making it use the user agent button styling.
== After ==
Since the colorpicker already has some CSS variables to handle its design
depending on the context, we make use of the CSS variables to customize
the design of the component when it is inside the backend, and make it
look as it was before it lost its `.btn` class.
[1]: ee38c69503
[2]: 711fc86368
task-3693078
closesodoo/odoo#150157
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
- On table when we hit tab it displays toolbar as it sets selection between
startPosition and endPosition.
- On hitting tab it selects the text in the next cell completely, which
should not happen.
After this commit:
- Now toolbar is not displayed on hitting tab.
- selectionis made to collapse at the end the lastNode of the cell.
task-3475079
closesodoo/odoo#151653
X-original-commit: 9361133a24146528846cd2d69119c3e9045eafba
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
When we have some text in selection and we move away from the selection the
the toolbar disappear.
After this commit:
The toolbar is still visible when we move far from the selected text.
task-3054229
closesodoo/odoo#151354
X-original-commit: cbcad3b85f78dd42f7e059471498009be27a9045
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit, since [1], the "small" class behavior of Bootstrap
was changed to use a fixed value instead of being dependent on the
context (using `em` units).
This was a bad choice, given the fact that the "small" class could
be used in the past with its previous behavior in custo but also in
default Odoo layouts, where it could be use in more legit cases that the
one Odoo currently offers: instead of applying the class to a whole
paragraph, applying it to part of a title.
In that case, since [1], we can have a big title ... with a very small
text next to it, which may be strange. Of course, the proper way to
achieve a big title with a smaller text next to it would be to not use
"small" but another hx font-size, but the legit bootstrap behavior which
is to use their "small" class is thus broken.
This commit keeps the current possibilities (big title with very small
text next to it) but does it by using new custom Odoo classes instead of
changing the Bootstrap "small" one. That way, legit custo in previous
versions (or trying to use default Bootstrap in this version) will be
supported.
Note that this commit will impact existing 17.0 users though: if they
actually configured a big title with small inner text... those will
become big title with slightly smaller inner text (the default Bootstrap
behavior). Worse: a big title whose size was reduced using the font-size
selector and choosing "small" will now become a big title. We think this
is worth the risk (see PR description for more visual details).
However, notice that "legit" use case of the "small" font-size in 17.0
will be kept untouched: e.g. adding a small text on its own or next to
a paragraph: the "smaller" Bootstrap behavior is now computed based on
the ratio of the configured base and small font-sizes.
Note that some additional "bugs" were found investigating this:
- Form descriptions use the "small" class for no reason and should
probably not be possible to customize ("font style"-wise) anyway.
- The use of the "small" *tag* should probably be reviewed in all Odoo
layouts and/or its interaction with the editor be fixed.
[1]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0closesodoo/odoo#149590
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behaviour before commit:
In a saved pad, putting cursor inside a link without
making any other changes makes editor dirty. As result
discard button appears on the top.
Desired behaviour after commit:
Now putting cursor inside a link without editing
doesn't make editor dirty and discard button doesn't
appear on top.
task-3607361
closesodoo/odoo#151094
X-original-commit: d7f89ca078ec21fe0db49ae5b01f21caecd6abfa
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit the button to add documents from an URL is labeled
"Add Document" which is confusing given it is displayed besides an
"Upload Document" button.
This commit renames the "Add Document" button into "Add URL" to make its
purpose more obvious.
task-3493618
closesodoo/odoo#149406
X-original-commit: 860cbe0fcddc7b7a6f1ca383161ab439ba68fd72
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit:
Clicking on invalid link results in a blank and bizarre notification because
we are accessing wrong parameter in wysiwyg.js.
After this commit:
After correcting parameters clicking on an invalid link triggers a notification
displaying an invalid URL message.
task-3563345
closesodoo/odoo#139301
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Before this commit:
We used the .textsize method, which returned the height and width of the
icon. However, in the latest version of Pillow, this method was deprecated,
resulting in errors in the log.
After this commit:
We have transitioned to using the textbbox method, which returns the
coordinates of the top, left, bottom, and right of the text's bounding box.
From these coordinates, we calculate the height and width of the text.
task-3502373
closesodoo/odoo#140613
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Previous commit is fixing the code so that a view without `en_US` in
arch_db jsonb value won't make the code crash (`get_related_views`).
The commit before that actually improved the custom snippets so the
translations are forwarded to it when it's saved.
But that new code was introducing a way to have an arch without `en_US`
value, which led to the bug described above.
While the previous commit fixed the consequence of the issue, this
commit solves the root cause of the issue, introduced 2 commits before.
Arguably, this commit could be squashed in the one 2 commits ago, but
it makes things more clear to figure.
task-3375518
closesodoo/odoo#150945
X-original-commit: bf598d9098b4be36542a9a91c0dd1055cf36aed5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since commit [1], the lang was removed from the context by setting it to
None.
In Odoo 16 and since jsonb, it's not correct, the lang should simply be
popped from the context.
Indeed, having `lang=None` in the context will not return any value when
reading the arch if the arch has no `en_US` default value.
The previous commit will make it so the translations will be forwarded
to custom snippets when saving a snippet. With that commit, the issue
described above will be problematic and lead to a crash.
There is probably other legit ways to reproduce the issue which are not
yet found as we don't really use non english DB often.
Step to reproduce (following previous commit):
- Create a db with french only and install website.
- Then enable dutch and add it on the website as second lang
- Drop a title snippet & translate it in the dutch version
- Save and go back to the main lang (fr)
- Drag & drop again this newly saved snippet (custom snippet)
- Save and to to dutch version
- Enter translate mode
-> A traceback will be shown, because `get_related_views` will fail on
"empty etree document", because when in the stack doing
`etree.fromstring(view.arch)`, it will fail since arch = ''.
Step to reproduce (without the previous commit):
- Remove the `en_US` jsonb key from a view, eg
`update ir_ui_view set arch_db = (select arch_db - 'en_US' from ir_ui_view where id = 4) where id = 4;`
- Start odoo-bin in `shell` mode
- Do `self.env['ir.ui.view'].browse(4).arch` -> Will output the arch
- Do `self.env['ir.ui.view'].browse(4).with_context(lang=None).arch`
-> This will crash on record not found error.
[1]: https://github.com/odoo/odoo/commit/fdb9f8273be62d0a6d8051f7ca0a66cdf22ae5e7
task-3375518
X-original-commit: 9cb17bc9cb1490219d1488c99e419a84681ca121
Part-of: odoo/odoo#150945
This commit adds translation capability to custom snippets.
Before this commit, the custom snippet was not translate friendly:
1. Neither when saving a block as custom snippet
2. Neither when dropping a custom snippet into a page.
This was a known limitation for years. But now it's time to make it
work.
Step to reproduce (part 1):
- Enable french
- Drag & drop Title snippet in a page
- Translate the Title
- Save the block as custom snippet
-> Go in the backend view of this custom snippet, in debug, there is no
translation that followed the title.
Step to reproduce (part 2):
- Following previous steps, now add the translation manually on the
custom snippet view
- Back in a page in edit mode, drag & drop this custom snippet in the
page
- Switch to french
-> The title is not translated, the drag & drop copy code but no
translations
Those are the "page/view" to "page/view" translation transfer, but it
could also be any html field (like a product description) to view
(custom snippet) or view (custom snippet) to any html field.
task-3375518
opw-3242100
X-original-commit: 2bd6c1a8d653453692211eef0f5d46a0047eb6f2
Part-of: odoo/odoo#150945
Commit [1] introduced a responsive font size feature was. Following
this, in the context of mass mailing, an issue arises when users select
a font size from the toolbar dropdown. Specifically, the
`_computePxByRem` function converts the `px` value selected by the user
to the wrong `rem` value. This is because it relies on the font size of
the `html` element of the main window's document rather than that of the
iframe's document. Since the iframe's document has a font size of 14px
where the main document has a font size of 16px, the conversion was
faulty. Also, the value was cached on the window object, which is common
to both documents. So this commit moves that cache to the document so
two different values can be stored.
[1]: https://github.com/odoo-dev/odoo/commit/ddf25a16c46bfc3628512aba1390a1e345ec719a
task-3653543
closesodoo/odoo#147685
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Co-authored-by: Vishal Padhiyar <visp@odoo.com>
Co-authored-by: Dieleman Guillaume <gdi@odoo.com>
Before this commit:
On clicking the saame paragraph while emojipicker is open, it doesnot close,
resulting in multiple emojipicker being opened at the same time.
After this commit:
Now onclick away from emojipicker on the same paragraph emojipicker closes.
task-3555717
closesodoo/odoo#151038
X-original-commit: be671cce046a72402d1746917b4b5b8715ba1d41
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Sanjay Sharma (shsa) <shsa@odoo.com>
Current behaviour before commit:
In v16.0 and above clear format button was missing from
snippet toolbar.
Desired behaviour after commit:
Now clear format button is getting appeared in snippet
toolbar.
task-3638147
closesodoo/odoo#150620
X-original-commit: 701bbe40554ea9b6867171a755124fe5b635988b
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Mehdi Outagant (MOU)