In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
https://github.com/odoo/odoo/pull/102662 Highlighted the fact that in some
cases, an rpc call can be done on a destroyed component.
There is such a case in Knowledge, which now causes a warning in some cases.
Impacted Versions
- 16.0 and higher
Steps to reproduce:
- create a new article in Knowledge
- type the space character: [ ] in the article body
- switch to another article
Current Behavior:
- warning
Expected Behavior:
- no warning
Contents of the fix:
Do not try to update the value of the html_field if the component is already
destroyed. This could happen when an urgent commitChanges was requested (i.e.
when leaving an article to open another).
Task-3101553
closesodoo/odoo#110862
X-original-commit: 1b683bd600bbf5c39c520afa041c4f6124c9dea8
Related: odoo/enterprise#36232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The JSON object can contain characters such as `<` (i.e. in domain expressions
for the act_window object of an embedded view). This means that the JS sanitizer
DOMPurify will remove the attribute when parsing a node that contains it.
Instead of encoding/decoding that attribute each time the DOMPurify sanitizer is
called, we could encode at all time, and decode it only when we use the value it
contains, since JSON.parse has to be used at those times anyway.
This way, we don't pollute OdooEditor.js code, which is already quite complex.
Task-3101553
X-original-commit: 7686ae282c97bc255ebb66367b39447b7bc1749b
Part-of: odoo/odoo#110862
Steps to reproduce the bug :
- In Website (edit mode), drag & drop a "text-image" snippet.
- Click on the button.
- Change the size of the button to "small".
- Click outside the button.
- Re-click on the button.
- The size selected in the options is "medium" and not "small".
Note that the same bug exist in backend with the link dialog.
This bug was introduced in ([1]), the code of the "else" (which was
removed by it) made it possible to take into account the cases where the
option had no "value" (e.g. "medium" size button). And so, without this
"else", the options without "value" were activated in any case.
This previous commit, which fixed an issue with the presence of the
"btn-success" class on a link, could in fact be based on what had
already been done for the links with the "btn-link" class (in [2]).
In this commit, this issue with the "btn-success" class is handled the
same way as for "btn-link".
[1]: https://github.com/odoo/odoo/commit/4c68b3e923610e1d573b4bd2b241b2fc5923c412
[2]: https://github.com/odoo/odoo/commit/c3e08e7a7baab1035c3d5c48d668cc02a232e1ac
task-3002177
closesodoo/odoo#110809
X-original-commit: 5e98953d67042dcffa978ab7d240d8677e847456
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
When inserting a backtick in text that has another backtick before
(case 1) or after (case 2) it, we convert the text contained between
said backticks into inline code. Case 2 was not tested, and didn't work
properly.
closesodoo/odoo#110784
X-original-commit: cc2a4a960d6d83362e35abc8a253e95105fd07f9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Wrong syntax made it so that having a text node after the text node in
which we're inserting a closing backtick character, converted all the
text after the backtick to the word "NaN". This fixes that syntax error
and ensures such cases are properly handled.
X-original-commit: 2833b42c09582dbcfed334d9fe6628a8eaf476b8
Part-of: odoo/odoo#110784
When the only change in a form was made in the html editor, if the user
did not blur the editor, the content was not saved.
The reason is because the `urgentSave` in `basic_relational_model.js`
check if the record is dirty before the HtmlField had the time to update
the value to make it dirty since the commitChange in the HtmlField could
run promises before calling `update`.
To solve it, in case of urgent save, we update the value before any
asynchronous modification and re-update it after those modifications.
In order to have this strategy only on urgentSave and not on the
blur of the editor, the params `{urgent: true}` has been removed in
`_onWysiwygBlur` as it seems to not be useful. Another params will need
to be added if we want to keep that behavior on blur.
task-3140763
closesodoo/odoo#110517
X-original-commit: 3ff0d4b032e44719f52d09c7bfb701c47a79a5c3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
When entering edit mode on the website and discarding directly, the editor
considers that there are changes in the DOM and displays a confirmation modal.
After this commit:
When entering edit mode on the website and clicking directly on discard, the
confirmation modal is not displayed.
Task-3056463
closesodoo/odoo#110515
X-original-commit: 650a97d1bd59254cc2115d54d58940b6112a8d70
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Dhaval Baraiya <dhba@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Before this commit, it was possible to edit void element if they were
branded. It does not make sense to edit a void element.
task-3096813
X-original-commit: fbf633b8110a74dbf25bdc5372a60e793017fbdc
Part-of: odoo/odoo#110513
In the web editor when the placeholder using the class `oe-hint` is
shown the insertion caret color is almost invisible in dark-mode.
This commits reset the caret to its default behavior by removing the
`caret-color` property from the class `oe-hint`. Therefore making the
caret dark in white mode and white in dark mode even when the
placeholder is shown.
It makes it consistent with all the other inputs w/ a placeholder.
task-3099628
closesodoo/odoo#110477
X-original-commit: 4caf4eb9b957853245a881b645863d6af8a166d1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce the bug :
- In website (edit mode), add a mega menu in the Header.
- Choose the "Cards" template for the mega menu.
- Click on a card of the mega menu.
- Change the url of link in the editor panel toolbar.
- The style of the card is broken.
The issue is that when the link of the card is changed, 2 classes are
removed from the link ('text-wrap' and 'text-center').
This is from code that removes all classes starting with "text-" and
"btn-" when updating the link in the DOM. This commit fixes that by
avoiding removing classes that should never be removed there.
Note that a previous commit ([1]) had already corrected this but only
for the "btn-block" class. This commit fixes the issue in a more generic
way.
[1]: https://github.com/odoo/odoo/commit/888687b487e95b4bf4fb080118b5eb945c8ab724
opw-2954714
task-3006845
closesodoo/odoo#110186
X-original-commit: 121af26cfee8a227ce5925d3a64a99c5bb63d35f
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since the migration to Bootstrap 5 (at [1]), the tooltip for the
background position overlay was no longer disposed when toggling the
overlay back on.
This meant that new tooltips kept being added and could lead to a very
confusing user interface.
This was fixed for legacy widgets at [2] but the tooltip for the overlay
is a specific case.
This commit makes disabling the overlay also dispose of the tooltip.
Steps to reproduce:
- Edit a website and drop a cover snippet
- Toggle the background position overlay (by clicking on the target
icon)
- Close the overlay (discard, save or click on the editor)
- Change the Parallax option from fixed to Top to Bottom (this is just
so that the previous tooltip is clearly visible after the next step)
- Toggle the background overlay again
=> The old tooltip is still present and a new one is visible
[1]: https://github.com/odoo/odoo/commit/1fcd098af5fa18e848c66bb83bdceb6ba0308512
[2]: https://github.com/odoo/odoo/commit/3c01b1cd77adec146b1a90f96bb1223a2108678b
task-3119958
closesodoo/odoo#110170
X-original-commit: 2ddffeef579baf47ff117b133a9d4fbf12108a2c
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before this commit:
On removing link, all classes were removed including non-button link classes.
After this commit:
Only remove link related classes and remaining classes are preserved by
creating span.
Task-2930767
closesodoo/odoo#103602closesodoo/odoo#110169
X-original-commit: 0057b7983b5da42328187f42729b6648002fb2be
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
* = digest, hw_posbox_homepage, im_livechat, mass_mailing, web_editor,
website, website_slides_forum
Since the migration of Bootstrap 5 [1], some CSS rules was automatically
converted (`border-left` and `border-right`) when it shouldn't be.
These conversions were made because the CSS rules was embedded in
HTML/XML code and the REGEX for the conversion had no protection for
these cases.
This commit restores the old correct value.
Ref:
[1] odoo/odoo@1fcd098af5closesodoo/odoo#110141
X-original-commit: 0cbf7c00ecc307fc725da345415647828e771bb4
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This behavior only made sense with [1] applying in all cases, but
since it was wrong to begin with (because of the "Plain Text"
template) and was reverted in the previous commit of this PR, then
the behavior does not make sense anymore, as the dialog would open
as soon as the user clicks on the link.
This reverts commit aaf70d3692.
Task-3128388
Task-2889670
[1] https://github.com/odoo/odoo/commit/61f7366d686b353ae9614285370e952253ec067c
X-original-commit: 33e5dcdb41ae2d4bb2a47ea3fd92f522b09b53e8
Part-of: odoo/odoo#110089
Sometimes, there is a crash when uploading a file when loading an article for
the first time.
Impacted versions:
16.0+
How to reproduce:
- open the odoo home page (module menu) and CTRL+f5 (force reload)
- go to the knowledge app
- in an article, put the cursor somewhere and type ENTER to create a new line
- type the /file command in that line
- try to upload a file
- traceback (if it does not happen, try again from the first step, it is not
always consistent)
Fix:
Delay the _onBlur handling of the wysiwig when using the modal. The Blur event
may occur and may trigger an update on the html_field, which may in turn induce
a rerendering of the component and its value.
We don't want this to occur when using the modal, because the selection was
registered by the modal to restore it when the modal closes (`preserveCursor`).
If the contents of the html_field are updated, then the stored position used to
restore the selection won't be in the DOM anymore, and the restoration will
fail. As such when we try to insert the Knowledge file block, the selection is
not in the editor and the method fails.
Task-2889670
Task-3128388
Task-3086694
X-original-commit: 2591d343793f59e2e70e7ffe8fa666661995348f
Part-of: odoo/odoo#110089
Co-authored-by: Antoine Guenet <age@odoo.com>
Both `allow_command_video` and `allow_command_image` options are supported by the
editor, but only `allow_command_video` was being sourced from the XML of the view.
This works:
<field name="body" widget="html" options="{'allow_command_video: false}"/>
But this didn't work without this commit:
<field name="body" widget="html" options="{'allow_command_image': false}"/>
It looks like that particular option was simply forgotten. This commit rectifies that.
Impacted version:
- 16.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#110088
X-original-commit: c81c5918e6ba2f263e173b27978194de1f71f1db
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Commit [1] correctly disabled some of the behaviors of the editor
that used to modify the selection outside of the editable. However,
it also had the inadvertent side-effect of disabling the toolbar
update mechanism when clicking outside of the editable.
Behavior before this commit:
When the toolbar is visible, clicking outside the editable zone
does not hide the toolbar.
Behavior after this commit:
Clicking outside of the editable zone hides the toolbar.
[1]: 07a1483967
task-3131435
closesodoo/odoo#110044
X-original-commit: 28a35a6b53493abd03e42cc30d164262c86b6de5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
Selecting some text and changing its size will never allow you to select 13 and
selecting default will make the text bigger than the surrounding text.
Example in project: the default size is 13px (the editor parses that info and
display 13px as the font-size), but if you want to set any text to that value
you can't. Users could set any text to that value by selecting
"default" font-size instead of 13
After this commit:
"default" sets to "font-size: medium", which is often not correct. It should
instead, do a "font-size: inherit" so that it's the default for the current
context. Hence, removed that medium font-size rule and let the cascade do it.
Task-3095887
closesodoo/odoo#109835
X-original-commit: 9878579f62b493958bb6a98e2cdc466bfc2954d8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue # 1:
Before this commit, copying an empty selection (collapsed range)
produced a Traceback. Making onClipboardCopy return when the selected
range is empty serve as double purpose: avoid that trace and not
overwrite clipboard content with an empty string (leaving the
previously copied content available for pasting).
Issue # 2:
Before this commit, copying a selection that spans over two or more lines
was producing a text/plain content without line breaks. This happened
because the text was obtained getting the innerText property of a detached
element (thus, not being rendered). In such case, the returned value is
the same as textContent, which just concatenates the text content of
text nodes (thus ignoring BR elements). Selection.toString(), for
instance, represents line breaks in the selection as '\n' in the
resulting string.
This commit also removes 2 harmless but useless lines:
if (!clipboardEvent.clipboardData.getData('text/plain'))
if (!clipboardEvent.clipboardData.getData('text/html'))
A copy event handler cannot read the clipboard data.
(see https://developer.mozilla.org/en-US/docs/Web/API/Element/copy_event)
The expressions in the if-conditions above always return true,
as getData will return an empty string.
Finally, this commit also adds basic unit tests for copying and cutting that
were missing.
task-3114102
closesodoo/odoo#109757
X-original-commit: 3a4be5116c23e12129d6e8c9d841a17a57a710a9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since its introduction with [1], there is an issue about the full link
URL which is never set.
The preview has 2 URL elements:
- The main one, for which the text will either be the URL itself for
external website or the page title for internal pages.
- The "full one", which will simply be the full URL for internal pages.
It's basically the text of the "main one" which is moved here when
there is a title to display.
But the "full one"'s url was never set, always being "#", meaning that
when you click on the title you land on the correct page but when you
click on the URL itself you don't go to that page.
[1]: https://github.com/odoo/odoo/commit/8fcf930a6b6b7ffb0965b0a689c7a3117962ce7e
task-3129267
closesodoo/odoo#109716
X-original-commit: 015c9bf111899b2a86c39b24cd1ec2d4e5278204
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, cut/copy operation in non-html fields will trigger the _onClipboardCut/_onClipboardCopy handler as long as there is html field in the same form view.
This will cause cut/copy fail when using chrome or edge.
Only bind cut/copy event to html field as these event handlers are not related to non-html fields.
closesodoo/odoo#109624
X-original-commit: 494f8300f848cf258ba8ba0132af104346083b3e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit when a color was applied on a text that spans several
nodes, it was wrapping each text node in a font node to which the color
was applied. Because of this, applied gradient colors were restarting on
each text part. (e.g. before a bold section, on the bold section, after
the bold section: each had a distinctly drawn gradient)
After this commit the bold and italic nodes are considered similar to
text nodes and are wrapped inside a common font node to which the color
is applied - using the mechanism that already existed for text nodes.
Actually applied on all visible inline & inline-block elements that do
not contain a font node (and are not buttons).
task-2666200
closesodoo/odoo#109537
X-original-commit: 8c965cad4d3fdbfefbbd5caa43d8c21e3a8e064f
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since [1] the gradient text image was reset within each font or span
block (e.g. for applying bold style).
The change was done because Chrome does not inherit the involved styles
when a transform is used, which is the case in animated texts.
After this commit the inherit style is only applied on animated texts.
This lets the gradient span across style changes.
Note that there is no solution yet for animated texts: they still have
a restarted gradient.
Steps to reproduce:
- Drop a Title block in a website page.
- Add a few words.
- Select the whole title's text.
- Make its text color a gradient. (Not the background color)
- Select the second word (avoid picking the word in the middle to
easily see the visual impact).
- Make that word bold.
=> The gradient restarts within the bold word instead of continuing
across the whole text - even though no text animation is used.
[1]: https://github.com/odoo/odoo/commit/187acb938f70a2130d25fa76079221339c742f1e
task-2666200
X-original-commit: 372eeebb47b93890d567185879981e817cdc1326
Part-of: odoo/odoo#109537
Since [1] when the m2m widget was introduced, when the network latency
is high enough, the `_search()` method can be called several times in
parallel. The former list of existing records is removed before doing
the RPC call, then populated with the results received after the RPC
call returns. With the proper timing and race conditions, this could
lead to having the list cleared several times, then populated several
times with the incoming results.
This commit makes sure the list is cleared after the RPC results are
obtained instead of before.
Steps to reproduce:
- Create and save a blog post with several tags.
- Edit blog post.
- Configure network latency to one second in browser's developer tools.
- Remove one tag.
- Remove another tag after 500ms. (Because the search happens after a
`setTimeout`.)
- Open tag suggestions.
=> List contained the concatenation of the two suggestion lists.
[1]: https://github.com/odoo/odoo/commit/be05ac7e2b8d866a72693b761f3bc8576d54e59e
task-2811746
closesodoo/odoo#109479
X-original-commit: 48564abe484f61c09ca98c3cddd5b4b0b55e6497
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the m2m widget was introduced, events that were neither
from the create input text nor the create button did remove the internal
value of the text that was entered in the create input text.
Because of this "Create" had no effect if the user hovered e.g. a
suggested blog tag on its way to pointing to the "Create" button.
This commit replaces this behaviour by restoring the text value of the
create input when the create button is used.
[1]: https://github.com/odoo/odoo/commit/be05ac7e2b8d866a72693b761f3bc8576d54e59e
task-2811746
X-original-commit: 59ecbb96db75a77cdcce11460cdbe8aa04438449
Part-of: odoo/odoo#109479
Commit [1] attempted to fix unexpected behavior when copy-pasting from a
<pre> to a <pre>, where the pasted text was smaller the intended, and
preceded and followed by new lines. The chosen approach had uninteded
side effects though as it removed any empty paragraph after the <pre>.
The source of the issue it tried to fix was that the pasted <pre> was
inserted as a new <pre>, splitting the existing element in two in the
process, instead of simply inserting the text content.
[1] 449cacf
task-3086603
closesodoo/odoo#109208
X-original-commit: dfcc3abe3396eaf764c3c3c8510b654649ed82f8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The insert command ends with setting the selection to the "right" of the
last inserted node. However, it did this without checking if that
position was valid for the selection, so we could end up with the
selection directly within the root of the editor. This corrects it if
such is the case.
X-original-commit: 722cf3bf11fcc9839677837018c1389d65b3f4fa
Part-of: odoo/odoo#109208
This commit allows to debounce the events of the RangeUserValueWidget so
that the user can use this widget with the left and right arrows without
having a lag effect (especially on the image quality option).
In addition, steps were added in the website_gray_color_palette tour to
let the time for the debounce to trigger the changes.
task-2601533
closesodoo/odoo#109165
X-original-commit: dddec7489f5cb4e48368684a8783015517c394ee
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
When a big number is entered in an option field with units, it gets
automatically converted to scientific notation (1e+10) by Chrome.
This makes the unit conversion code fail because it mistakenly
interprets the 'e' as the unit.
This commit adapts the used regular expressions in order to include
the complete number in the number part even if it is written in
scientific notation.
Steps to reproduce:
- Use Chrome.
- Drop a "Banner" block.
- Set the "Position" to "Repeat Pattern".
- Type a long number in the "Width" option.
=> Error popup.
task-2853161
closesodoo/odoo#109078
X-original-commit: a554e102a7f9ca2a0b7f64573adffa4b26a0b813
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When CSS properties are updated, a check is made to verify whether the
new value is different from the old one. This process sometimes involves
unit conversions.
Since [1] when a CSS property is updated, it is also set before the
check, in order to verify whether it should be set as `!important`.
When the CSS property is a size, such as the `background-size` CSS
property, it is made of two dimensions. However the verification does
not handle that situation: it handles `15px auto` as being a single
number with the unit `px auto`, which is wrong.
The full comparison is made because the strings do not fully match:
when a size property is set to a measure followed by `auto`, it is
returned without `auto` when reading the computed style.
E.g. after setting `15px auto`, it is read as `15px`.
This commit adapts the CSS properties comparison mechanism by splitting
the size properties into their parts and comparing each part separately.
This commit also introduces a few tests about the already existing
CSS properties comparisons.
Steps to reproduce:
- Drop a "Banner" block.
- Set "Position" as "Repeat Pattern".
- Type "5" in the "Width".
=> It raised an error.
[1]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4
task-2853161
X-original-commit: 07e471b9398e042c45182f1e8ca33e74dd8087a3
Part-of: odoo/odoo#109078
Since [1] the mechanism that was introduced in [2] is broken because a
snapshot of the property value is used instead of the dynamically
computed property value to determine whether the `!important` marker
should be set on the modified property.
This commit makes sure the value is obtained for each comparison
instead of relying on a snapshot across all comparisons.
Steps to reproduce:
- Drop a Banner block in a website page.
- Select the box.
- Set the background to a custom solid color.
=> The `background-color` style has the `!important` marker on it, while
it should not.
[1]: https://github.com/odoo/odoo/commit/815d1f775c13ad9d4463c2d571dffc4691e81a35
[2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4closesodoo/odoo#109117
X-original-commit: fff46efc04cbce3ff5bff1ded501197fbd5dca84
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
When a record gets deleted, there is no more collaborationResId.
If there is no collaborationResId, prevent the collaboration to
restart, otherwise it will try to subscribe to a channel.
When trying to connect to a channel without record, there
is a cache miss being logged.
Task-3045910
closesodoo/odoo#108933
X-original-commit: e15e8fa1b039cb200686cf49f49075ec7d5486d4
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Drop zones are available outside form when dragging form fields.
This leads to errors whenever the field is dropped outside a form.
This commit removes all drop zones outside the form when a field is
dragged.
Steps to reproduce:
- Edit Contact Us form.
- Drag'n'drop a field to the footer.
=> Error popup (should not be allowed in the first place)
task-2855670
closesodoo/odoo#108863
X-original-commit: 31aec4f89eea5f6095e420137c9603732674901c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Some buttons/actions were unsuitable for icons (were made for images).
fa-icon for toggle icon spin was misleading ("refresh").
task#2737569
closesodoo/odoo#104163
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
While creating a website: in the footer, when trying to edit the link mailto:
there is an "https://" added and preventing the link to work successfully.
After this commit:
- Whenever we try to edit mailto link and save it then in _parse(node) function
it will set link label as new URL.
- For that we add condition by which it will avoid further operations and Now
when we try to edit link mailto then there is no "https://" added and link
works successfully.
Task-2977682
closesodoo/odoo#108639
X-original-commit: 680a204b952e6281d7e1bcdfe0730688ee698a9d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, changing the font size of an element with one
ancestor having the same font size could trigger a traceback. For fixing
that issue some code has to be refactored to handle the setFontSize case
in formatSelection. As a side effect of this refactoring, nested
font-size is now properly handled (see added tests).
task-3086301
closesodoo/odoo#108633
X-original-commit: d003b82043468bcf609006c5910ac8fc9520e136
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Drop enough snippets to have a scrollbar.
- Drop a snippet with inner content having up/down arrows (e.g.
showcase,timeline).
- Move inner content with the arrows.
- => The element is correctly placed but the screen scrolled along
with it.
This commit fixes it by preventing the page from scrolling if the
element being moved is still visible after the move. The page therefore
scrolls only if the moved element is not visible after the move.
This commit also improves page scrolling when the element is hidden at
the bottom. Before, the page scrolled to bring the moved element to the
top of the page but now, it stops scrolling as soon as the element is
fully visible.
task-2952200
closesodoo/odoo#108831
X-original-commit: 675ae44803539a807c79fbc32c93b4e5d230816e
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Commit [1] made the "light" and "dark" colors of bootstrap be very
light and dark variations of the "main" color ("alpha" at the time, now
"o-color-1", which is used as bootstrap "primary" color). It was already
not a very good idea, although slightly better than nothing (at the time
navbar and footer colors could not be changed at all, so without this,
they would use a gray with a blueish hue not related to the main color).
Since then, 2.5 years later, [2] and [3] were made which gave some
control over bootstrap default grays via two widgets controlling the
new "gray-hue" and "gray-extra-saturation" params. At that time, the
light and dark overrides made at [1] should have been removed as "light"
and "dark" normally default to two bootstrap grays, which we would have
had control over since [2] and [3]. This was however, not a big problem
since "light" and "dark" were not used by the website templates (well it
was by some but not a lot) and the overrides to gray colors related to
the main color was not "stupid", just less nice as less control over it.
However, since the many improvements made with [4] more than 1 year
later, the "light" color started to be used to achieve more detailed
designed for the eCommerce. And it is planned to use it in further
design elements later on. The fact that those "light" elements are not
following the "grays" configuration made by the user is thus starting to
be a problem.
This commit fixes the issue in master (>= 16.1): "light" and "dark"
colors will now follow the configured grays. In the future, we might
even improve the control over those two particular grays or maybe
improve their default value according to the theme color palette.
It was judged that stable versions can stay as they are right now. As
explained, it is not critical and you can still force your own CSS rules
if you are really unhappy with the "hardcoded" grays (related to the
main color) at some places.
[1]: https://github.com/odoo/odoo/commit/22c4311e283af95eafe1ba85ee1234bb8102110e
[2]: https://github.com/odoo/odoo/commit/35d27a6c1d3dab621de7f059565d7619ae004412
[3]: https://github.com/odoo/odoo/commit/e08184103c42eaf7f6bfb70655cb90b51e79913a
[4]: https://github.com/odoo/odoo/pull/98558
Related to task-3097005
closesodoo/odoo#108825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When `link_tools` was introduced at [1], `_onURLInput` did only update
the configuration form and did not touch the edited DOM. Even though its
name would be misleading for that purpose, it was therefore used without
issue as an event handler responding to the configuration form input
events and as a private method called in the `start` method of the
widget lifecycle.
At a later stage, with [2], DOM modifications were introduced in
`_onURLInput` (using the misleading `_adaptPreview` method whose
refactoring at [3] made it update the configuration form only in the
case of the "Link Dialog" but update the actual link DOM for the "Link
tools" (website / mass mailing)).
This commit fixes that behavior by touching what is strictly necessary
in stable to keep the original intend of `_onURLInput` (updating the
configuration UI) but at the same time update the DOM following
configuration form input events (as intended by [2]).
In master, all of this should be reviewed.
Here are steps which revealed the problem. Although, meanwhile, [4] and
its parents were merged which fixed other parts of this issue but
keeping the potentially problematic DOM update on selection as described
above. Notice that [4] and its parents may be reviewed further in a
future update.
- Edit Home page
- Drop a "Banner" block
- Select the "Contact Us" button
- Select "Custom" style in the link tool
- Select a fill color
- Deselect the button by clicking on the Banner's text
- Select the button again
=> Button is redrawn without its color
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
[2]: https://github.com/odoo/odoo/commit/226c4c4032c26d3d8f622b29fb151fa8e78ba70a
[3]: https://github.com/odoo/odoo/commit/4a1d776243b059d423152bd026bb8bc758477224
[4]: https://github.com/odoo/odoo/commit/eb4edac560227b46efdcfe958e3b93e0b88def64
opw-3086198
task-3096806
X-original-commit: da25eadde299b81b78d84678978b7e1f703530cc
Part-of: odoo/odoo#108812
Co-authored-by: qsm-odoo <qsm@odoo.com>
Commit [1] which occurred in 13.X for the upcoming release of the 14.0
version introduced a "No column" option for snippets whose only column
was removed but that we wanted having the possibility to switch to a
multi-columns layout. At the time: Title, Text and Cover snippets.
That "None" option was meant to be hidden (as it was at the time) for
other snippets already in a multi-columns layout. Indeed the "No column"
and "1 column" options are very similar: "No column" is just an
optimization for experienced users.
The problem here was that [2] broke the behavior. Indeed [1] marked the
code in charge to hide that "No column" option as "To improve" as the
system was limited to do that at the time... [2] actually improved the
system to allow hiding sub-widgets, but did not adapt [1], making the
"No column" option always visible.
While working and not harmful, that "No column" option may be confusing
as at best you don't see the difference with the "One column" option and
at worst, removing the column removes nice style that you cannot restore
by choosing a multi-column layout again afterwards.
While not entirely stable (in the end we never released a major version
where [1] was working as intended), this commit restores the idea behind
[1] anyway to avoid further confusion and tickets. Choosing "One column"
instead of "None" most of the time leads to a better UX anyway.
[1]: https://github.com/odoo/odoo/commit/b293ccc7c3c5ca9a55092afd2e4a7b88c7b93fc8
[2]: https://github.com/odoo/odoo/commit/ecefd51b63ed8c933243b4a2d26381d05ac288d2
Related to task-3106301
closesodoo/odoo#108757
X-original-commit: 1ff8c9a6a907b4e60f86efc27c82727b288f0947
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When trying to replace an image with the media dialog, there is first a
click on the image, which activates the options of the image, and then
a double-click, opening the media dialog to choose the new image.
However, the media dialog does not wait for the image options to be
completely initialized before opening.
This behaviour is in general not problematic but if it happens quickly
enough, in a tour for example, it might cause a traceback. This happens
because the renderings (in `_renderCustomXML`) of the image before and
after replacing it happen too closely, making the first one lose the
reference to the image parent.
This commit fixes this issue by waiting for the options to be fully
initialized before opening the media dialog, that is, by adding an
empty action in the mutex and waiting for it to complete.
runbot-10692
closesodoo/odoo#108738
X-original-commit: 7667ba149aaf179f430615c4aba4b963d1d167c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the default image selection color (added by this
commit: [1]) used in "web_editor" in edit mode (Website, Email
Marketing). This prevents selected images from being covered with a blue
filter and allows to see the correct final rendering of an image when
it is edited (e.g. Apply a color filter to an image in a website page).
This commit also moves the rule (added by this commit: [2]) that
overridden the portal selection rule to "web_editor.frontend" because it
was applied everywhere even outside of the website/email marketing edit
mode. This rule no longer worked because of the "!important" in [1].
[1]: https://github.com/odoo/odoo/commit/3da301fcb24998333039a7b636cec0e5be8694c6
[2]: https://github.com/odoo/odoo/commit/aa8d2a8be2c8f713b4b39b2aa1ea2aaf1839396c
task-3073192
closesodoo/odoo#108732
X-original-commit: 19bebfc29f5c94ab11dab1fac2e6676eaab51592
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
The m2m widget label is aligned at the middle of the height of the whole
option's display.
This commit makes the m2m widget label aligned with the first element
(either the first active value, or the "Choose a record..." dropdown if
no value is selected).
task-2811746
closesodoo/odoo#108227
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: mass_mailing
When images are dropped from outside the browser into a website page
text paragraph, they are stored as an inline base64-encoded source.
This commit marks those images to be saved as attachments when it
happens in website. The save happens upon page save similarly to what is
done when images are transformed.
This commit also applies this behavior for pasted images.
task-2928495
closesodoo/odoo#98801
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To apply a shape on image, we use its base64 string as source on the
<image/> of the shape svg file. Then, the svg is used as source on the
targeted DOM element (<img/> on snippet).
When the targeted image is an animated GIF, the behaviour is different:
CHROME:
- The animation works correctly.
SAFARI & FF:
- The GIF animation is lost (only on non-animated shapes). The animation
works correctly on the svg file but once it is used as src of <img/> tag,
the animation is lost.
The goal of this commit is to fix this behaviour by forcing the
animation on SVG content.
task-2679905
closesodoo/odoo#108229
X-original-commit: 996acc3977de0346a45da328f42583b4366d1d47
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
