Commit [1] introduced a flickering when any modal was opened on the
frontend. Indeed, it introduced the possibility to go into "fullscreen"
mode, which makes the Odoo UI navbar and sidebar disappear. This is
animated: the padding of the `<body/>` element is using a CSS
transition... but when a Bootstrap modal opens, the padding-right is
changed to compensate the scrollbar removal. This change now being
animated, it creates a flickering.
A generic solution was made: only animate what is animated for the
duration of the fullscreen mode switch.
[1]: https://github.com/odoo/odoo/commit/0b0690a3934cedcab0d5e34373e8d40c2ab25660closesodoo/odoo#55210
X-original-commit: ccadb20c82a651e9ef87e818b898f3e9a081cacd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, you could only add a tag on a blog post from the backend.
Here we're adding a way to add them from the left-panel so that it's
easier for the user to add them.
The long term goal will not be to reimplement complex view of the
backend. This is actually already past the limit: we will need a way
to instantiate views from the backend in the frontend in the future.
Part of https://github.com/odoo/odoo/pull/52759
task-2267693
closesodoo/odoo#52759
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Render inline SVG inside buttons in order to allow CSS styling.
Define SVG icons design for normal/hover status applying the same colors
as default text buttons.
In order to support multi-colors SVGs, this commits will affect inner
shapes in different ways:
- '.o_graphic' shapes: will gets the UI btns colors (default/hover)
- '.o_subdle' shapes: will gets a slightly reduced default text color
Shapes without '.o_graphic/.o_subdle' classes will be rendered normally,
as defined in the svg code.
Part of https://github.com/odoo/odoo/pull/54913
task-2157252
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: web_editor
-> Introduce the we-gpspicker widget and improve the way the gmap lib
is loaded (for Odoo / multiple snippets / ...).
Part of https://github.com/odoo/odoo/pull/49101
task-2091396
Enter keypress browser event were removed in 3c372d1da8.
It was reintroduced in text fields with d2f024d254 and this PR do the
same and reintroduce it for source mode of FieldHtml (`html` widget).
opw-2302605
closes#55066closesodoo/odoo#55081
X-original-commit: b10ca1f6094b7c8e6e222aa0ea3d1f891e79379a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, user could not selecta a date before year 1900.
This was an historical limitation due to python < 3.2 that didn't
support dates before 1900.
After this commit, user can select any date, user can select any
date from 01/01/0001.
taskID: 2166761
Fixes#41788Closes#43055closesodoo/odoo#51406
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Since the new effects on the header, the overlays do not overlap
correctly after the page has been scrolled. Now we hide the overlays
during the scrolling and show/recompute it after the scrolling.
Part of https://github.com/odoo/odoo/pull/51446
task-2229127
X-original-commit: 209a94d8c4fcdc2e74860c9392fc14a35aec52ed
Clicking on the delete button of custom snippets was not working anymore
since [1]. Indeed, that button is placed inside the snippet thumbnail
which is the drag handle for the drag and drop feature. Since we now
start the drag as soon as the mouse is mousedown-ed, then the click on
the delete button cannot be intercepted.
This commit solves the problem by placing the delete button out of the
thumbnail element.
[1]: https://github.com/odoo/odoo/commit/ab72fe6c4681f62dc670f1cf1ac6fa47abd301f6closesodoo/odoo#54770
X-original-commit: dac122935ac5c20526e529b09bf019f15a290d59
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website
Commit [1] broke the UI for some options related to CSS variables when
using Chrome. The commit made sure the string-value CSS variables are
printed with quotes, so that the JS representation of the CSS values can
distinguish them (strings = strings with surrounding quotes, others like
colors, numbers, etc = strings without surrounding quotes). With chrome,
the printed surrounding single quotes are read as double quotes for
strange reasons though... so the value "a" was not considered equal to
the value 'a'.
This commit makes sure surrounding quotes are normalized. This is done
through a new utility function to read CSS variables. This also makes
sure the values are trimmed, and colors normalized.
[1]: https://github.com/odoo/odoo/commit/3a34e39caa8544059dfb1888edc29c62c3efde31closesodoo/odoo#54757
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In some complex cases, some snippet editors were destroyed but were
still referenced in memory.
E.g.
1) Reorder a snippet gallery image
2) The code is implemented in such a way that reordering create a new
wrapping column for each image and moves the images in them.
3) This result in having the snippet editor linked to the old columns
to be explicitely destroyed and removed from memory, but not the ones
linked to the images as they are still in the DOM (just moved).
4) ... but the snippet editors linked to the images are children of
the snippet editors linked to the columns. They are thus implicitely
destroyed... but not removed from memory.
closesodoo/odoo#54643
X-original-commit: e4bf37c7fc892cdba57f0acac8e10f5698184e67
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The bug was already solved with [1] but was reintroduced later for
another reason. [1] solved the problem by checking that the current
option is not destroyed before asking for an UI update thanks to a
trigger_up (the option was destroyed because of image reordering). The
bug is now reintroduced for the same basic reason: a new trigger_up was
added between the potential option destroy and the destroy check, so
if the option is destroyed, that trigger_up fails to be triggered and
the editor is locked.
This commit solves the problem once and for all, hopefully, with a
more robust solution: only destroy options when none is being
processed. That way we ensure that all trigger_up occuring during an
option activation / update can be properly done.
[1]: https://github.com/odoo/odoo/commit/9eeea4c4107dc15984c475582d5ee58a17cd2568
X-original-commit: 7770430f78ee9e122a732fa042226d362467158e
Commit [1] broke the background videos feature. This is because the
'we-imagepicker' widget is now a sub-widget of a new 'we-button-group'
widget, acting as a selection choice (same as we-button in a we-select).
When selecting a selection choice, the appropriate option method is
called, with the selection value and params... but the params were
actually the ones of the 'we-button-group' element and not the ones
of the chosen widget 'we-imagepicker'.
This has never been important for we-select widgets but it could have
been. The problem is only solved here in master, generically for all
selection widgets (currently only 'we-select' and 'we-button-group').
The params received are the ones of the active sub-widget combined with
the ones of the selection widget.
[1]: https://github.com/odoo/odoo/commit/bb0cd4d5c82a9c2311f8c45ced0e9fdc0397d292closesodoo/odoo#54629
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: 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>
*: 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>
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>
*: 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
qsm-odoo