This commit fixes visual issues (pixel gap between shapes and bugs in
colors) in some background shapes.
task-2547435
closesodoo/odoo#78013
X-original-commit: 861dba13657f1ca41c40304abd212c521a6615de
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: mass_mailing, website, website_sale
Before this commit, it was impossible to add `fa-fw` directly on a
`we-button` as it would make the icon half invisible, since the whole
`we-button` would have the font-awesome `.fa-fw` css rule applied on it;
width: ~1.28em.
Then, one would need to insert a `<i/>` tag inside the `we-button` for
it to work.
This commit improves that behavior by handling automatically such cases,
and will preserve the purpose of the `fa-fw` class which is to have a
fixed width for those icons.
Note that the util class introduced in [1] (o_we_button_icon renamed
here in o_we_icon_button) is still useful to handle the case of svg
images, they are not allowed to shrink, the same way the fa buttons are.
[1]: https://github.com/odoo/odoo/commit/e4233643b93b521454cc146c6a2ae876781fb9ba
Related to task-2172311
closesodoo/odoo#77980
X-original-commit: e8ab9d76b802e80bb386812e4c8566825cbc2c92
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Sometimes the padding controls disappeared for no apparent reason. This
was when going from a child element to a parent element -> following
BVR's investigation, it apparently appears that the UI is not updated
anymore since already visible and nothing should have to be updated
since [1].
While waiting for a deeper investigation about the onFocus / ui update
flows, this commit restores the padding controls another way: by simply
not hiding them and showing them again at each blur / focus. It does not
seem needed indeed... or at least I cannot find a reason why right now.
Indeed, it was not the case before [2] which changed the system without
any explanation. With [3], the onFocus part was later moved to updateUI
since each onFocus calls are now followed by an UI update. But in this
case, like before [2], it only seems needed to show or not the padding
controls at option initialization.
Deeper investigation and refactoring will follow.
[1]: https://github.com/odoo/odoo/commit/806a8db35b5e0e6a461422f5bba7c97180c3ef29
[2]: https://github.com/odoo/odoo/commit/4f27e52cabb77b8b1a9637a11185ddf882adc9af
[3]: https://github.com/odoo/odoo/commit/3be9ae5672f76f85cd747f57539e7bc2919850f8closesodoo/odoo#77929
X-original-commit: 4de5d51948a121bb6df716f1b99cd86511b9cba9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the progress bar options were broken because the
stripe effect is achieved by a gradient in the CSS, but
`SnippetOptionWidget` recognized it as a manually selected gradient, and
thus applied the gradient specific handling (such as neutralizing the
background-image when a color is selected).
After this commit the special handling for gradients is only applied
where gradients are expected to be selected manually (i.e. when the
`withGradients` parameter is set).
task-2662401
closesodoo/odoo#77881
X-original-commit: f873c1d1eb05fa25717817c85899629103dcada3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Every options UI is updated when one is updated.
The Many2manyUserValueWidget is built in a way that every UI update will
trigger 2 rpc to get the records to display to the user, even if it is
not the option containing the widget that has been updated.
These rpc are now cached at the widget level.
This commit also fixes a bad computation of the Many2manyUserValueWidget
search domain.
task-2629245
X-original-commit: 847aecb4f9f4647e55e454d8c6560aa267f17c64
Part-of: odoo/odoo#77873
*: web_editor, website_sale_wishlist
The goal of this commit is to fix the issues with the header templates
and their related options. Such as:
- Alignment of inline language selector
- Alignment of CTA / Template content
- Add missing CTA in some templates
- Bugs with off-canvas hamburger menu
Unfortunately, it will require more work to make everything perfect.
task-2636546
closesodoo/odoo#77862
X-original-commit: 2a000e33c5a44ddf0a777b43d8266cc413d8e4e2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit reviews the component design in order to match the
"Configurator" one.
As a result, 'color-4' and 'color-5' are hidden in the palette-chooser
while remaining visible/editable once the palette is active.
This commit will also reorder color fields in the sidebar and in the
colopicker in order to match both the palette-preview & CC-list colors
order.
Beside design consistency, another reason behind these changes goes back
to the initial stages of the color system introduced with v14.
At the very beginning the system was designed to handle 3 custom colors
+ "locked" black and white.
Being able to edit black and white sounded interesting at that time;
as a result 'color-4' and 'color-5' have been introduced in the
system.
Despite being a powerful tool for designers and pro-users, the edition
of these color has been proven to be tricky an potentially unsafe.
Together with new default palettes that standardize 'color-4' and
'color-5' to safe values, hiding these color from the list simplify
the palette selection process and aims, implicitly, to communicate to
"normal" users that these colors are "not part of the palette", while
somehow related.
task-2656337
closesodoo/odoo#77857
X-original-commit: 02aba326710523bf210644e9038198059db1672c
Related: odoo/design-themes#514
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds a sass function that, given one or two colors, returns
an odoo palette in sass-map format.
The palette will be generated using the safest values possible, setting
'o-color-4' always to '#FFF' and shifting predefined colors' HUE to
match the primary color passed to the function.
Overrides (eg. 'menu': 4) are supported trough the '$-overrides-map'
method.
The commit will also allows to customize the "has-enough-contrast"
function threshold. Indeed, prior to this commit, the threshold value
was locked to '500' in order to spot contrast issues against the tiniest
elements (eg. small text).
Using a more forgiving '300' value, for example, allows to verify
readability of a solid button against a bg.
task-2656337
X-original-commit: 61f014a955ed9b9d33e7289c2a8a273a4179b088
Part-of: odoo/odoo#77857
When decreasing the number of columns through the column count snippet
option, the editor entered a deadlock situation.
This reverts [1] which is the cause, trying to await the UI update
during a snippet removal. This commit first prevents the deadlock while
waiting for a better solution to be implemented.
[1]: https://github.com/odoo/odoo/commit/ab7508393376075f95d6dd5925e7f4462936d24e
task-2652904
closesodoo/odoo#77848
X-original-commit: ae219ec06baf0280c76ae09b1453cc1481eece30
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The body's font size and line height were lost on transpiling it for
emails. This restores them by applying them to the mailing's top
element.
Part-of: odoo/odoo#77724
The mass mailing transpiler wrongly applied inherited colors to children
and failed to take inline styles into account, while those are supposed
to have the highest specificity.
Part-of: odoo/odoo#77724
When loading a field html iframe, there are sometimes display glitches
due to the iframe's contents and assets loading lazily. This prevents
those glitches by hiding the iframe until it is fully loaded, creating
a better user experience.
Part-of: odoo/odoo#77724
The body of a mailing is saved in two fields: body_arch without
modifications, and body_html with conversion for email client
compatibility. Prior to this commit, we were showing body_html when
opening the form view of a saved mailing in readonly. This was pretty
strange and confusing as it's a sort of intermediary version that
doesn't mean much: an in-browser rendering of html that is compiled for
email clients.
With this commit, we change the view to always show body_arch instead.
A new tab is introduced in order to show body_html for debugging, which
is therefore only visible in debug mode.
Part-of: odoo/odoo#77724
Commit [1] copied a lot of website snippet options into mass mailing.
Some were moved to web_editor and xpathed to be used in both without
duplicating code. Sadly that is not without side effects and it was
therefore decided to duplicate them instead so they can live separate
lives in the future.
[1] https://github.com/odoo/odoo/commit/4f7cd33d0fd69ee5984d0968233ffc73d7751030
Part-of: odoo/odoo#77724
`we-button`s, `we-toggler`s and `we-select-items` with no text content
don't properly take up their full height in iframes. This solves that
issue by ensuring a text content at all time, albeit an invisible one.
This is a bit of hacky solution perhaps but one that consistently works
across browsers.
task-2554899
X-original-commit: e59ad49cb9f32240d8ca3c89fc20ab200e291adc
Part-of: odoo/odoo#77724
Transparency is not supported in several leading mail clients. This adds
the option to completely remove transparent colors from the palette, and
uses that option in `mass_mailing`.
task-2554899
X-original-commit: 4e2c859b6d4fb8d9c12e24d1c8ebc84aa0f3c72e
Part-of: odoo/odoo#77724
The feature to drop snippets to the nearest allowed position was broken
in iframes because of a reference to a JQuery contained in a different
document than the editable area. This restores the feature in all cases.
task-2554899
X-original-commit: 4be474283f7fb6abbea8707d346f0d71939efce2
Part-of: odoo/odoo#77724
Prior to this commit, it was possible to drop snippets out of the
confines of the mailing's body and into its editable parent instead.
This makes that impossible.
task-2554899
X-original-commit: e3942e4aa1391ca82a946d4b6b3823d2690733ee
Part-of: odoo/odoo#77724
This brings a series of improvements to the mechanism in place to
convert the output html of mass mailing into html that is more compliant
with the main mail clients' requirements.
The biggest change is the automatic conversion of Bootstrap grids into
table structures. Currently all templates in `mass_mailing` are designed
with tables so they work in mailings as is. That has limitations though
as it makes it less easy to edit with snippets such as those used in the
website builder. This new automatic conversion from Bootstrap grid will
allow us to adapt the mailing and snippet templates and be more free
within `mass_mailing`.
Note: Because of the limited support of media queries in emails, this
doesn't support the mixing and matching of column options
(e.g., `"col-4 col-sm-6"` and `"col col-4"` aren't supported).
Other changes include:
- The conversion of Bootstrap cards to table structures
- The conversion of Bootstrap list-groups to table structures
- The conversion of snippets (.o_mail_snippet_general) and mailings
(.o_layout) into table structures
- The conversion of all rgb colors to hexadecimal
- The conversion of all "rem" sizes to "px"
- Various small corrections to the output styles
task-2554899
X-original-commit: e2e00939e09220051f6f4ecfb7bb3276105387bf
Part-of: odoo/odoo#77724
The img nodes where being wrongly considered empty by isShrunkNode
because the image was not loaded yet.
closesodoo/odoo#77646
X-original-commit: d18d51191bca8f063effd4a216c3963c187a8767
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
These encode/decode shenanigans seem to be unnecessary since we are not
using summernote anymore. Moreover, the encode process was destroying
the html structure of nodes contained in the link, only making a special
case to maintain images. This is not sufficient anymore because the
Cards option of website mega menu does make use of custom html content
inside a link. This content was therefore destroyed on edition and
replaced by its textContent because of the encode function.
task-2652361
closesodoo/odoo#77654
X-original-commit: 80004b1819fa1e1e7cfdd03a285de9d4ee845356
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Before this commit when computing the deepest position for a non-visible
node, if that node had no next visible sibling it used the previous
siblings, but it still marked the offset within that sibling as 0.
Because of this, the selection sometimes got lost.
E.g. in Firefox, drop an "Image - Text" block and triple click on the
header text: upon changing its color the range got set to the text node
but ending at offset 0.
After this commit if the used node in the "previous sibling" from the
evaluated element, the offset is set to the length of that node.
task-2655176
closesodoo/odoo#77567
X-original-commit: 3c4426c71ebe080bcbd285e271c61bf1580c3afa
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
When adding an odd width images on website, a thin black line is
drawn on its right side. The problem comes from the getSourceCanvas
of the cropperjs library. A translation is applied followed by an other
translation in the opposite direction. However the second translation
was not the exact reverse of the first due to a rounding problem.
The fix proposed here comes from: https://github.com/fengyuanchen/cropperjs/pull/300/commits/a6481c052cfc93ef14dd95a3bd00142215dda36e
task-2652904
closesodoo/odoo#77562
X-original-commit: 53f13979cc363c74a8f4e2cec0d24ca10c6ac11c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
ISSUE:
The click on "THEME" tab in editor panel triggers the
'_onThemeTabClick' method which:
1- Starts the loader ('_execWithLoadingEffect' method).
2- Runs '_activateSnippet' which uses the same mutex as the
loader.
Execution order:
A1- '_execWithLoadingEffect' with promise: adds the loader in
the DOM immediately.
A2- '_activateSnippet' sets a second loader to be added after
a delay = 500.
A3- 'releaseLoader' removes the first loader.
A4- '_activateSnippet' ends : (before adding the second
loader: t(4) - t(2) < 500) and timeout is cleared.
In some cases we get t(4) - t(2) > 500 which adds a second
loader to the DOM, and the new flow will be:
B1- Same as A1.
B2- Same as A2.
B3- Second loader added to the DOM / replaces the first one
in 'loadingElements'.
B4- 'releaseLoader' removes the second loader (from the DOM
& 'this.loadingElements').
B5- Same as A4 but the first loader still in the DOM.
The goal of this commit is to fix this behaviour by preventing
more than one loader on the target element.
task-2656308
closesodoo/odoo#77500
X-original-commit: 9f21b2eefab2115c1b8581ad9f43fe1e65f934ed
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Add a plugin for the Odoo editor that includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
- style t-tags to make them stand out
Task-27033
X-original-commit: odoo/odoo@300da82eb4
Part-of: odoo/odoo#77377
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Before this commit, if there were a change in the codeview of the
field html and the record was saved while the codeview was still open,
the changes made in the codeview were not saved.
closesodoo/odoo#77367
X-original-commit: d8a9d23a66d3662fc1c5e4e07e35a1de6800ffa5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The user was able to remove the mega menu snippet without removing
the corresponding link in the menu. To avoid this flow to happen
we removed the delete button for the mega menu snippet. We also
handle the case where the user remove the mega menu snippet element
by element. On last element removal we put back the original template.
task-2636545
closesodoo/odoo#77256
X-original-commit: 97810a9c40396bb27cb5779937734849d185cf1f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now, a snippet option can do async operations in its onRemove
implementation.
task-2636545
X-original-commit: ef2e55d7f407dedfbf724f2cae32a0fcaede6890
Part-of: odoo/odoo#77256
*: website, website_payment, website_sale
Instead of having a "o_we_large_input" class, now to have large widget, we can
use the generic "o_we_large" class (a future update is needing that for a non-
input widget).
task-2431285
X-original-commit: a8446e5d0f0b10f99f8174c012a6a53e2134b77a
Part-of: odoo/odoo#77255
Without this commit, the method `saveModifiedImages` did not use
editables zone but rather the whole `$editable`.
Because of that, oeModel and oeId were undefined and saving images
was done without the proper metadata.
That made impossible the retrieval of the images from the method
`ir.qweb.field.image` `from_html` defined by the module `web_unsplash`.
task-2581567
closesodoo/odoo#77259
X-original-commit: c32ef686e9744fc66f372921fce5cfaff739a76c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The new collaboration feature of the web editor was active by default.
We fix it to by making it an opt-in option on the field html.
X-original-commit: 86678b98dad069d864cb78baec5eb8af8bf30ce3
Part-of: odoo/odoo#77160
This matches the behavior of GDocs and CKEditor.
closesodoo/odoo#77115
X-original-commit: a84a6c869b815bf372d81db538b458cd23c99b07
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Don't set 'repeat-y' to false explicitely as it is the default value.
X-original-commit: 26612818d71f072eaf291df6d4ee839301f36dc7
Part-of: odoo/odoo#77119
In a undeterministic circumnstance, the editor has not enough
time to be loaded after `testUtils.nextTick()`.
By using a 100ms timeout instead, it will give more time for
the editor to be loaded and therfore reduce the risk of a false
negative to appear.
closesodoo/odoo#76980
X-original-commit: 190ddf08b8bb6c4750f1d0ad1c57f19b936794de
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Even though onRemove and onClone cannot be async themselves (yet?), it
is called via a trigger_up of `call_for_each_child_snippet` so that each
part of the snippet being removed / cloned has their onRemove / onClone
called. Doing that way, some SnippetEditor instances may have to be
created and it can be an async operation... the problem is that our code
was only awaiting the first of those instanciations instead of all of
them.
closesodoo/odoo#76881
X-original-commit: ea2a40afb96147e83c897a0376e187d8c957e66a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "Open in new window" checkbox was always initialized as false, even
if the link would open in a new window - both in the link tools and
dialog.
task-2172311
closesodoo/odoo#76880
X-original-commit: 52b034e8844336cc424e3126b843ec084fd7118e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* website, website_form_project
In master, there was an error when adding a form to a website and
selecting "Create a Task" with no active projects. This issue was solved
in PR #73269, by allowing tasks without a project associated. This
introduces a new problem: if a user wants to create a project (e.g. if
there is no active project), they will have to save their changes, close
the editor, navigate to Project, and only then will they be able to do
it. This issue could happen for other modules, so the solution has to be
generic.
In this commit, we add the possibility to add a button to the form
editor, next to a we-select item, which will redirect the user to a
specified action after prompting them to save their work. This button
can be added by specifying an action window in the corresponding
registry.
We also add the action window to the website form project editor, so
that the user can be redirected towards the Project app if they want
to create a project to select in their form.
task-2580436
closesodoo/odoo#76772
X-original-commit: e4233643b93b521454cc146c6a2ae876781fb9ba
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
On very small editors the restriction on the toolbar size
and position could generate issue (blocking text visibility).
So we changed the rules to allow the toolbar to overflow
outsize of the editable zone.
task-2648156
closesodoo/odoo#76710
X-original-commit: 6390a4225ea8a97fd0bc0b267d0d016846d27e46
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Sébastien Geelen <sebgeelen@users.noreply.github.com>
In master, when editing a date, the same date will be shown multiple
times next to each other. This is because each date is comprised of a
few times the same field with different formats, and when editing them,
they all remove their formatting and show the entire date.
In this commit, we allow adding the class `oe_hide_on_date_edit` to date
fields we don't want to show when editing, which will be dynamically
hidden (by adding the `d-none` class) when a user clicks on a field with
the same date.
We also add this class to some date fields in website_event.
task-2618494
closesodoo/odoo#75205
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Philémon van Helden <pvh@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
When adding an image to the library from an URL, if the URL contains
parameters (e.g. ?width=200&height=200), the link will not be accepted.
In this commit, we remove these parameters from the URL before checking
the image, so that the URL is considered valid.
We also remove these parameters before computing the mimetype of the
image, since it is computed based on the end part of the URL.
task-2618494
Part-of: odoo/odoo#75205
Brieuc-brd