Changing the `deleteContents` method of the editor is tricky. This
commit however dares to add a behavior: if the range does not
represent a selection but only the cursor position and is then asked
to delete its content... it should not do anything as nothing is
selected.
/!\ Partial backport of https://github.com/odoo/odoo/commit/0a31cb9b4ae461119ecafdd05c5b979621ffb039
/!\ Should not be forward-ported
Before the websitepocalypse introduced in 11.0 (saas-17), when saving a
page in the editor, every `cleanForSave` method of snippet options were
called, even for snippet options which were not initialized (so if a
snippet was left unchanged before saving, the related `cleanForSave`
methods were called anyway). This behavior was bad code and did not make
much sense and was so removed with the websitepocalypse
(see https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8#diff-4c580abda3220e45c6b3f6bdcf77c733L415)
Unfortunatly, the behavior was necessary given the states of our snippet
options. Indeed, for the "latest posts" snippet, the `cleanForSave`
method removes the entire snippet content (as it is dynamically loaded).
The dynamic loading is performed by the snippet *animation*... and
removing the dynamic content should logically be done by the animation
too... which is the case. The problem is that animations are not stopped
before the editor is saved. This behavior was only implemented in
saas-11.1 (for future version 12.0) with commit https://github.com/odoo/odoo/commit/0a31cb9b4ae461119ecafdd05c5b979621ffb039
As a stable fix for 11.0, part of the mentioned commit is backported
here and some specific `cleanForSave` will be reviewed as animations if
necessary. Note: `cleanForSave` made useless by this commit are left
anyway as this is a stable fix.
See https://github.com/odoo/odoo/issues/22089
- Remove useless snippet background suggestions (only one button to
open the media dialog directly)
- Show meaningful-only tabs in the media dialog (no document as
background, ...)
- When editing a background shows the background suggestions first and
show the background suggestions last for standard images. Technically,
this is done by filtering on the name/fname of the attachments and
adding magic name parts to the fname on image upload (e.g. when
uploading an image from the media dialog when customizing a bg, the
uploaded image will automatically be marked as a background). Note:
there were discussions to implement this feature with a tag system for
ir.attachment/s but the implementation's cost was too great in regards
to the feature.
- When editing an existing link or creating one from selected text, do
not show the "Link Label" field in the dialog; it was confusing. Only
show that field when adding a link at the cursor location with no
selected text.
Before this commit:
In the web editor, if you double clicked on a video iframe to edit it, it would
open the MediaDialog(media) with the wrong media element.
Media would be ' ' instead of '.media_iframe_video' (which is its grand
parent):
div.media_iframe_video
div.css_editable_mode_display
'& nbsp;'
Then, if you changed the media by another one (Image or Video), the media would
be wrongly inserted into the DOM, in the already existing iframe, eg:
(1) div.media_iframe_video
(2) div.css_editable_mode_display
(3) div.media_iframe_video
(4) div.css_editable_mode_display
(5) ' '
Since the new media (3) is wrongly instered into (2) instead of replacing (1),
the bug it would not be visible on normal mode (you would still see the
old media) because (2) is not displayed on normal mode.
Then on edit mode you would see both media one over the other.
Note: This only happened when you opened MediaDialog thought double click
directly (not 'Edit 'in navbar) and without clicking somewhere else after you
entered edit mode.
Now, if the media has an iframe parent, we use that parent as the correct media
This closes#22109, closes#22179
Courtesy of QSM for the help
* web, website, mass_mailing
Before this commit, the editor allowed defining the margin of some
elements and the height of some elements. There were three main
problems with this system:
1) When an user dragged the arrow, he often expected to change the
size of the element while he was in fact changing the margin
2) When changing the margin, you increase the space between two
elements but with a white space (while most users want a space
with the same color of the block they are resizing = padding)
3) When changing the height, the user was able to hide snippet parts
and the height was not consistent accross screen sizes
Now, the only thing you can edit is padding. There is only one arrow
for each direction, which allows increasing spacing and consistent
dimension at the same time.
The only feature that is lost with this change is the ability to
control vertical alignement of colored columns. This is not a problem
as colored columns are rare in our current snippets and there still
have the possibility to add margin classes by hand if necessary (there
are also plans to control vertical alignement another way).
Note: margin classes are kept for compatibility.
This was broken in 11.0 if the media dialog was the first dialog to be
opened when using the editor. This happened for two reasons:
- Never use a widget (dialog)'s `$el` before it is started (opened).
This was the case here. The bug is even worse in saas-11.1 as we do
not allow to do that from there so it results in a JS crash.
- It worked in <= saas-16 because dialogs were started at once as they
did not need to load anything. In >= 11.0, the first dialog which is
opened in the page needs to request the main dialog template and this
takes some time.
So, this fix makes sense in >= 9.0 but I chose to merge it in 11.0 as it
only induces a real bug from there.
* portal
When there are too many items in the top menu, the menu is broken into
multiple lines (especially on medium screen resolution). This commit
implements a system like in the enterprise backend: the extra items are
placed in a "+" dropdown menu at the end of the top menu.
Also, review the direction used to open dropdown menus. The default is
now left-to-right (while it was right-to-left before) and JS has been
added to determine the safe direction:
- If last item: to the left instead
- If would overflow the window: to the other direction instead
Now the colorpicker option can be defined with a `data-color-prefix`
parameter which will allow toggling classes different than "bg-*".
(e.g. if the prefix is set to be "hello-", the colorpicker option will
allow to choose between "hello-primary", "hello-danger", ...).
Before this commit, when defining two sets of classes to be chosen
independently on a same element you had to define two options:
```
<div data-selector=".myElement">
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 1</a>
<ul class="dropdown-menu">
<li data-select-class="a"><a href="#">A</a></li>
<li data-select-class="b"><a href="#">B</a></li>
<li data-select-class="c"><a href="#">C</a></li>
</ul>
</li>
</div>
<div data-selector=".myElement">
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 2</a>
<ul class="dropdown-menu">
<li data-select-class="x"><a href="#">X</a></li>
<li data-select-class="y"><a href="#">Y</a></li>
<li data-select-class="z"><a href="#">Z</a></li>
</ul>
</li>
</div>
```
Now, an unique option can be used for this, allowing to not duplicate
the `data-selector` and not creating two JS options:
```
<div data-selector=".myElement">
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 1</a>
<ul class="dropdown-menu">
<li data-select-class="a"><a href="#">A</a></li>
<li data-select-class="b"><a href="#">B</a></li>
<li data-select-class="c"><a href="#">C</a></li>
</ul>
</li>
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 2</a>
<ul class="dropdown-menu">
<li data-select-class="x"><a href="#">X</a></li>
<li data-select-class="y"><a href="#">Y</a></li>
<li data-select-class="z"><a href="#">Z</a></li>
</ul>
</li>
</div>
```
Before this commit, defining a snippet option began by choosing an XML
`data-selector` attribute to put on the option's <div/>. This selector
would then be used to find DOM elements on which to attach the option.
A recent refactoring added the `data-exclude` attribute, allowing to
define a selector that a DOM element must not match to receive the
option.
A new kind of need has arrived: allowing an option to be attached on a
DOMElement but making the option's effects be applied on a specific
child of this DOMElement. This can allow to regroup children options on
a main DOMElement.
To that effect, this commit introduces the optional `data-target`
attribute. If defined, its value is used as a selector to find the
option's `$target` inside the element found with previous rules. Note
that the system has been made smart enough to only add the option on
elements which indeed contain such a $target.
E.g. I want an option to appear in the customize menu of my custom
snippet's <section/> but will in fact control the toggling of a class
'super-row' on the `.row` (I don't want the option to be on the `.row`
otherwise it would not be in the main customize menu). All I have to
do is defining a
```
<div data-selector="section" data-target="> .container > .row">
<li data-toggle-class="super-row"><a href="#">Super Row</a></li>
</div>
```
(no JS required)
Note: a similar behavior was already present on the JS side of the
"colorpicker" option.
Depending on the speed of the runbot, errors may appear if one tries to
use a template that is not yet loaded. Templates are being
loaded and we add new template to read, the ready function does not
take into account new additions.
Avoid texts to be translated twice if some modules have the translated
value corresponding to the English source term.
To reproduce: create a translation for static xml (comment 'openerp-web')
with 'Modifier' translated by 'Tadaaa'. In french context, the 'Edit'
button in forms is translated by 'Tadaaa'.
Don't translate template in web_editor if we are in the backend because
the translations of all the modules have already been loaded and applied.
The rte_inline tour was failing on chrome because jquery selector in
chrome does not like a space in the style selector.
On the other hand, other browsers and phantomjs need the space.
This commit change the selector to find the element on chrome and
friends.
Fix over this one: https://github.com/odoo/odoo/commit/cae188514fa8b0a7c785a630ac4aff677b2071fa
The intent was to disable buttons in form views until html fields are fully loaded,
but it was not disabling the buttons for the following reasons:
1. It is looking for buttons in the DOM, although they
are not already attached into the body at this moment.
2. It was disabling the buttons only at widget start(),
so only once after "Empty Cache and Hard Reload".
We propose a better solution than disabling the buttons in the control panel:
when we click on "Save", the html field ensures that it is fully loaded while commiting the changes.
Summernote uses `document.execCommand` to apply most styles when
editing, leveraging the implementation to the browser.
Summernote is configured to use HTML styling (`'styleWithSpan': false`),
and in this case, browsers such as Firefox use HTML attributes for
styling text align, while Chrome still uses CSS for that. In fact,
`document.execCommand` is browser-inconsistent... but so is the
`styleWithSpan` option. Indeed, setting the option to `true` will make
Firefox use CSS property for alignment too... but not Internet Explorer.
So we might consider changing this option's value but this would not
solve the current problem.
Indeed, any CSS `text-align` style in Firefox takes precedence above
the element's `align` attribute, so when users were trying to align text
on stuff that was pre-aligned, they were unable to do so.
We can better explain the situation with this example:
A user tries to left-align in Firefox a `p.text-center` element, and
produces this:
```html
<p class="text-center" align="left"/>
```
(`align` attribute is ignored because of the `text-center` class)
On Chrome, this would be produced with the same steps:
```html
<p class="text-center" style="text-align:left"/>
```
With this patch, we actually make that HTML look like expected by the
user, no matter the browser he's using, by forcing the editor to use
the text-align CSS property. Note that the implementation is quite
ugly but had to take care of compatibility.
See https://github.com/odoo/odoo/pull/20900
(thanks to @Yajo for original PR)
Christophe Simonis