* = 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>
PURPOSE
Simply improve the design of the link popover
SPECIFICATION
- "ellipsis" the link preview instead of wrapping it
- only keep a 0.5rem gap between each of the right icons
Task-2916270
closesodoo/odoo#108497
X-original-commit: bb1f37226dcd842abf4ec63ecf037f5ce3a3441b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the span within monetary field could wrongly be
removed. Python code that parse the value (see `from_html` of
`ir.qweb.field.monetary`) expect to have that span available.
This commit make that span being unremovable.
opw-3090775
closesodoo/odoo#108496
X-original-commit: 7576c88fec4f993e525279d15c22077a11132281
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
On changing style of a list item to normal it wrapped the content in a <p> which
results in extra spacing to next list item.
After this commit:
Now the content is not wrapped in a <p> which removes the extra spacing as well.
Task-2990517
closesodoo/odoo#108434
X-original-commit: b4cf3bcc893e345c25d863c0afaab71bbbfb404c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This prevents the removal of styles on non-custom buttons, which the
user may have applied to them back when it was possible to apply styles
to non-custom buttons. The removal of styles now only happens when
picking a new link style in the "Style" dropdown, which is what the
removal was intended for.
task-3096806
closesodoo/odoo#108384
X-original-commit: eb4edac560227b46efdcfe958e3b93e0b88def64
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If a custom button had a gradient background, clicking in it removed
that gradient. That is because that opened the link tools, which updated
the DOM before having fetched the custom colors.
task-3096806
X-original-commit: c3d22aa0e03588cc8781f015ada9002c6a0a4384
Part-of: odoo/odoo#108384
Before this commit:
In Email Marketing's Mail Body, The Powerbox is opened below the cursor,
even when there's not enough space between the cursor line and
the window's bottom. As a result, a part of the Powerbox cannot be seen.
After this commit:
Now, the Powerbox opens itself above the cursor line if it's too close to the
window's bottom.
Task-3037435
closesodoo/odoo#108352
X-original-commit: ba888c39716f0226adce993cb08852e21b0376eb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: website
The fields of a form that are mandatory because of the model they need
to be used in cannot be removed. When such a field is selected, the
remove button displays a tooltip giving this information.
Disabling the overlay button is done by removing the specific class -
which makes the event selector not linked to the button, but also
impacts the applied CSS rules.
This commit adds an `o_disabled` CSS class upon disabling the button.
The tooltip is put on a `span` that wraps the disabled button because
tooltips cannot be shown on disabled elements.
Steps to reproduce:
- Drop a "Form" block.
- Select the "Phone Number" field.
- The overlay's delete icon has a reddish background.
- Select the "Your Email" field.
=> The overlay's delete icon had a dark gray background instead of a
reddish one.
task-2950433
closesodoo/odoo#107864
X-original-commit: ed3acbae6a6b2fe91c948ceeb16a5bdb3fa8f060
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
1. Drag and drop the "image - text" snippet.
2. Click on the image => you have a double overlay which appears (one on
the column with handles and one on the image without handles), this is
good, that's what we want: the ability to control the column width but
as the image has options, it should be framed with an overlay too to
indicate what you are editing in the right panel.
3. Hover the column options => good, only the overlay of the column
remains in preview mode (without handles / buttons).
4. Hover the image options => good, only the overlay of the image
remains in preview mode (without handles / buttons).
5. Stop hovering the panel => the double overlay should be restored but
that's not the case: only the column one remains, even though the image
options are still displayed in the panel.
When we introduced the possibility to display 2 overlays at the same
time in this commit [1], we added a loop to search for the overlays to
display since there can now be several.
But in a later commit [2], we added a `break` in this loop, which no
longer allows displaying more than one overlay when necessary.
[1]: https://github.com/odoo/odoo/commit/9bbe5be3fb0d995374a369851df3641979d8e553
[2]: https://github.com/odoo/odoo/commit/806a8db35b5e0e6a461422f5bba7c97180c3ef29
task-2919164
closesodoo/odoo#108334
X-original-commit: ee86f5a94965ce691393f5300bdfb6dc09780b1d
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Commit [1] added a div around the `.note-editable` node of the html
editor. This broke some css rules. For instance, the html field in
form view's notebooks should have a transparent bottom border when
focused, this was no longer the case (e.g. crm lead form view).
Moreover, we sometimes want to control the height of the editor
(e.g. in Notes or in the mail full composer). That was broken as
well due to the added div.
This commit fixes those issues.
We also ensure to set the border-radius to 0 when the editor only
has a bottom border.
In notes, we do not want to have borders, but the rule didn't
apply due to selector precedence, we fix that as well.
Finally, we fix a typo in a selector in the web_editor addon.
[1] https://github.com/odoo/odoo/commit/60ac6be0d3545#closesodoo/odoo#107740
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, following this flow:
- Add a form
- Add a selection field
- Add an option starting with a number
- Save
=> The created form's option value is only the number
From the website_form options, the options HTMLElement of a form field
are generated using the field's records ids for their html element value
attribute (see FormEditor._renderField).
When [1] refactored the website_form options to use a generic
ListUserValueWidget, the list records id computation changed to use
parseInt instead of strings.
This commit changes the detection of parsable int to match only strings
that are made only of digits, and less than 16 of them so that their
value is not lost.
[1]: https://github.com/odoo/odoo/commit/9304f8fa7bb94f21dd4caa83f9679ffd1642691b
opw-2980760
closesodoo/odoo#108248
X-original-commit: 166f4aa4d23a01901585b60d69fac47fe70b7ebe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
As the previous commit explained, there is sometimes a gap between two
shapes due to some browser rounding errors, especially when using
browser zoom. However, there are also some things we can do in our
shapes themselves to decrease this problem.
This commit fixes two pairs of shapes which were easily fixed by
reviewing the rounding of one path and making the viewBox a square
(making a viewBox a square is known to solve issues). However:
- The first pair is not entirely fixed, the error is just reduced.
- The second pair is fixed... but the shapes actually do not join very
well (somehow the linear gradients do not seem to join properly)...
but still better than a white line between the two.
Reminder: several commits had attempted to fix this before ([1], [2],
[3], [4]) (and this commit's parent). But that wasn't enough to stop it
happening. Some shapes still need to be fixed although that will likely
be done in future versions.
[1]: https://github.com/odoo/odoo/commit/c0f62593a4da37e8404dddc0a5762879a5ebbf7f
[2]: https://github.com/odoo/odoo/commit/ac82407b259eab929486bf0a333a48bc507efa60
[3]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
[4]: https://github.com/odoo/odoo/commit/e386f318f5cff50901dba3db8a2587911ba02a6e
task-2824607
opw-3069213
opw-3057533
closesodoo/odoo#108228
X-original-commit: 52e5afaa10ca7f2b3183bf6359b42929a9b3704a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit mitigates an issue with shape elements sometimes having tiny
spacing on their top or bottom edge.
This issue is mainly on Chrome when the user has changed the page zoom.
When the page is zoomed the elements can have a width value with a
decimal part. Because of it, the size of the SVG background images are
not correctly rounded compared to their container and therefore leaves a
visible space.
Steps to reproduce the bug:
- On Chrome, add several shapes on a website page.
- Change the zoom of the page and change the window width.
- At some points, the gap will appear.
The least bad solution we found to fix this is to ensure that the width
of the shape elements is always as close to an integer as possible.
Reminder: several commits had attempted to fix this before ([1], [2],
[3], [4]). But that wasn't enough to stop it happening. Some shapes
still need to be fixed although that will likely be done in future
versions.
[1]: https://github.com/odoo/odoo/commit/c0f62593a4da37e8404dddc0a5762879a5ebbf7f
[2]: https://github.com/odoo/odoo/commit/ac82407b259eab929486bf0a333a48bc507efa60
[3]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
[4]: https://github.com/odoo/odoo/commit/e386f318f5cff50901dba3db8a2587911ba02a6e
task-2824607
opw-3069213
opw-3057533
X-original-commit: 623db525e18931a4dd5794da78be840afc34991a
Part-of: odoo/odoo#108228
Before this commit, it was possible to resize a column so that it
overflows the right border of the row.
Steps to reproduce the bug:
1. In website edit mode, drop a `media list` snippet in the page.
2. Select a column.
3. Resize the column by dragging its left side to the right to make it
smaller.
4. Drag its right side to make it bigger and go until the edge of the
editor => The column overflows and ends outside of the content zone.
This commit prevents the column from overflowing when it has an offset.
task-2837361
closesodoo/odoo#108218
X-original-commit: 1759079cbb084acac0616abfab84b83b1e62ae61
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Since the migration to Owl, the root of wysiwyg has been wrongly set.
First, in renderElement, wysiwyg creates an editable element, which it
sets as its $root and $el elements. Then in startEdition, wysiwyg_iframe
creates a new editable element that it puts in an iframe appended to the
$el element. It then failed to change the $root element to that new
editable instead. Since we have a new editable element, the old one
should also not be contenteditable=true.
Because the $root element was wrong (and outside the iframe), all
listeners on it failed, with the effect that at least the link tools and
link popover were broken.
closesodoo/odoo#108186
X-original-commit: 86a8b31879b153bb53249fabfab47d254159effa
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
command prompt is not displayed when html field has placeholder.
After this commit:
placeholder is replaced with command prompt when focused.
Task-2881079
closesodoo/odoo#108175
X-original-commit: 16cb4af921fec5483e366ea0a1b402631a7e28f3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Romeo Fragomeli