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
Previously, the media-dialog had a "filter" feature, where when changing
a background image for example, all backgrounds would show first in the
media-dialog. However, because this required to load all public
attachments in the database it was causing issues and was removed. The
backend code for this feature however was unfortunately forgotten, this
commit removes that code.
Part of https://github.com/odoo/odoo/pull/51517
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
*: web, web_editor, website_blog, website_event
New o_cc${xxx} classes where ${xxx} is a number [1-5] to style snippets:
they come with a background color, a text color, headings colors, a
link color, primary button colors and secondary button colors which
will later be possible to customize by the user.
The classes are made so that they are working on two levels. So if a
column receives a color class and the snippet too, everything will work
fine. More than 2 levels are not supported and the editor is made so
those cases should not appear. See o_colored_level class.
Part of https://github.com/odoo/odoo/pull/45856
task-2197038
*: web, web_editor
Disable the automatic generation of bootstrap color buttons and do it
ourself with a tweak: we introduce btn-fill-* (working as the normal
btn-* classes (in opposition to btn-outline-* classes). We then map
btn-* classes to either btn-fill-* or btn-outline-* classes depending
on the configuration (with a sass extend).
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
closesodoo/odoo#52220
Related: odoo/design-themes#288
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now only suggest bootstrap classes for buttons: link/primary/secondary.
Also review the link dialog to show only the options which are
meaningful to the chosen type.
Note: it will still be possible to change from an old color to primary
or secondary).
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
*: web_editor
Note: this work also prepare the code to be able to support different
font configs per font family.
Part of https://github.com/odoo/odoo/pull/52220
task-2197038
Instead of the text of the selected option displayed as label, we may
want another text (especially if the choice has long text). This can
be defined on buttons with 'data-select-label'.
Part of https://github.com/odoo/odoo/pull/52211
Related to task-2197038
Don't know how this test worked before but it will stop working with
next updates. This just make it more robust using the same trick as
other tests: wait for the colorpicker to be opened before actually
using it.
Part of https://github.com/odoo/odoo/pull/52211
Related to task-2197038
The goal is to reduce loadings as much as possible but there will
always be some. So that loadings do not appear as bugs and give users
some feedback that they are ongoing, this commit adds a loading effect
during the loading of some actions.
Part of https://github.com/odoo/odoo/pull/52211
Related to task-2197038
*: web_editor
When clicking on the theme tab on an empty page, a scrollbar appeared
and stayed. This was because the fake `<theme/>` element was focused and
the overlay positioned randomly outside of the page.
This commit fixes that by simplifying the code and always hiding the
related overlay. This commit also makes sure the onFocus/onBlur method
of the theme options are called consistently, even though they are
probably not useful.
Part of https://github.com/odoo/odoo/pull/52081closesodoo/odoo#52114
X-original-commit: 7760898de4e14fa30db1db87dfa05276bfcaa2bb
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the onBlur function of snippet options was not
called if the blur occured because of a click on the 'Blocks' tab.
Part of https://github.com/odoo/odoo/pull/52081
X-original-commit: 85049e2dcf68c40218bd0f4ed7401a4f979951d4
As the colorpalette has very big chances to have to be loaded when the
user enters edit mode (any click on a text will require the colorpalette
to be available), this commit makes it so the dependencies are loaded as
soon as the editor is started, without actually waiting for them until
the colorpalette are used.
This allows to make the first click on a text or on the theme tab a bit
faster to react.
closesodoo/odoo#52116
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Go to Project
- Open a project to display Tasks
- Switch to list view
- Click on create button
- On task form page, click nowhere. (It is important to not click on anything)
- On the taskbar of the WYSIWYG editor used for Description, click on one of the following actions:
* Unordered list
* Ordered list
* Checklist
* Table
* Style
- The action will be applied to the "name" field (Task Title) and
an error will prompt for Unordered list, Ordered list and Checklist actions
- If not, discard the form and retry by opening the form with create button
In this case, the WYSIWYG editor does not have the focus and try to execute
the tool action on the current focused element.
opw-2256835
closesodoo/odoo#52023
X-original-commit: eaa55ce3e806ad0d9609394309ff9d48b32bb73f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
View rendering from javascript has recently been made to check
permissions (See commits 64d0dab0a6
through ccc98e0169). Some assets required
by the iframe editor are rendered in JS so that they can be injected
into the iframe, but their permissions had not been updated, causing a
crash when trying to create or edit a mass_mailing campaign.
This commit fixes that by adding groups="base.group_user" to the
required templates.
closesodoo/odoo#51598
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The _view_get function is a recursive function used to retieve all the
views related to a view (inherited or t-called).
The issue is that by an odd set of circumstances it is possible to have
a loop in the view graph. Resulting in the recursive function being
called until a "maximum recursion depth exceeded" error occurs.
Example of a loop: A t-call B and A inherit from B
This is possible on an update of a view that has been forked by website:
If the view A was doing a t-call on B and is has been duplicated with
the arch modified.
When we update with the changes A now inherit from B instead of t-call B
Since the arch was modified it will not be updated so A will still
t-call B but the inherit_id of A is unchanged so it will be updated to
reference B resulting in a loop.
closesodoo/odoo#51620
X-original-commit: 63e1e84ebd7e609d6e06d83dc0f0092688b013eb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This lib is also used by the Gantt view, so we move it to the
common basis between web_editor and web_gantt, which is web.
Part of task 2205607
closesodoo/odoo#51606
Related: odoo/enterprise#9740
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Because of cross-browser compatibility concerns, jQuery's selector
engine makes using :has selector relatively slow. This is usually
acceptable, but in the case of snippet options, some options also need
to use :has in their data-target selector, and nested :has selectors'
performance degrade exponentially with the level of nesting.
Additionaly, jQuery evaluates complex selectors right-to-left, which
makes the :not operator quite inefficient.
Because of that, this commit removes :has and :not from the conditions
that were added at the end of the data-selector, and speeds up the
selector by a factor of ~15-40
Lastly, the addDropSelector options was actually unused, and a leftover
from the editor revert, as such it has been removed.
closesodoo/odoo#50073
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Colorpalette compatibility system was broken so old color classes were
not removed from snippets when being edited.
The bug was introduced by [1].
Also if a compatibility color class happens to use the same css color as
a current theme class, that one will now be shown as selected.
[1]: https://github.com/odoo/odoo/commit/c20423313cf10f262e615badc0397e6ba4ef4087closesodoo/odoo#51464
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Stop using the colorpicker dialog in the colorpalette widget.
Integrate the colorpicker widget in the colorpalette widget. Of course,
the colorpicker behaviors are adapted so that no useless rerendering
of the colorpalette is made on each value change.
The 'reset color' button is now a button like the other colors, no need
for a 'color_reset' event anymore. It is removed and replaced with a
'color_picked' event with color being an empty string. The clear button
now also work on hover.
Also, the topbar colorpalette for text and text background colors now
has the exact same behaviour as the background colorpalette: adding
color preview on hover.
The colorpalette now also closes on 'enter' keypress.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
closesodoo/odoo#46088
Related: odoo/enterprise#8696
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website, web
Move the colorpicker dialog logic into a colorpicker *widget*, which the
colorpicker dialog will now instantiate.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The method fields_view_get should be the only way to retrieve the view
content. This method is executed in a super-user context.
To avoid retrieving views for a model a user does not have access to
(as it may reveal some informations like name of fields), add a
verification of 'read' rights before retrieving the view content.
Execute _postprocess_access_rights with sudo(False) as this method is
used to evaluate which buttons should be displayed.
Remove the su flag to avoid misleading the user and displaying a
button they won't be able to use.
Retrieving the database id from an view key is not considered as a
sensitive information and get_view_id and viewref can be left as a
public methods.
Add missing sudo when needed
Change _handle_visibility in website to avoid increasing the query
count: Checking the visibility (to fail most of the time) to retry in
sudo was making unecessary queries.
Previously, when converting a number to a string we only kept 3
decimals, it turns out that when converting back and forth between rem
and pixels, we were losing enough precision that we had inexact pixel
values shown to the end user for odd number of pixels, even with the
default rem value of 16px.
This commit increases the precision to 5 to work around this issue and
allow us to convert exactly between rem and pixels at the default
16px/rem.
task-2248360
closesodoo/odoo#50881
X-original-commit: fdce273f4fe72a9e2555acecad3c2989110dac1a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
qsm-odoo