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>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
All background-color classes (bg-XXX) were defined before the color
combination classes. Except for the Odoo colors ones (bg-o-color-X)
which were defined after. That inconsistency was not a real problem
before as those two type of classes could not be combined but this will
change in the future.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
The editor sometimes compare CSS values, in particular in the
selectStyle method where a given style is not applied if it would have
no effect (e.g. applying an inline pink background-color is useless if
the block is naturally pink because of CSS rules). That comparison
failed when it was comparing 'var(--XXX)' and 'YYY' as 'var(--XXX)' was
not processed as the CSS variable 'XXX' to be read.
Related to task-2599770
closesodoo/odoo#75201
X-original-commit: 22b5d90539895bb7c2b14de4abbb2d7d978a6f79
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Whenever using the `getPowerboxElement`, it is possible to have a
null node.
closesodoo/odoo#75163
X-original-commit: 03d7021b251d31cfda055c6ffe9684fad191903c
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Some templates contain empty <li> elements for styling purposes
only and should be blacklisted in the context of Odoo editor hints
as these elements are not editable.
task-2550858
closesodoo/odoo#74944
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
If the active element is an Odoo field (ie. a field with the
`data-oe-model` attribute) it means the content should not be
considered html, unless its type is specifically `html`.
If the Odoo field is of the `html` type, the Powerbox should only
be triggered if the active element is _within_ that field rather
than _being_ the field itself.
task-2550858
Old shortcut (ctrl+K) was conflicting with the new command palette feature, so we change it to CTRL+M.
task-2593213
closesodoo/odoo#75069
X-original-commit: 0371fe2b9e54ff557265a8f8fc919d351ed6a7d5
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Mass mailing form view currently has a scrollbar for the contents of the
editor, one for the form view itself, and one for the sidebar. In
consequence we can sometimes end up with three scrollbars side by side,
which is ugly and confusing.
This ensures the height of the iframe is always that of its contents so
there is no need for a scrollbar.
When inserting a new snippet we want to autoscroll to that snippet. That
is a complicated situation because the element we want to scroll is not
in the same document as the element we want to scroll _to_.
To address that situation, a new option is added to `scrollTo` so we can
pass it the element to scroll. It can then check if we are in the
aforementioned situation, in which case it can correct the scrolling and
apply it to the right element.
We use that option in mass_mailing to prevent the bug.
Task-2545445
closes#71511
Currently, editing a mail feels a little claustrophobic because of the
boxes within boxes within boxes design. This commit removes the chatter
and the sheet from the form view so the mail editor can take up more
horizontal space. The chatter is then moved into one of the notebook's
tabs.
Task-2545445
closes#71511
The command bar hints were not properly text-aligned, and the color was sometime not visible depending on the background.
task-2607335
task-2607337
closesodoo/odoo#75028
X-original-commit: 0cd597558c2da268148ca8871442014edba3fdcb
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The bold command used `assignInlineStyle`, which misidentified when a text node needed
to be wrapped in an inline element in some situations, eg:
`<p>aaa<span style="font-weight: normal;">[bbb<span>c]cccc</span>bb</span>dddddd</p>`
task-2613476
closesodoo/odoo#75015
X-original-commit: a61fe7a338289b9195dfca56389593411daf2401
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Because of css rules, when a space was inserted (which is supposed to close the power box), it wouldn't be present in the innerText string.
It was fixed by using the textContent property instead, which contains all the spaces, including the invisible ones.
This might cause problems in some situation where the markup that the editor is modifying contains formatting spaces.
task-2584101
closesodoo/odoo#74766
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
The auto-link making feature would insert two spaces when the user would try to add one space.
It is no longer the case.
Some selection management with the link making has been fixed as well.
task-2584101
When the user selects text, the editor compares its closest block type
with a pre-made list of text types (eg. p, h1...).
In case of a match, the 'active' class is applied on the relative
toolbar component.
This commit will extend the comparison list adding text styles that were
initially missing (= the code, h4, h5 and h6 tags were never marked as
active).
Related to task-2496339
closesodoo/odoo#74925
X-original-commit: 1f1157c7e5c2df1bf318ad3a32e7030c969f5261
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When inside a specific color preset, active dropdown items' background
color is set to that preset's primary color. However, their text color
was not properly computed mainly because of [1] which forced other rules
as important.
[1]: https://github.com/odoo/odoo/commit/2172295cefa1d8780332709bf0c97cfa23def3a5closesodoo/odoo#74776
X-original-commit: 67fb206e2ef4828712a53052282aa0791edb74e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the popover would be displayed on top of the clicked
element if that element was a menu in a dropdown.
Indeed, there was not enough room for the popover to be shown correctly, as the
available space was the dropdown itself.
Note that if there was more than 2 menus in the dropdown, it would work
correctly as it would create enough space for the popover to be shown bellow or
above the menu.
Step to reproduce:
- Create a menu and a submenu
- Click on the menu, it opens a dropdown with the submenu inside it
- Click on the submenu, the popover position is wrong
task-2618494
closesodoo/odoo#74755
X-original-commit: b0b9fd2fd07fec96dd870467e8d9d8da7996c8ef
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Issue:
- [1] Edit mode > Set a shape on image (mimetype = 'image/jpeg')
- [2] Replace it by an animated GIF.
- [3] Replace the .GIF image again by the old one.
- The shape is not applied on it.
After the step [2], the image a dataset of:
{..., mimetype: "image/svg+xml", originalMimetype: "image/gif"}.
But when replaced by the JPG image in [3], we get (in '_applyOptions()')
an image with the following dataset:
{..., mimetype: "image/jpeg", originalMimetype: "image/gif"}
This incoherent state is caused by the fact that the mimetype from
attachment will be added on shape image in loadImageInfo(), which
affects the result of '_isImageMimetypeSupported()' method
(image is considered as a .GIF), and as a consequence, the shape
won't be applied.
We already have code (in '_onImageChanged()' method) to fix mimetype
in this case, but the goal of this commit is to move this code to
'_loadImageInfo()' to prevent this kind of incoherent mimetype values.
IMPORTANT: after this commit, the right mimetype value for GIF images
is passed and shapes cannot be applied on them (shape data will be
removed from non-supported images)
task-2578242
closesodoo/odoo#72639
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Added documentation to the methods of the ImageTools SnippetOption.
Also, removed unnecessary config from the transform method, which was
specific to the wysiwyg transform method to allow for reset on double
click.
The ImageTools transform and crop options now correctly set their button
to active or not.
Two reset buttons are added next to the transform and crop buttons,
visible when a transformation was made on the image.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
closesodoo/odoo#74592
X-original-commit: fc3706a0736c2c76dfd1a261a1455146b1699ce7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds two events to either enable or disable and cancel
loading effects at the SnippetsMenu level.
This is useful if we want for a snippet to be edited without showing the
loading effect. In the context of this PR it is used for image
transforms.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
X-original-commit: c45896fdd5a89e7954d8afeeb89ff51bb16ab438
Before this commit, the editor overlay was not correctly applied to
rotated elements.
After this commit, we apply the transformation of the element to the
overlay. For that, we needed the original top and left offsets of the
element. These values are obtained by cancelling the transform before
computation, and reapplying it after application to the overlay.
With these original top and left values and the transform property also
applied to the overlay, we are able to display it with the correct
rotation over transformed elements.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
X-original-commit: 8c7815bc02b06914966aca524cf95675706944b8
REASON FOR THE FIX
To correctly display the overlay over a rotated element, we need to
reset the transform of the element, to be able to apply it on the
overlay.
Changing the style of the element in the SnippetEditor cover method
would trigger a DOM mutation, which will result in setting the
odooEditor observer unactive.
The issue was that flushing the observer (when setting it unactive)
would always send an event observerApply, even if no record was
processed.
It was an issue as the SnippetsMenu was triggering a content_changed
event at the reception of this event, which would rerender the
SnippetEditor overlay cover (and create an infinite loop of events).
SOLUTION
To avoid that, the observerApply event is sent only if records were
processed.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
* Remove AST in favor of pure Pyhon. This should make it easier for
developers to understand and create new directives because they do not
need to know AST.
* Remove `t-call-options` as it has been merged into `t-options` for more
consistency. Support for t-call-options is retained.
* Use generators for lists. This increases performances as the rendering
can be sent directly without having to wait for the creation of the
entire list.
* Optimize expressions runtime computation by pre-computing the static
parts.
Example:
'<' + 'div' + '>' + '<' + dynamic_value + '>'
Now compiles as:
'<div><' + dynamic_value + '>'
Sébastien Geelen (sge)