When a snippet is selected, its options are shown in a section named
after the snippet. The name is guessed from the block classes if it
matches those of a snippet or is simply retrieved from the data-name
attribute. The problem is that that data-name attribute was not written
on the DOM but as jQuery data in some case which make them disappear
under some circonstances (like cloning a whole snippet thanks to the
keyboard, etc).
closesodoo/odoo#36217
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now, the snippets options of the selected snippet use a blue color to
match the overlay color. When a block does not have any other option
than being removable or resizable, this helps a lot to see which option
is opened.
* mass_mailing, note, website, website_blog, website_form,
website_mass_mailing, website_sale
This commit, unfortunately, mixes three things:
- Restoring as much as possible the scss organisation to allow styling
the web_editor UI properly.
- Fixing some bugs like a border around the page once the editor is
loaded, no ability to scroll the snippets, etc
- Introducing a whole new UI for snippet options: a left panel instead
of the old dropdown & button overlay.
Note: this commit also do some linting and ES6 convertion even though
some of it has been done in the parent commit.
Note 2: some elements that were removed are still styled in the POS apps
but this is because part of a feature was removed while leaving dead
code behind, this is handled in another PR which is to be merged
(https://github.com/odoo/odoo/pull/36136).
Part of https://github.com/odoo/odoo/pull/36068
task-1942370
closesodoo/odoo#36068
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit aims at linting and converting to ES6 some parts of
web_editor JS to avoid as much noise as possible in UI refactor in next
commit.
Part of https://github.com/odoo/odoo/pull/36068
task-1942370
* mass_mailing, point_of_sale, website
- Lib files were included twice
- Variables files were split but added multiple times in the same assets
bundle
- Useless assets templates were defined or split
- ...
Part of https://github.com/odoo/odoo/pull/36068
Related to task-1942370
Hard to say when this was broken since the current work and revert of
the editor: when dropping a snippet outside of a dropzone it was not
dropped in the nearest one anymore because the dropzones were somehow
destroyed first in the current code.
Part of https://github.com/odoo/odoo/pull/36068
Discovered while working on task-1942370
Since we reverted the saas-12.2 editor in favor of the 12.0 one,
we faced a dilemna regarding how the editor iframe is handled in
mass_mailing.
The 12.0 version was using a special controller to get the website
assets required for mass_mailing while the saas-12.2 version used
a completely different mechanism that was, obviously, not handled
by the 12.0 version.
We did not want to reintroduce the old controllers who were
considered to be a hack to load the assets in the mass_mailing
iframe. However, we were very cautious about changing the editor
itself to avoid introducing new bugs in the editor core of 13.0.
The approach we chose at the end, is to use the loadAsset mechanism
introduced in saas-12.2 to load the necessary assets and inject them
in the mass_mailing iframe. This did not reintroduce the controllers
nor did it require to change the code of the editor itself. However,
it required moderate changes to the wysiwyg interface.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
These modifications crystalize the behavior of the old editor, even
if it makes less sense than the behavior of the saas-12.2 one.
In some cases, the only reasonable adaptation we could do for 13.0
was to delete the tests, as these tests relied on mechanisms of
the newer version of summernote introduced in saas-12.2 which
cannot be easily replicated in the older version from 12.0 that
we are reintroducing in this PR.
It is sad to see these tests go, but we knew this was going to be
something we would lose in reverting back to the older editor.
That being said, since these tests were not present back in 12.0,
we are simply back to the 12.0 state of things, not worse. Don't
weep for them though, they will be back in Odoo 14.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
This commit reverts the saas-12.2 editor by putting back the editor
of Odoo 12.
The saas-12.2 editor was an intermediate work between the previous
editor of Odoo 12 and the new one slated for Odoo 13. It was unstable
but it was supposed to be replaced by the new editor of version 13.
However, since the new editor has been postponed to Odoo 14, the
saas-12.2 one would have been staying in Odoo 13, which would have
been a nightmare to maintain. To avoid this outcome, we chose to
put back the 12.0 editor in its place.
This has the particular advantage that Odoo 13 will share the same
bugfixes as Odoo 12 and 11 as they all run under the same core
editor, while the saas-12.2 one would have been an entirely
different beast to maintain.
This is a partial revert of f2969923.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Summernote was updated alongside the new editor of saas-12.2. However,
since we are putting back the editor of 12.0, summernote needs to be
downgraded back to the version that was compatible with the 12.0 editor.
This is a revert of 17c6d005.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Do not remove block in _removeNextEmptyUnbreakable.
Before this commit, when you tried to remove insert a character in
a td, with an empty td after the first one. The function
_removeNextEmptyUnbreakable removed the empty td. It was for
example breaking snippet in the website and mass_mailing.
closesodoo/odoo#32096
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
For the ours need, we can not let the contentEditable behavior. Indeed,
this one does not have the same behavior according to the browser. The
DOM node could be erase, merge, cut, in them according to the keyboard
interactions. The problem is that if we have to manage these behaviors,
we have to manage everything. It was already the case in the previous
version, however before we created an editor by zone and by a hack we
mix the history.
In the case of the virtual keyboard of some OS / Phone, the events are
different and the autocompletion does not update (bug that prevents
modification interactions with javascript). In order to solve these
problems, we use another event for the insertion of the characters.
However, we must also force the update of the corrector by forcing a blur
and a focus.
The current version is a temporary version. We are currently working on a
version that uses a virtual dom and does not need to do excessive prevent
default.
Before this commit, for the following view tree:
P (active)
|
I (inactive)
|
II (active)
When calling `get_related_views()` on 'P', it would wrongly return 'II'.
It shouldn't, since its parent 'I' is inactive.
Step to reproduce:
- Go to /shop
- Enable ecommerce categories
- Enable Collapsible Cateogories
- Disable ecommerce categories
- Collapsible categories is still shown even if its parent got archived
closesodoo/odoo#35154
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, for the following view tree:
P (active)
|
I (inactive)
|
II (active)
When calling `customize_template_get()` on 'P', it would wrongly return 'II'.
It shouldn't, since its parent 'I' is inactive.
Step to reproduce:
- Go to /shop
- Enable ecommerce categories
- Enable Collapsible Cateogories
- Disable ecommerce categories
- Collapsible categories is still shown even if its parent got archived
Test writen in 12.0 with #35154closesodoo/odoo#35155
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
`_view_get_inherited_children()` `options` parameter is not more useful.
Introduced with ae8232136d and not used since edce2fd6d0.
Also, the opportunity is taken to rename `options` in `_views_get` into
`get_children. Indeed `options` does not mean much.
closesodoo/odoo#35157
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, when a snippet was cloned, its animation was not destroyed
first. The flow was:
1. Clone the snippet (DOM) - web_editor trigger `snippet_cloned`
2. Start cloned snippet animation - website listen `snippet_cloned`
This was causing bugs, eg facebook snippet for which the animation is to create
an iframe containing the facebook widget.
When cloning this snippet, its iframe would be cloned to, then its animation
would be started, creating another iframe.
To fix such flows, the snippet cloning flow should be:
1. Strop the snippet animation
2. Clone the snippet (DOM) - web_editor trigger `snippet_cloned`
3. Start cloned snippet animation - website listen `snippet_cloned`
4. Restart the original snippet animation
task-1951466
closesodoo/odoo#35029
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Having an assert that randomly breaks is quite annoying, as this assert
is not critical and breaks once every 100 - 120 builds. It can "safely"
be commented out before being fixed
closesodoo/odoo#35043
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Under certain unknown conditions, the range cannot be applied and
triggered an error. In order to allow the user to keep editing, we need
to prevent the dialog from showing, hence the use of `console.error`.
If this error appears, the carret is moved to the beginning of the focused
node.
If this error appears, then bullet can generate an error (I managed to
have the bug once or simulate it by manually breaking the dom and range)
We suspect a wrong snippet custom javascript code.
see: https://github.com/odoo/odoo/pull/34188closesodoo/odoo#34871
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Odoo Translation Bot