Before this commit, the web_editor option 'Style' which has a `Quote` entry
would not do anything visually.
Indeed, what it does is inserting a `<blockquote/>` element in the DOM but is
has no style anymore in BS4.
This commit restore the style we had with BS3.
task-2144335
Some code was added to prevent notifying a 'reset' if there was no
'preview' before. Unfortunately, checking "if there was a 'preview'
before" cannot be done properly so some 'reset' were stopped while they
should not have. This commit simply removes the code which is in fact
not needed.
closesodoo/odoo#44499
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Some elements like the file input are not compatible with selection.
Since there is no reliable way of figuring out if the element is
compatible or not we will simply try catch it.
closesodoo/odoo#44470
X-original-commit: 1f0a0b380c2738795b0b5a7976692d9e9cd88583
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Studio
- Add an required html field
- Create new record
- Leave it empty
It is saved
Cause
The isSet function of FieldHtml widget, have a "/" in the <br> tag
and summernote empty = <p><br></p>. If you add a space, the value
becomes <p> <p>.
Solution
Remove the "/" and the spaces, check if value != <p></p> &&
<p><br></p>
OPW-2183687
closesodoo/odoo#44427
X-original-commit: c984b1b1210cea1e63f3bc66cec2120554c76c2a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In case of font-awesome icon when the browser is being zoomed, we can
get a decimal font-size.
There is a system that transform font-awesome in image links so they are
readable in any email client (supporting image) but it did not take into
account decimal font-size.
With this changeset, we only send a integer font size: we do not try to
get the original value because styling is relative on elements, a 90%
zoom ratio could lead to a 98% font-awesome icon ratio.
Also improve edition of font-awesome icon edition after first save by
reverting the transformation to image on edit. Thanks to that, the
original size will also be reinstated and will not depend on zoom on
previous save.
opw-2156069
closes#43949closesodoo/odoo#44033
X-original-commit: fe72bf01b67ea20ddb74a5b05464c63cc77090ef
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Adapt drop zone direction when a snippet is dropped in an oe_structure
within a snippet.
Before that, the first and the last drop zone preview (when dropping a
snippet in an oe_structure inside an other snippet) was vertical if the
oe_structure width was smaller than his parent.
Part of https://github.com/odoo/odoo/pull/40690
task-2118980
*: website
This commit is a safety nest to ensure `o_snippet_invisible` will be
found, even if somehow they appear as one of the editable area elements.
It might be the case with some refactoring, as it was the case between
404fa8164 and 83d99941c, in which case, the step to reproduce were:
- Add s_popup snippet into the page
- In the options, select 'Show On All pages' -> It moves to footer
- Now save and enter Edit mode again
- The invisible element (popup in this case) is in the DOM, the widget
is working fine but it is not retrieved as an invisible element,
thus not possible to edit it
+ lint/dead code
Part of https://github.com/odoo/odoo/pull/41294
task-2087003
Avoid display errors with special characters when copying the href attribute
of links in the web editor.
opw-2078313
closesodoo/odoo#44176
X-original-commit: 19ebcdd20426406250174eb473b081a9e488e542
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* website, website_sale
The design will be deeply reviewed in a future update. This commit is
just about unifying it and making sure no element is cut/overflowing.
-> All items are now inline automatically
-> If there is no enough space, it becomes full-width over two lines
automatically (this can be forced with the o_we_fw class)
-> Force to stay on one line with the o_we_force_inline class
closesodoo/odoo#44142
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website_event
Commit https://github.com/odoo/odoo/commit/a153ed42a09f8b7f5e0865112eb7d5affc22a353
solved a big problem which was that when an undo/redo is performed, the
whole DOM was reconstructed breaking all the JS relying on the old one.
For example, the latest blog posts which are dynamically loaded in JS
were not removed before saving since the JS relied on the old DOM... and
this broke the page because that dynamic content contained non-valid
XML markup. The solution was to destroy all JS widgets before applying
an undo/redo and rebuilding them all afterwards. Ideally this operation
should be done on the undo recording action but this would have a huge
flickering impact since many DOM would be destroyed each time the user
types text (flickering which is also bad on undo/redo but it is more
acceptable).
The problem now is the following: if a widget, like many, is declared
like this:
```
start: function () {
this.$el.append(/* Some dynamic content on page loading */);
},
destroy: function () {
this.$el.find(/* Dynamic content to remove */).remove();
},
```
Then it works in all standard cases: dynamic content is loaded on page
load and is removed when saving the editor. But this happens with the
undo/redo system:
1. The users types text, we record an undo, which is the whole page
current DOM, containing all the dynamic contents.
2. The users hits CTRL-Z:
a. We destroy all JS widgets, calling destroy, the dynamic content
is removed from the page.
b. We replace the whole DOM with the one that was saved. That one
contains the dynamic content DOM.
c. The JS widgets are recreated, calling start... creating the
dynamic content again.
Result: the dynamic content appears duplicated. On save, depending on
how the destroy was implemented only the last generated content may be
removed or both... but in any case it appears duplicated during edition.
Hopefully, our current stable version do not contain that many dynamic
content so a perfect amelioration of all of this can be found in master.
As a fix, this commit introduces an extra step between (a) and (b):
we remove the dynamic content of the DOM-to-re-apply before applying it.
For this to work, widgets have to mark their dynamic content with the
class 'o_temp_auto_element' when creating it. They also must add the
content they replace on the 'data-temp-auto-element-original-content'
attribute.
closesodoo/odoo#44025
X-original-commit: f0d2559afd3094f6fbd7e6788f7c10fa421c9080
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The move snippet arrows where not hiding properly when the target was
not movable.
closesodoo/odoo#43864
X-original-commit: ab32882ff0ecaf9995e52b062b880cd8ea0b6efa
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Left panel widgets can define the widgets they depend on to be visible.
Up to now, if such a dependency was defined but that the related widget
was not found, the dependency was considered as not met. Now, it acts
as if that particular dependency was not defined at all.
This is useful for controlling the visibility of a generic option in the
case of a specific snippet without having to duplicate and restrict that
generic option.
E.g. There is a generic "color" option on all snippets. For my snippet
"hello" I only want that generic "color" option to be visible if my
"world" option is enabled. I then add `data-dependencies="world"` on the
generic "color" option. In the case, any other snippet than "hello" is
used, since the "world" option does not exist there, the "color" option
acts as if it had no dependency.
closesodoo/odoo#43511
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website, mass_mailing, website_event, website_form,
website_mass_mailing, website_sale
Now the user can save snippets to use them on other pages.
task-2120409
closesodoo/odoo#40408
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Call the `onFocus` method before the `updateUI` one so that we can
make changes before we update/render the UI (so that `updateUI` may
be influenced by something done in `onFocus`).
Needed for upcoming task: https://github.com/odoo/odoo/pull/42189closesodoo/odoo#43334
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since a refactoring (it was working at some point), `title` attribute on `we`
elements would be lost when rendering actual DOM elements.
We had 2 occurences of `title` on `we` elements:
1. s_countdown > What Should Happ.. > Show Message > fa-eye icon has a title
(in next version 13.2)
2. data-js `BackgroundPosition` (section) > fa-arrows has a title
Also, incoming Cookies Bar task/PR will add a title on 'Hide For' option.
closesodoo/odoo#43199
X-original-commit: 230a84edcea139bc7df44a4d1a27761e74038257
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With this commit, we can now say "on preview/selection of a widget,
also preview/selection these other widgets". For this, add a
`data-trigger` with comma-separated widget names.
A `data-trigger-value` can also be used to indicate the values these
other widgets should have during preview/selection... but this currently
only works for colorpicker widgets thanks to a big big hack that should
be improved later.
Part of https://github.com/odoo/odoo/pull/42986closesodoo/odoo#42986
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website
This commit is simply about factorizing the code some more and making
sure the user value widgets always trigger a meaningful 'previewMode'
value.
Part of https://github.com/odoo/odoo/pull/42986
* website
This commit is simply about making the related method public instead of
private (allow to better see the diff in upcoming improvement commits).
Part of https://github.com/odoo/odoo/pull/42986
Instead of triggering three different events 'user_value_change',
'user_value_preview' and 'user_value_reset', user value widgets in the
left panel now trigger only one event: 'user_value_update' with a
'previewMode' parameter being false, true or 'reset'.
This allows to simplify the code.
Part of https://github.com/odoo/odoo/pull/42986
Issue
- Have firefox
- Go to any chatter
- Open full editor
- Write some "test" words with line breaks
- Select one of your "test" words
- Drag & drop it somewhere else in the editor
Welcome on test.com! (redirected)
Cause
Summernote doesn't preventDefault on drop event, so firefox
think we want to go to another URL.
Solution
Add the preventDefault manually.
This reveals another issue which is solved by importing
this PR's code https://github.com/summernote/summernote/pull/3327
(with adaptation for our dinosaurus version)
OPW-2158112
closesodoo/odoo#42759
X-original-commit: 197145ac19fd65dcfbcbae81c8b5dd54025185a4
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
*: web_editor, website_forum, website_mass_mailing, website_slides
This class no longer does anything.
Part of odoo/odoo#41561
task-2155808
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The previous commit introduced a new imagepicker uservaluewidget, which
allows the user to select a picture or video in a generic way, this
commit adapts the background and CoverProperties snippet options to make
use of this uservaluewidget instead of duplicating most of the logic.
Part of odoo/odoo#41561
task-2155808
This commit introduces a new web_editor UserValueWidget on the
we-imagepicker tag, this widget allows the user to pick an image or a
video using the MediaDialog, and calls the containing snippet option's
method (specified via data-attribute) with the url of the chosen picture
or video as widgetValue. Videos are disabled by default and can be
accessed through the use of the data-allow-videos="selector" data
attribute, any $target that matches the selector will have videos
available in the media dialog.
Part of odoo/odoo#41561
task-2155808
Hardcode some existing colors (but make them hidden in the colorpicker)
so they can be removed from snippets when selecting another color.
Normally, the chosable colors do not contain them, which prevents them
to be removed. For example, normally, the 'alpha' and 'beta' color
(which are the same as primary and secondary) are displayed instead of
their duplicates... but not for all themes.
This commit was mainly about the addition of 'success', 'info',
'warning' and 'danger' colors to the list (as we do not give the
possibility to select them through the editor but they might still be
used by snippets or in old databases). This also solves a bug for
upcoming features in master.
This commit also makes the excluded sections of the colorpicker hidden
instead of removed for the same reason.
In preparation of task-2152191 and others.
closesodoo/odoo#42505
X-original-commit: 222f72386a8a0a28ff450bf8dfa6a1ac8fa48d8e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Changes (+ fix) to the way inputs work:
- Placeholder is now independant from the default value and set through
data-placeholder. When emptying an input, it still sends the default
value but appears empty. The value is only visually added in the input
after leaving it (or hitting enter), after the validation through
_computeWidgetState (because now when the default value is applied on
a snippet, the value is displayed in the input as any other value).
- Consider inputs active if they hold a value and, in the case the input
has an associated unit, if that value is different from 0 (important
for visibility checks).
- If no default value is set and that a unit is set, the input will
return the ('0' + unit) value by default (no need to specify it in xml
anymore).
Part of https://github.com/odoo/odoo/pull/42407
Issue
- Install Mail template
- Enable debug mode (normal or assets)
- Create or edit a mail template
- Click in the text editor
The toolbar is not showing up (it does when we're not in debug mode)
Cause
We are doing `splice(-1, 0, ['view', ['codeview']])` on toolbar
which is undefined, the method crashes and the toolbar doesn't
render.
Solution
Checking if the toolbar is defined before doing all that logic.
OPW-2151675
X-original-commit: 0e5ca50d5a8401bb3495e83691eab5c86a97a616
* website, website_mass_mailing
Instead of a custom string, use the name of the snippet when displaying
an 'invisible' snippet in the 'invisible elements' section.
This commit also fixes a font-awesome bug introduced with the library
update revert.
Part of https://github.com/odoo/odoo/pull/41789closesodoo/odoo#41789
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website, website_mass_mailing
Instead of triggering an event on the invisible element when its related
button in the left panel is clicked, the invisible element's options are
now toggled (shown if were hidden and hidden if were shown). To do that
the new 'onTargetShow' and 'onTargetHide' methods are called, and the
appropriate action can be done there.
Those two new methods are also automatically called in other cases:
- When dropped in the page, after onBuild, 'onTargetShow' is called
for any snippet.
- Before cleanForSave: 'onTargetHide' is called for snippets with the
'o_snippet_invisible' and 'onTargetShow' is called for the others.
In case the element visibility should be toggled another way (like the
close button of a modal), the option can trigger_up an event named
'snippet_option_visibility_update' with a 'show' parameter so that the
the UI is updated accordingly (and so that the options are hidden if
necessary).
Part of https://github.com/odoo/odoo/pull/41789
Snippet enabling operations and snippet edition operations were mutexed
individually. In fact it simplifies the code and it is probably better
to chain all snippet operations, through an unique mutex.
Part of https://github.com/odoo/odoo/pull/41789
* web_editor
Previously, increasing the number of columns on the tabs snippet would
cause the newly created tabs to toggle the original tabs instead of its
own, this was caused by an oversight where the columns were clone
directly using jQuery, and the snippets' the onClone method was not
called on the newly created columns (here, tabs). This commit move the
responsibility to clone onto the SnippetsMenu so that it can create the
appropriate snippetEditor if needed and call its onClone method.
task-2070643
closesodoo/odoo#42130
X-original-commit: 77ebadfe6ada8ad1fa4d6e476b9534f252499d92
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The background position snippet option makes a copy of the snippet to
use in the overlay, such that it is over all content and the user can
easily see the end result of dragging the background. However, an
oversight in the CSS didn't account for the possibility of the copied
element to have a relative max-width (% of its container), because of
this, the overlay for those items was incorrect. This commit fixes that
issue by overriding the max-width and max-height properties of the
copied item.
closesodoo/odoo#42106
X-original-commit: 3b8cadd579f3309640a938bcce39ac83ac7a6942
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now, instead of extending updateUI, developers can extend
_computeVisibility and _computeWidgetVisibility to indicate if the
whole option or a specific widget needs to be visible or not.
Without any JS, developers can also add a 'data-dependencies' attribute
on widgets whose value is a comma-separated list of widget names. Widget
names are specificied through 'data-name'.
Other notable changes:
1) *All* the options UI of a same section are updated on a change (not
only the widgets of the same option).
2) Back as it was before: the UI is only updated in non-preview mode
(prevent flickering of background removal during color preview
because of point 1).
Part of https://github.com/odoo/odoo/pull/41600closesodoo/odoo#41600
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
No more notion of 'can update UI' and a callback to filter the widget
which should be updated: the base case is that a widget is not updated
if being previewed and notion of "being previewed" is extended to
"having the focus or being opened".
Part of https://github.com/odoo/odoo/pull/41600
- updateUI is async, most of the time it is really important to wait for
its async parts.
- method options are now async and should wait for async parts and user
choices before resolving their returned deferred.
While it was working perfectly in normal flows, some elements would not
have worked correctly if the datetimepicker was used another way. This
was revealed while working on another task.
This commit also fixes some issues:
- The datepicker was not working in languages where the date format is
different that the english one (the date was displayed correctly but
interpreted as if it was using the english formatting).
- Because of summernote, the datepicker sometimes loses the focus and
get it back directly... but this is enough for it to close. Now, we
open the datepicker on focus, not on click, so that summernote only
make it close then reopen right away (not possible to notice).
Jeremy Kersten