*: web, mass_mailing, website, website_form, website_sale
New CSS design of the editor (step 1/x).
This work is unfortunately far from perfect but is a first step towards
what we want. In particular, much CSS linked to elements that are meant
to be removed/moved in the upcoming weeks was done in a huge rush but
will thus hopefully be removed/reviewed before the 14.0 release.
As the design is now far more complex including gradients and other
"complex" elements, it was also very difficult to keep a design based on
css-variable so this system was removed, which means that the editor now
appears the same everywhere (backend, frontend, ...). The original goal
of this system was to have an adapted style for backend, frontend and
website visitors. Unfortunately, the current result was a very good
frontend editor design, a not-so-good backend editor design (for mass
mailing at least) and a totally unadapted design for the website
visitors. Making this perfect will be achievable by loading different
assets for those 3 areas and hopefully those assets will only differ by
the values of editor scss variables.
Part of https://github.com/odoo/odoo/pull/53930
task-2157252
Example where this was a problem: when clicking on a field type for
website form, the whole option is rerendered and we never go through the
"close" method of the clicked we-select element (which will be important
in the future).
Part of https://github.com/odoo/odoo/pull/53930
task-2157252
Commit [1] introduced the bug by relying on the fact an element with
id=top is in the edited DOM. As the website header can be disabled, this
induced a crash as soon as the header was indeed disabled. Also, the
editor is not meant to edit the website only so we cannot rely at all
on the presence of a #top element.
[1]: https://github.com/odoo/odoo/commit/6df67a28c2f113572acd4a3db19ab6b1bd37e7daclosesodoo/odoo#54409
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*mail,point_of_sale,web_editor,website
In the tests, required services are deployed for each test
independently. There is no need to have, in additon, all services
deployed globally. Worse, it could conflict and lead to unexpected
results.
This commit ensures services are no longer deployed globally in
tests. It turns the module 'web.env' into a declarative module with
no side-effect, by moving the service deployment to main.js, which
isn't added to the tests page.
Task 2287397
closesodoo/odoo#53817
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
*: web, web_editor
Instead of three lists + one map to define font information and user
choices saved as the index of the related fonts in those lists, the
fonts are now stored in an unique map <font-name> -> <data> and the
user choices are saved as the font name. This allow to have a visually
better definition of the fonts and allows to reorder fonts in the UI
without losing user customization (and actually simplify some code).
Unfortunately any user font customization < 14.0 will be lost, but this
is a small price to pay (users can still rechoose the same font in the
editor UI where they will go anyway to discover all the new shiny
features we are introducing there).
Part of https://github.com/odoo/odoo/pull/54065
task-2291398
closesodoo/odoo#54065
Related: odoo/design-themes#269
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the autoscroll on drag feature was accessible and only
used in the web_editor application.
After this commit, the autoscroll on drag feature will be available in the
web application and has been refactored in order to allow its usage
in other application (as for the sign application).
task-2280965
closesodoo/odoo#54072
Related: odoo/enterprise#11656
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Runbot 13.0
- Website > Contact Form
- Double click on send button
Link dialog opened, ok
- Discard
- Double click on send button
- Click link button
Traceback
Cause
The next double click doesn't work
because in rte.js RTEWidget._onMousedown
we remove the target's contenteditable
attribute and it's never added back.
This is because we break if the element
is not editable.
The traceback is a side effect,
since we can't select the button
anymore, our selection is incorrect
and getLinkInfo use range.create()
try to use it.
Solution
Break only if the target is not
a '<a>' & non-editable element
OPW-2268595
closesodoo/odoo#54221
X-original-commit: 460bc102d0f7503207fb7bd11216c335795dd33b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
*: website
Update the visibility (from dependencies and _computeWidgetVisibility
function) for all widgets, including the ones which are children of main
widgets (e.g. new ability to hide some choices from a select depending
on other options).
closesodoo/odoo#54162
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The mixin was inconsistent: depending on the color, the created rules
were `!important` or not. This causes bugs with new master features.
closesodoo/odoo#54151
X-original-commit: 83d8c8b66bd9e58b08fe0aa66d2be7bab691ce3e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website
The style to achieve the chess-like bg result was duplicated at many
places. The 'web' app was also actually using an image from the
'web_editor' app (we can live with it in stable as web_editor always
comes with web in auto_install but this was still a mistake).
closesodoo/odoo#54154
Also: fix some layout issue in the colorpicker widget.
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
this fixes is related to this PR https://github.com/odoo/odoo/pull/41561 where
are broken the behaviour of options for media dialog.
In this commit, we have changed classes names to fix the broken behavior of
options in the video tab of media dialog.
task-2154812
Closes https://github.com/odoo/odoo/pull/52135closesodoo/odoo#54041
X-original-commit: fafbd7525c481dfed6a3df2a5cd15fbd01ab4d31
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
*: web_editor
Do not display the backdrop element added by bootstrap in the body and
add a background on the modal to keep the same effect. The bootstrap
backdrop was probably useful for compatibility with <IE9 but is no
longer needed. This also avoids z-index issues because modals could be
opened in an element (e.g. the website #wrapwrap) whose stacking context
is different of the body one (where the backdrop is opened). This would
make the backdrop appears on top of the modal.
Part of https://github.com/odoo/odoo/pull/49142
Related to task-2229551
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, hovering options of a parent snippet displayed two
overlays: it's confusing.
After this commit, when hovering a parent property, only the parent
overlay is displayed, with the same style.
task-2182911
closesodoo/odoo#51476
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
Before this commit, the left panel input widgets were considering the
values between 0 and 1 as 'inactive' and thus were forcing their
default value if the user entered those. As the default is most of the
time 0, entering 0.9 gave a 0 result for no apparent reason.
Part of https://github.com/odoo/odoo/pull/52821closesodoo/odoo#52841
X-original-commit: ee08dbb27afe165035ee683884737d4867034913
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When 'data-apply-to' was introduced to be able to target different
elements for snippet option methods, we kept triggering the
'content_changed' event on the main option element. This can be a
problem if the main option element is not in an editable element and the
elements targeted by apply-to are, as that editable element would not
be marked as dirty.
Note: the bug could actually still be produced, even in Odoo <= 13.0
where the apply-to param does not exist, by using a option method
which searches by itself for an inner element in an inside editable
element. This is considered as a limitation for the time being.
Part of https://github.com/odoo/odoo/pull/52821
X-original-commit: 906b2d9d4679c03365f949633e3c90319724deb8
When a snippet contains a modal, the editor overlay should not cover the
0-height wrapping div but the modal element itself.
Part of https://github.com/odoo/odoo/pull/52663
X-original-commit: bc055e7822b9b2e7f8f9608e335456a71d7896a1
The loading effect of the left panel was conflicting with the invisible
snippet activation. This is to be reviewed with the new UI anyway, so
the loading effect is just removed in that case for now.
closesodoo/odoo#52676
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The computed preview for non-background properties (e.g. borders) was
wrong in the left panel since the color presets classes were considered
by mistake.
Part of https://github.com/odoo/odoo/pull/52605closesodoo/odoo#52605
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Windows > Chrome or Firefox
- Any chatter > Open full screen
- Paste any image
The image is pasted twice
Cause
Summernote adds the image but
the browser event adds it too
Solution
I applied the fix that summernote did
summernote/summernote/commit/6e432941af17c5fee0877d9ff54b6ace65fbdb4b
OPW-2267712
closesodoo/odoo#52532
X-original-commit: 2b4b2ce8660326b1cb53b5624690718b89aaceda
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
*: website, mass_mailing
In continuity with the nline crop, in an effort to make the image
workflow as seamless as possible in the website editor, the image
optimization feature has been moved out of the modal which could be
opened through the media-dialog and into the left panel.
This commit adds a quality slider and a width selector, as well as a
preview of the image's weight to the left panel, and removes the
image_optimize dialog.
This commit also introduces the possibility to add a color filter on
images.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
closesodoo/odoo#51517
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: base
Previously, cropping an image was done inside of a modal window, turning
it into an inline widget makes the editor feel more integrated and
allows you to better see the result of cropping directly in the page,
it's also less intrusive to the user's edition workflow.
At the same time, the way cropped images are saved was refactored to use
the new original_id field on ir_attachment, as the old system was
creating problems.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
In the next commit the crop functionality will be made into an inline
widget instead of a modal dialog, as such, the name no longer makes
sense.
Part of https://github.com/odoo/odoo/pull/51517
task-2192755
When attempting to update its UI in reaction to events, summernote tries
to make layout info for the event target, this relies on finding this
information on one of the target's ancestors. In some cases, elements
can be removed from the DOM between the moment the event was triggered,
and the moment summernote attempts to create the layoutInfo, resulting
in layoutInfo being null.
This commit prevents tracebacks from happening in such cases by checking
that a layoutInfo was actually returned, and if not, aborting the UI
update that relies on it.
closesodoo/odoo#52541
X-original-commit: 3e999db0c114d51102ae51f870f98a4cc276c4b4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If a mousedown event was fired over the left panel in edit mode while
the mouse up was fired over the current page in edit, the focus would
suddenly go at the top of the page due to pointer events. This made
input selection not easy on some browser.
task-2210712
closesodoo/odoo#52495
X-original-commit: 667ea8d586e8e8fdb7d0509e9ffc87fa5c76af56
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Ease the understanding of the drag'n drop of a snippet. Users test have
demonstrated that one doesn't understand how to add a snippet on the page.
* Rotate the snippet once clicked, as it is for tasks in project application.
* Keep the position of the mouse.
task-2261817
closesodoo/odoo#51905
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: web_editor
Note: on color palette change, all the colors of the user are reset and
he is warned about it.
Part of https://github.com/odoo/odoo/pull/52224
task-2197038
*: web_editor, web
Also now allows to control the copyright section color.
This commit also allows to use color name alias when the user choose
one of the 5 main colors or a gray color for one component (e.g. if the
user picks 'o-color-1' as the color for its text in preset 4, then it
will no longer be linked to the current css color of 'o-color-1' but to
'o-color-1' directly; meaning that if that color changes in the future,
so will the text of preset 4).
Part of https://github.com/odoo/odoo/pull/52223
task-2197038
* web_editor
Now, if the opacity of the bg color for a bg classes is lower than x
(currently 0.3), the class will only control the bg and not the text
and other components anymore. This behavior is disabled for presets
though (otherwise the text color would be "undefined").
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
*: web, web_editor
Now, the user can edit each individual component of each color preset
thanks to the third tab of the left panel. The edition of the first
preset is the same as the others for the users but it is actually
also used for "no-preset" areas, meaning that they impact the whole
website by default (*without impacting the other presets*). The website
thus appears as areas using presets, preset 1 being the default (in the
future all areas will be customizable with a different preset). The only
difference between "using preset 1 explicitely" and "not using a preset"
will be that background color is transparent in no-preset, leaving the
body background appear. If the body background has no image, then there
is no difference at all as the background color of the body is set to be
the background color of the preset 1. In boxed mode, that color is used
for the "box" and the website body uses a different customizable color.
Note: before this commit, the "text" color edition was used to set the
main text color and one of the constrasting color for the color-yiq
function (the darkest if a dark color or the lightest if a light color).
That last part has been removed and automatic colors will now always
use $gray-900 and $white as contrasting colors, unless changed by the
theme explicitely. This needed to be removed as now the "text color"
edition has been moved in the "preset 1" config and should thus only
impact the "no-preset / preset 1" areas instead of all the presets.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
*: mass_mailing, website_blog, website_forum, website_hr_recruitment
Deprecate alpha, beta, gamma, delta and espilon color names and now use
a new color system: o-color-x, with x from 1 to 5.
This will allow to review the colors of all themes to have nice visuals
for the new color combinations classes, without breaking the current
uses of bg-alpha, alert-delta, etc in current websites of customers
(by keeping the old color and classes for compatibility).
This will also allow to uniformize all themes under the same conventions
to enforce BS color override:
- o-color-1 used as primary (as before, for alpha)
- o-color-2 used as secondary (as before, for beta)
Before, some themes were not following the 2 guidelines. The users
using those themes will simply have the possibility to choose o-color-1
and o-color-2 colors accordingly to restore their website without
breaking the new system features.
Another change is that those colors are defined through color palettes
and not theme color palettes. This will avoid them to generate automatic
bootstrap classes which we don't want (alert, btn) and generate the one
we want by ourself.
Note: for mass mailing, the colors and classes also have been renamed
but the system stays unchanged.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
Now, the colors used in a color combination are accessible and possible
to override through the BS $colors map, with a specific prefix
(o-cc for "color combination").
So, to access the 'headings' color of the color combination 3, use:
color('o-cc3-headings');
If you don't need to completely override a color combinations preset,
you can override what you want through a color palette:
$o-color-palettes: (
(
'text': red,
'o-cc4-btn-primary': 'alpha',
// ...
)
);
As our current system allows the user to customize colors of the color
palette (like for menu, default text, etc), this will allow to easily
give them the possibility to override combinations colors in a future
update.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
qsm-odoo