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
When displaying a view with the same html field in multiple places,
we would have some conflicts between the editors if they start in collaborative
on the same channel.
task-2647125
closesodoo/odoo#76676
X-original-commit: 7bc676d751baeb030030eb814fc4a78200b80777
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Signed-off-by: Sébastien Geelen <sebgeelen@users.noreply.github.com>
Before this commit opening the color palette only checked for the
available space below the button to open the popup above instead.
Because of this the popup sometimes opened higher than the top of the
screen making it unusable.
After this commit an additional check is done on the space available
above the button. If there is not enough room above then just opens
below, which makes the area scrollable if there was insufficient space,
thus keeping the palette usable.
task-2599771
closesodoo/odoo#76611
X-original-commit: 3ac197de28f7b4403a55342f387189fc9a1d74e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since cfe079221c, unsplash is not working anymore as that commit did not adapt
the unsplash code to that change.
task-2581567
closesodoo/odoo#76617
X-original-commit: 9a4723628e868836c7bbe8bec31ec9b6ce3f2554
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
After this commit, it is possible to animate text in website pages.
task-2545252
closesodoo/odoo#76610
X-original-commit: 187acb938f70a2130d25fa76079221339c742f1e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the toolbar container was closed when we clicked
on its background or in its title bar.
task-2545252
X-original-commit: 2ca87a5142a03540fc5e6428530d394faa223d17
Part-of: odoo/odoo#76610
Before this commit the button custom color colorpickers were not updated
when a color was selected - but this was alright because the
colorpickers did not remain opened.
After this commit the button custom color colorpickers are updated
whenever a color is picked, which is necessary during gradient edition.
task-2599771
X-original-commit: f40c980d7ff68f27b389a93cd2b8f60cbff5baa6
Part-of: odoo/odoo#76608
Before this commit the color palette was updated directly during the
color picking event management.
After this commit picking a color updates the whole UI, and the global
UI update also updates the already opened palettes.
task-2599771
X-original-commit: 5698cf982c7e4499ed8b6f933ad364b9db475922
Part-of: odoo/odoo#76608
The languages displayed for the ConditionalVisibility option are now the
ones available for the website.
The select widget is hidden if there is only one.
task-2629245
closesodoo/odoo#76537
X-original-commit: 380edf50bd1d8d1f7b1a33fd4fa1ad70dbc12804
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit toggling the user menu did display the link popover.
After this commit no link popover is displayed when clicking on the user
menu (or any other dropdown menu) anymore.
task-2612755
closesodoo/odoo#76511
X-original-commit: ffaa406884bd5a897a0f76e993c915691ab850ba
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit button colors were only obtained from one of the
predefined styles.
After this commit button colors can be specified by using the new
"Custom" style.
task-2612755
closesodoo/odoo#76461
X-original-commit: a010c91b5ee119cf54ed1a68a6ea06b2bc5f3978
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
Before this commit several history steps were added when picking a color
and history steps were added when previewing a color.
After this commit history is only updated on color selection and not
during color preview: applying the color relies on execCommand which
adds an history step => no need to add another step upon picking a color
but must be prevented during preview.
task-2599771
closesodoo/odoo#76417
X-original-commit: 4c1956d697a52e4d561e93930bb9e9f5c61e8a35
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso-odoo@users.noreply.github.com>
It was previously decided that double clicking on a link shouldn't do anything
other than opening the popover (which happen on single click).
It was recently decided that we should actually open the right panel link tool
on double click.
Adding double click behavior, it was needed to refactor the way the popover is
opening/closing -> We now use `focus` as trigger instead of `click`.
Side effect, it will also fix 2641448 (part about double click on word)
Courtesy of SAD for debugging the double click issue (with trigger click)
task-2618494
closesodoo/odoo#76372
X-original-commit: 4eff35ab31bfc45b4c8dca8392e9da4f4e2a7afd
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when requesting the link tool in the right panel, it would
always focus its input.
This commit adds an option to not focus the input when link tool is requested.
It will be used by next commit.
task-2618494
X-original-commit: ad13055d58b6cd92d56f483bce17ab2e19216809
Part-of: odoo/odoo#76372
Before this commit if the text selection was lost while the color
palette was used, the color selection was not applied on anything.
After this commit if the text selection was lost, it is restored to the
last selection known in history before applying (or previewing) the
color selection.
Also avoid to remember selections that are not part of the editable.
task-2599771
closesodoo/odoo#76357
X-original-commit: 0e706d508d6e747cff566c33d34b794a321eef5c
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Use the method serializeNode of the editor rather than directly
the one from utils in order to only serialize when the collaboration
is active.
closesodoo/odoo#76143
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
By activating the profiler debugger, the two qweb options is added. The
qweb templates that need to be rendered are compiled into a new function
to add instructions for saving data.
`Add qweb directive context`
It's a sub-option of "Record sql" or "Record traces", add some context on
thread at current call stack level. This context stored by collector
beside stack and is used by Speedscope to add a level to the stack with
this qweb directive information.
```
directive=t-call='website.layout', xpath=/t/t
t_call_content
directive=t-foreach='5' t-as="'a', xpath=/t/t/div/div
directive=t-esc='website.search([])', xpath=/t/t/div/div/t
execute
```
`Record qweb`
Add profiling data used by ProfilingQwebView widget. In the `ir.profile`
form view, the widget display the duration and number of sql of every qweb
directives with the xml of templates. Every xml is recorded to be
consulted even if the user change the xml templates.
```xml
<t t-call="website.layout">
<div>
<div t-foreach="5" t-as="a">
<t t-esc="website.search([])"/> <!-- will display 5 separate requests -->
</div>
</div>
</t>
```
closesodoo/odoo#74712
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
344d82c commit changed how the editor `_historySteps` should behave.
Before that commit, `_historySteps` could have 0 steps whereas after
that commit `_historySteps` should always have at least the first step
be a snapshot. When reseting the history, we should now add a snapshot
as a first step. This commit guarantees it.
closesodoo/odoo#75901
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
344d82c renamed `resetHistory` into `historyReset` but failed to update
some calls to it and rename its equivalent in wysiwyg.js. This commit
corrects the discrepancy.
Part-of: odoo/odoo#75901
When saving a mailing, we do some processing (converting classes to
inline styles mostly) in order for the mailing to display properly in
all email clients. Until we started saving the processed version
separately from the unprocessed version, we had to revert the process
whenever we would start editing the mailing. This was extremely
expensive and made the loading of a previously created email very, very
slow. This was kept so far for backward compatibility reasons 3 years
ago (see f296992). This commit removes the that unnecessary conversion.
Part-of: odoo/odoo#75901
Since the introduction of Odoo Editor, `field_html`'s `_getValue` uses
`wysiwyg.getValue`. This conflicts with the mechanism of `mass_mailing`
which modifies the html of the editable area in place to save an
"e-mailable" version on the `body_html` field, then relies on
`_getValue` to reset the original html (`body_arch`).
This ensures the field has a value before modifying the html in place,
so we can manually restore it instead of relying on a side effect of the
old behavior of `_getValue`.
Part-of: odoo/odoo#75901
