Before this commit several history steps were added when picking a color
and history steps were added when previewing a color.
After this commit history is only updated on color selection and not
during color preview: applying the color relies on execCommand which
adds an history step => no need to add another step upon picking a color
but must be prevented during preview.
task-2599771
closesodoo/odoo#76417
X-original-commit: 4c1956d697a52e4d561e93930bb9e9f5c61e8a35
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
It was previously decided that double clicking on a link shouldn't do anything
other than opening the popover (which happen on single click).
It was recently decided that we should actually open the right panel link tool
on double click.
Adding double click behavior, it was needed to refactor the way the popover is
opening/closing -> We now use `focus` as trigger instead of `click`.
Side effect, it will also fix 2641448 (part about double click on word)
Courtesy of SAD for debugging the double click issue (with trigger click)
task-2618494
closesodoo/odoo#76372
X-original-commit: 4eff35ab31bfc45b4c8dca8392e9da4f4e2a7afd
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when requesting the link tool in the right panel, it would
always focus its input.
This commit adds an option to not focus the input when link tool is requested.
It will be used by next commit.
task-2618494
X-original-commit: ad13055d58b6cd92d56f483bce17ab2e19216809
Part-of: odoo/odoo#76372
Before this commit if the text selection was lost while the color
palette was used, the color selection was not applied on anything.
After this commit if the text selection was lost, it is restored to the
last selection known in history before applying (or previewing) the
color selection.
Also avoid to remember selections that are not part of the editable.
task-2599771
closesodoo/odoo#76357
X-original-commit: 0e706d508d6e747cff566c33d34b794a321eef5c
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Use the method serializeNode of the editor rather than directly
the one from utils in order to only serialize when the collaboration
is active.
closesodoo/odoo#76143
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
By activating the profiler debugger, the two qweb options is added. The
qweb templates that need to be rendered are compiled into a new function
to add instructions for saving data.
`Add qweb directive context`
It's a sub-option of "Record sql" or "Record traces", add some context on
thread at current call stack level. This context stored by collector
beside stack and is used by Speedscope to add a level to the stack with
this qweb directive information.
```
directive=t-call='website.layout', xpath=/t/t
t_call_content
directive=t-foreach='5' t-as="'a', xpath=/t/t/div/div
directive=t-esc='website.search([])', xpath=/t/t/div/div/t
execute
```
`Record qweb`
Add profiling data used by ProfilingQwebView widget. In the `ir.profile`
form view, the widget display the duration and number of sql of every qweb
directives with the xml of templates. Every xml is recorded to be
consulted even if the user change the xml templates.
```xml
<t t-call="website.layout">
<div>
<div t-foreach="5" t-as="a">
<t t-esc="website.search([])"/> <!-- will display 5 separate requests -->
</div>
</div>
</t>
```
closesodoo/odoo#74712
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
344d82c commit changed how the editor `_historySteps` should behave.
Before that commit, `_historySteps` could have 0 steps whereas after
that commit `_historySteps` should always have at least the first step
be a snapshot. When reseting the history, we should now add a snapshot
as a first step. This commit guarantees it.
closesodoo/odoo#75901
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
344d82c renamed `resetHistory` into `historyReset` but failed to update
some calls to it and rename its equivalent in wysiwyg.js. This commit
corrects the discrepancy.
Part-of: odoo/odoo#75901
When saving a mailing, we do some processing (converting classes to
inline styles mostly) in order for the mailing to display properly in
all email clients. Until we started saving the processed version
separately from the unprocessed version, we had to revert the process
whenever we would start editing the mailing. This was extremely
expensive and made the loading of a previously created email very, very
slow. This was kept so far for backward compatibility reasons 3 years
ago (see f296992). This commit removes the that unnecessary conversion.
Part-of: odoo/odoo#75901
Since the introduction of Odoo Editor, `field_html`'s `_getValue` uses
`wysiwyg.getValue`. This conflicts with the mechanism of `mass_mailing`
which modifies the html of the editable area in place to save an
"e-mailable" version on the `body_html` field, then relies on
`_getValue` to reset the original html (`body_arch`).
This ensures the field has a value before modifying the html in place,
so we can manually restore it instead of relying on a side effect of the
old behavior of `_getValue`.
Part-of: odoo/odoo#75901
This commit allows to use the editor collaboratively for any html
field in peer to peer using webRTC.
task-2497931
closesodoo/odoo#75768
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
Commit [1] introduced a "hack" to transform `'NULL'` values into `null`
values in some maps as normally-defined `null` values are automatically
removed (replaced by a fallback). This hack did not need to be general
and in web_editor but can rather be confined to website only for the
user palette maps (especially since the fix made by the parent of this
commit here).
[1]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2bclosesodoo/odoo#76033
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When [1] was introduced, we prevented to define a 'null' value for a
parameter P in a palette and forced a fallback to a default value X
defined in a "base" palette (value X which could be null). That allowed
to ensure that all final palette values were consistent as always
fallbacking to a "safe" value. However, since then, we introduced [2]
which makes it so a parameter P in the "base" palette is defined to X
(not null) while null is a valid value for P. We could keep the old
system and define that paramater P to a 'null' value in the "base"
palette and add the default X value in all palettes explicitely... but
with this commit we are choosing to be less tolerant (but in fact more
tolerant to custo) and rely on the fact palettes are well defined with
valid values (e.g. not defining a value to null while only X or Y are
allowed for example). Indeed, an exception for the "null" value did not
make much sense: if only X or Y are allowed as value for a parameter P,
setting a random Z value was not prevented, only null was.
[1]: https://github.com/odoo/odoo/commit/05d17089c4a604cb49f1a263b68f39aeffecccda
[2]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2b
Part-of: odoo/odoo#76033
Make the default height of the editor quite smaller in res.partner view.
To avoid "breaking" the design and prevent scrollbars
task-2586137
Part-of: odoo/odoo#75863
There were two issues when cloning a website_form field:
1/ Cloning is not done
Steps to reproduce :
Drop a form from the editor, save
Click on edit, select the field
Click on the clone option without hovering the label position option
2/ A traceback is thrown
Drop a form from the editor, save
Click on edit, select the field
Click on the clone option after hovering the label position option
Some FieldEditor options modify directly the dom and replace the field
node, which the editor will detect as a change of unbreakables. As a
result a rollback will be required in the next call to
odooEitor.historyStep(), done in SnippetEditor.clone().
To solve that we skip potential rollbacks while recording a history step
during a clone.
task-2485093
closesodoo/odoo#75908
X-original-commit: 7a75f295087cb02f162477a9df3b138b6780dbdd
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A new class has been added for snippets that should not display their
parents options: o_no_parent_editor.
With that class the editors for the parents of this snippet won't be
created.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
*: web_editor
As the mega menu templates are now displayed as an option of the mega
menu snippet, opening the mega menu dropdown in edit mode will display
the options.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
*: web_editor
The masonry templates selection SnippetOption has been abstracted so
that mega menus content can also be replaced with template content.
Part of https://github.com/odoo/odoo/pull/71143
task-2502208
Part-of: odoo/odoo#71143
Since [1], a new option was added to the masonry snippet to be able to
switch its whole content to a different template. That option was
working great... until [2] was merged. Indeed since then, each option
change induces an update of the whole editor panel. In this case, this
happened:
- Add a masonry snippet.
- Click inside one of its column (the masonry options and the column
options appear).
- Switch masonry snippet template.
- An option was changed -> Update the whole editor panel... including
the column options... but that column is not there anymore since
removed by the template switching option.
Now, we ignore options whose target is not in the document anymore and
make sure to enable the right options post panel update. This commit
could be backported later on (even though the masonry option was not
available before, the bug is potentially there for community options).
[1]: https://github.com/odoo/odoo/commit/c90ab7b6646b603dcd0a49387b5eeba60ce17f59
[2]: https://github.com/odoo/odoo/commit/2cbb691a84ce186ddd34a2a4c76d95671ed6e834
Part of https://github.com/odoo/odoo/pull/71143
Part-of: odoo/odoo#71143
* = crm_livechat, hr, hr_holidays, im_livechat, mail_bot, purchase, sms,
snailmail, survey, test_discuss_full, test_mail, web_editor, website,
website_livechat
- Create new model `mail.guest` for guests.
- Rewrite some RPCs to target routes rather than model methods so that
guests are able to use them.
- Patch JS and python models to support guests.
- Create a stand-alone page and boot the channel in it.
task-2494829
closesodoo/odoo#75496
Related: odoo/enterprise#20417
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
4eafd78847 was not correctly adapted with new editor.
The `removeClass` and the css for that class was left in the code but the code
in charge of adding that class was just removed, breaking the behavior.
closesodoo/odoo#75786
X-original-commit: e59f91d74ad07430a4942efeeb479a538993c918
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Commit [1] introduced a new "image" option instead of fixing the "img"
option which already existed. Also it created a <img> tag with a "fa-fw"
class which does not make much sense. Also, our system with data-img
actually creates a <svg> tag so that the color of the icon is the one
decided in our SCSS instead of the one hardcoded in the image and so
that there is an hover effect.
[1]: https://github.com/odoo/odoo/commit/02ccad3200187724d5f133842032981fb91f7465closesodoo/odoo#75743
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web, website
This commit redesigns the editor toolbar improving its visual appearance
and introducing substantial changes wherever it is rendered.
== "Into-sidebar" design
The grid layout has been refined, improving its components allocation.
For the sake of visual simplification, "list-type" buttons have been
unwrapped from their original dropdown. For the same reason the button
to create a new table has been removed (users will have to use the
command-bar to create a new table).
Table's options have been moved to a section "ad-hoc", visible only when
a table is selected.
== Floating design (backend only)
The toolbar is now white to match the command-bar design.
In order to simplify frontend inheritance, the floating toolbar now uses
grid layout.
== Colorpicker
The generic code necessary for each design has been moved from
'wysiwyg_snippets.scss' to 'wysiwyg.scss'.
The style is now controlled by css variables allowing to customize
critical design properties without the need of SCSS overrides.
By default the design is white(-ish) to match the floating toolbar,
while in 'wysiwyg_snippets.scss' the variables are customized to get the
typical sidebar's dark feel.
Note: despite the task main objective was just to improve/fix the
design, this aimed to simplify design inheritance and reduce the css
too. While inheritance has been improved reducing the amount of
overrides, the attempt to reduce the css partially failed (in the final
lines count must be considered that a new sidebar section has been
created).
The reason is that we currently suffer from a deep and complicated
inheritance structure for this component. The xml template uses default
bootstrap classes that are styled differently depending if loaded in a
community or enterprise environment. This approach leads to overrides
that must cover all the scenarios while further customization must be
taken in account too 'cause the toolbar can be rendered into the sidebar
with a totally different design.
A possible solution would be to detach from bootstrap directly in the
lib using custom classes names, and then @extend these classes
differently according to the current environment but probably not a good
idea as we want the toolbar to use bootstrap for in-website editors (so
they can match the theme correctly) but this has to be reviewed as well
anyway. To be checked.
Part of https://github.com/odoo/odoo/pull/73565
task-2496339
closesodoo/odoo#73565
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The "floating" and the "into-sidebar" toolbar designs are visually very
different but share the same XML template.
Prior to this commit we relied on SCSS overrides to achieve the two
designs, meaning that any new rule added in wysiwyg.scss was supposed to
be followed by an override in wysiwyg_snippets.scss.
This approach led to glitches and undesired behaviors, especially
considering that all customizations we apply are already overrides of
the standalone OdooEditor lib (that, by the way, applies its own
overrides on top of bootstrap too...).
This commit will add the 'oe-floating' class by default, and will
remove it when the toolbar is rendered inside the sidebar.
This approach allows to target the floating design when needed only, and
consequentially will leave the '.oe-toolbar' selector for the code
shared between the two designs.
Part of https://github.com/odoo/odoo/pull/73565
task-2496339
Part-of: odoo/odoo#73565
Step to follow
1. open any record with a chatter enabled )
2. start to write a log note in the the full composer
3. write a line with at least one character, then shift+enter
-> There is a traceback
Cause of the issue
InputEvent.data can be null
opw-2622051
closesodoo/odoo#75726
X-original-commit: 503bbe7a4d0cdd0aefcb723460210b089732831a
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
In master, in the 'Theme' tab of the website editor, the button to edit
color schemes has a light bulb icon, which doesn't clearly represent what
it does.
In this commit, we replace it with a palette SVG. Since we-select
elements do not have an image option implemented, we also add one
for future usage.
task-2618494
closesodoo/odoo#75730
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When adding a media to the library using its external URL, the
confirmation icon (either error, warning, or success) will not be
spaced correctly, and will stick to the button on its right.
In this commit, we add a class to it which adds some padding on the
right.
task-2618494
Part-of: odoo/odoo#75730
"Dyn. Colors" implies that the colors are dynamic, such as in an
animation. This is not the case, as it just represents the main color,
or accent.
This commit renames the "Dyn. Colors" option to "Main Color" to better
match its functionality.
task-2618494
Part-of: odoo/odoo#75730
Before this commit if the Apply/Discard buttons of the background image
positioning overlay were drawn outside of the visible area the user was
unable to access them - and thus had to reload the editor page.
After this commit the viewport is always scrolled to the background
image positioning overlay, making it always usable.
Because the block is always scrolled into the view, the buttons can
always be positioned near the top border of the overlay.
task-2627710
closesodoo/odoo#75679
X-original-commit: a9c3997b4bde08ceb75cacef7eb6ebad3efa7f44
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this fix applied color combinations were shown on the style
option.
After this fix the style option is displayed as any other plain option.
task-2612755
closesodoo/odoo#75665
X-original-commit: 2327248b8f67f5312f5630bf64fe49a31e025a09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
- The UI was updated twice (first to remove the overlay then to reselect
a surrounding snippet) -> that could be done in one operation.
- The UI update was not fully awaited.
- Add some inline comments to make the code more readable.
Note: this could be backported if the need ever arise.
Part of https://github.com/odoo/odoo/pull/74941
Part-of: odoo/odoo#74941
The editor was updated to handle a TODO but the TODO comment was not
removed. Originally, I wanted this commit to handle all TODO comments
around that code but failed to find the time -> at least this fixes the
comments...
Part of https://github.com/odoo/odoo/pull/74941
Part-of: odoo/odoo#74941
This commit completes [1] by further reviewing the drag and drop
technical flow order:
- The content_changed event should be triggered before starting snippets
as well as it is only useful to signal the snippet modifications made
by onBuilt.
- The undroppable snippets update which was done first could probably be
done anywhere -> best to put it at the end when everything in the DOM
is done, and it is also the last thing the user expects to be done.
Note: in the new editor the role of 'content_changed' became however
unclear and should be further reviewed. This commit fixes problems with
the old flow in master though (problems around removing items in a
snippet during its onBuilt call).
[1]: https://github.com/odoo/odoo/commit/60d7bf6d7daea83db9332b4fc47a4ac6892d21d7closesodoo/odoo#75596
X-original-commit: efdfe261afd933972869305fd3358c764f7c18c3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Regarding previous commit, the option parameter can be removed
from _get_asset_content api, followed by a nice snowball effect.
Part-of: odoo/odoo#75248
Since [1], this commit the controls for the background image positioning
were not accepting events anymore and were below margin handles.
After this commit the controls for the background image positioning can
be used again.
[1]: https://github.com/odoo/odoo/commit/a37f27d08fe2113a81668959d23282e9ae741115
task-2627710
closesodoo/odoo#75576
X-original-commit: e266669361cde6f799683fa6b082777d0f416c57
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit editing a link that was saved with fill styles
did reset it to a different value and even changed the 'type' to 'link'.
After this commit re-editing the link works for each style.
task-2629461
closesodoo/odoo#75512
X-original-commit: 4f6cc912260c5b5689b0e87644ad119ef5a1389c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
When an option notifies that it was used, its ancestor SnippetEditor
instances were in charge of asking for an UI update of all their options
(see [1] where this was already fixed). This was inconsistent with the
logic of our UI where the value of one option might affect the value and
visibility of another option which comes *after* it, e.g.:
- the user sets a badge type to 'info'
-> the badge background option (below) is shown as blue
- the user adds a shadow
-> more options are shown afterwards to control it (not above)
After this commit, we now update the whole editor panel (parent and
child options) wherever the updates come from. The only important thing
is to first update the options UI then their visibility as their
visibility may depend on their UI status.
This allows at the same time to fix the source of a race condition, as
enabling a snippet also triggers an UI update whose async parts were not
properly awaited (which thus may lead to inconsistencies if the user
clicked everywhere in the DOM too quickly).
[1]: https://github.com/odoo/odoo/commit/7623a0c771495cd41bf40af37c0d2b6e4beb7cdc
Part of https://github.com/odoo/odoo/pull/74959closesodoo/odoo#74959
X-original-commit: 488b9ae45e728327e0d43b91b7c2d6edf2a33be1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The editor panel keeps tracks of the SnippetEditor instances which are
enabled at the current time. When previewing one (by hovering its UI),
that tracking was messed up making onFocus and onBlur calls inconsitent.
Part of https://github.com/odoo/odoo/pull/74959
X-original-commit: 0d7e660d8c0941b1af83b08a90d936933287d681
Before this commit, with some animations (e.g. Bounce In-Left) the
overlay of the animated element or the overlay of selected element
inside it no longer reappeared after the animation.
task-2630112
closesodoo/odoo#75444
X-original-commit: fb98430b1cdbc63896d152b39bcf23c0f2241cb4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Benoit Socias