This commit allows to define steps in tours that drag&drop records
in (wowl) kanban views. The former helper is based on jQuery,
mostly because the drag&drop feature comes from jQuery. This
feature is still necessary for the legacy codebase using jQuery.
This commit thus introduces a new helper to allow the drag&drop
in wowl Component using, for instance, the `useSortable` hook.
This commit also fixes the project tour by making it use that
new helper. Note that even though the tour was broken (when run
"automatically", not in a user onboarding), runbot was green
because there's no test running this tour. It would be nice to
add one.
closesodoo/odoo#100208
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
Having a specific iframe selector like `div iframe.specificIframe div`
passed to `get_jquery_element_from_selector` would not work.
Before this commit, it would be split into:
- 'div iframe' outside of the iframe
- '.specificIframe div' inside of the iframe
After this commit, it is now split into:
- 'div iframe.specificIframe' outside of the iframe
- 'div' inside of the iframe
task-2898432
Part-of: odoo/odoo#94875
*: web_tour, test_website
Since [1] when the link popover was introduced, when the URL of a link
was made empty, an validation error appeared by the previously shown URL
did still appear inside the popover.
After this commit the previously shown link is replaced by a message
that indicates that no URL is specified.
The telephone and envelope icons are now also always removed when the
URL is change: they used to be only toggled, which made it possible to
make them appear and disappear by updating an email address or a phone
number.
Steps to reproduce:
- Add an image-text snippet to the page
- Select the image
- Add a link on the image
- Specify URL
- Click on image => link popup shows the entered URL
- Make the URL field empty
- Click on image
=> link popup still showed the previously entered URL
[1]: https://github.com/odoo/odoo/commit/8fcf930a6b6b7ffb0965b0a689c7a3117962ce7e
task-2765857
closesodoo/odoo#98845
X-original-commit: f212c56d73f5dad8eb5850b0b39cc92f55706ee2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, the isVisible helper would most of the time work as
expected, except if an element has display: contents. In that case, it
has no bounding box, but it may still be visible if one of its child
is visible.
This is particularly important since we want to set the display property
of all field components to "contents".
Part-of: odoo/odoo#96865
A tour finishing while a form is in edition mode is an issue, as it
then triggers an `urgentSave` which generates network traffic (and
promise handlers) during browser cleanup, at a time when the state of
the browser may not be entirely coherent.
Two methods seem to be the most common here:
- drop form during creation, aka the tour mostly wants to mess around
with onchange & ui & error reporting, in those cases the tour just
stops using the form, the "proper" way to handle this is to cancel
the creation and wait until back to the list view (note: the utility
step does not currently handle situation where the creation was
triggered from an other form view, or canceling an edition)
- save form during creation or edition, aka the tour wanted to create
an object, did trigger a save, but didn't wait for the save to
complete, leading to the tour finishing mid-save (which in theory
should allow the save to complete but may still trigger odd effects)
Part-of: odoo/odoo#96517
This commit fixes an inconsistent behaviour in tours using the website's
"Edit Menu" dialogs.
When adding a mega menu, two dialogs are displayed:
- The main "Edit Menu" dialog, from which you can open
- The "Menu" dialog with the mega menu label input
When these two dialogs were opened, and closed successively (click on
"Ok" to confirm the menu label, then click on "Save" to save the new
website menu), the tour was sometimes triggering the primary button of
the wrong dialog.
Two issues were leading to this inconsistent behaviour:
1/ Sometimes, the tour would click twice on the same primary button,
and would not wait for the current dialog to close.
To prevent that, extra_triggers are added to the steps to check that the
first click was correctly taken into account (and so, that the upper
dialog, that was the active dialog, was closed).
2/ Other times, the tour would click on the wrong dialog primary button
(it would click on the inactive dialog's button that would save the menu
without validating the label first).
This was coming from the web_tour.TourManager inaccurate
$modal_displayed property, which was defined and used in two different
javascript threads of execution. It could reference modals that were
not the actual modals from the DOM, when used in _check_for_tooltip.
To prevent that, that property is set inside the method it is used in.
It could be defined as a const and not a property, but this way the
commit history is left untouched.
runbot-4000
runbot-4001
runbot-4004
runbot-4005
closesodoo/odoo#94924
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit is two-fold:
1) events triggered with jQuery do not go through the native
layer, so if an handler has been bound natively, it won't be
called. Since our new code no longer uses jQuery, this caused
issue in some tours.
2) this commit explicitely logs the failing step when a tour
crashes, which helps debugging.
Part-of: odoo/odoo#92475
This commit adds an attribute to the iframe element in website_preview
so that the tour system knows when the iframe is ready. This is
necessary as tour could click on the iframe before the widgets where
properly started and therefore clicks would be ignored.
See merge commit for more information.
task-2687506
Before this commit, when using 'iframe ...' as a selector for a trigger
in a tour, the first iframe found was used to query and find the
trigger. In the context of this PR, the iframe fallback was used to find
the triggers in the website tours.
This commit adds a o_ignore_in_tour class, used to filter out those
elements in tours.
See merge commit for more information.
task-2687506
In mass mailing, when an iframe is loaded, the `contentDocument.body`
could be `undefined` this caused a traceback when trying to observe
the iframe.
Observing the `contentDocument` is safer as it will always be defined.
task-2869490
closesodoo/odoo#92630
X-original-commit: 00a2843216128df6454d5c6ced3a34cd02e7d6d9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, iframes DOM mutations were not taken into account to
update the tour manager. So in the context of mass_mailing, displaying
the web editor in an iframe, the tours were updated at the right moment
by chance (no mutations for 750ms in the global document and in the
iframe document).
This commit adds an o_iframe class, used to define an iframe that will
render a part of Odoo. An observer is added in the tour service to
monitor the addition of such iframe, and sets an observer on that iframe
to correctly update the tour manager, counting the iframe DOM mutations
for the 750ms delay.
In addition to this observer, the iframe's HTML content is added to the
final document HTML log when a tour crashes (directly between the
<iframe></iframe> for convenience, copy/pasting it in a browser just
ignores what's in between).
Also, when the tour_service is initialized in an o_iframe, it will not
run the tours.
This fix targets the saas-15.3 as it is needed to avoid a race condition
introduced with [1] (introducing a tour which relies on DOM updates
inside the mass mailing iframe). This could be backported if the need
ever rise (it should really have been the case since [2]).
[1]: https://github.com/odoo/odoo/commit/52d32e26c34bef10823582ef5c1f840492b73d7a
[2]: https://github.com/odoo/odoo/commit/971629b9fe40911c3a9765c9fb746ea1c55d3560closesodoo/odoo#91718
X-original-commit: ea35bd06c84b7101224c3b3dd24d1780e13232a9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: base_automation, iap, web_tour
Previously, when trying to create a custom dialog, one would need to
extend the base Dialog class and configure it directly on the class,
using separate templates for the body and footer as necessary. This is
very unidiomatic owl code, and it is much more natural to simply extend
Component, and use Dialog at the root of the template, giving it slots
and props to configure its properties and contents.
This commit changes the dialog API to work as described and adapts code
that uses it.
closesodoo/odoo#89113
Enterprise: https://github.com/odoo/enterprise/pull/26462
Related: odoo/enterprise#26462
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since [1] nested menus were not saved anymore because model ids do not
support `str` anymore.
After this commit the menus update data contain an integer `parent_id`
making them understood again by the model.
The `parent_id`s returned by `nestedSortable()` are the ones obtained
through a regex match, and therefore are strings.
Steps to reproduce:
- go to the 'Home' web page
- click on 'Edit Menu' in the 'Pages' menu
- drag and drop a menu item to nest it (e.g. put 'Contact Us' inside
'Home')
- click on 'Save'
=> nested entry disappeared from the menu instead of being nested under
its parent
[1]: https://github.com/odoo/odoo/commit/534087fa8d3c9947a918aa109f4030b5628a80d1
task-2781260
X-original-commit: d7bfb935580d6cc70dc213657c1a6dbc85dfa756
Part-of: odoo/odoo#89147
Currently, if the tip does not have any content set in step (happens a
lot in test tours), the tip is not displayed properly. This happens
because the height of the tip is set based on the tip content which is
not available in our case.
This commit fixes the behavior by providing a default content in such
cases saying "Click here to go to the next step.". It has two benefits
(in case someone is manually walking through a test tour):
- The tip is displayed properly.
- We can guide the devs with a friendly message.
task-2792218
closesodoo/odoo#87939
X-original-commit: 922370ffb6c9b64e1440db2e9b92d1c9e03e7253
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
According to [1], the update function can be called before the tip
is rendered (i.e. when this.$el is null). [1] aimed at preventing
that function to crash when called in that situation. However, if
the function _delegateEvents is called and this.$el is null, it
crashes as well. This was a cause of non deterministic runbot
failure.
[1] a34cd7c662
Runbot build error: 3382
X-original-commit: 66dd147eb6d0aab10bf4d8883fa4965b76f55de8
Part-of: odoo/odoo#85573
Before this commit, it could happen that the trigger element of a
step was in the DOM at time t0, but was no longer in the DOM at
time t1, when we tried to actually execute the step, because of a
non zero running_step_delay. This commit checks again the presence
of the trigger in the DOM at t1, and if it isn't resets the step.
The same reasonning applies to the ui blocked check: we never want
to run a step if the ui is blocked.
X-original-commit: 119d509feb2cb93c648160af2848146e9c623e21
Part-of: odoo/odoo#85573
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
It also adds `useService("rpc")` when component needs it.
closesodoo/odoo#85389
Related: odoo/enterprise#24745
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: base_automation, hr, mail, web, web_tour, website_payment
Previously, some modules were imported twice, this increases duplication
and can make refactoring more difficult. This commit enables the
no-duplicate-imports eslint rule and fixes offending modules to remove
duplicates.
closesodoo/odoo#84530
Related: odoo/enterprise#24319
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With [1] in 13.0, the blog post layouts were reviewed. At the same time,
new demo data was introduced. By default, with demo data, you have now
two different blogs. The JS tour was adapted so that when you create a
new blog post, a step explains you have to select the blog you want to
create the post in with the dialog that opens. The main problem that
this PR aims to solve is that all users start without demo data and thus
with only one blog... so with the current tour, the users are blocked
very early in the tour as they do not have the dialog to select the blog
in which to create their blog post. The simple solution that was chosen
is to set the step as "auto", meaning it will only be used in runned
tours (like via python tests), allowing to still test the blog selection
dialog in our python test. Users will not be guided via a tip for this
specific modal but this is not a problem as this is very straightforward
to understand in the case the user explicitely created multiple blogs
before creating blog posts.
This commit also review commit merged at [2] which made that python test
more robust by not relying on the demo data. That was here improved with
explanations.
However, allowing the tour to go further than the blog post creation for
the user... revealed that the rest of the tour was still blocking the
user. The very next step is to modify the blog post title. That step was
simply not possible to consume. Indeed the tour system asks for a click
event on the title... which is never detected because our old editor
removes all click handlers on that specific top-level editable area. The
cleanest way of fixing that is actually to not wait for a click but wait
that the user actually types text. For this purpose a feature was
introduced in 14.0 with [3] (even if unfortunately, that commit was not
well split). Unfortunately again... that 14.0 feature is currently buggy
during test tours as choosing the "input" consumeEvent alongside the
"text" run method... changes the behavior of that "text" run method when
the affected element is a contenteditable element. That should be fixed
but this will be done in a further update. Meanwhile, this commit
chooses to use the consumeEvent 'mouseup' which circles around both
issues.
[1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72
[2]: https://github.com/odoo/odoo/commit/f16f2e212a30352ead86c2f876be02b5c5e23b07
[3]: https://github.com/odoo/odoo/commit/a34cd7c662b3753d630d83793ffcb53b4a0a92d2
Bug revealed by testing task-2728994
closesodoo/odoo#83721
X-original-commit: ca82efe0c7b9a5e98d5c9623b3ae0f1b88fc8091
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
website{_*}: website, website_blog, website_sale, website_slides
Before this commit if several steps were referencing the same trigger
(e.g. "+New" button in website) only one was displayed, but all were
consumed when it was clicked.
Because of this the tour steps on "+New" were active even when its menu
was opened.
After this commit only the displayed step gets consumed if the step is
marked as 'consumeVisibleOnly: true'.
It cannot be done implictly on all steps because of [1].
This new marker is set on all steps referencing "+New".
The tour steps on "+New" now also require their menu to not be opened.
[1]: https://github.com/odoo/odoo/commit/5e888f8a6ccf9996b3231db6bf314d045619109e
task-2728994 (was task-2675252)
X-original-commit: 0fa40e37e596798665a098ee999f49749b6012a2
Part-of: odoo/odoo#83692
Before this commit tips could be revived after being destroyed if a
resize event occurred, because the resize was being debounced and could
trigger a request to rebuild the bubble mode of the tip.
After this commit the resize debounce is cancelled if the tip was
destroyed in the meantime.
However another unidentified reason still manages to trigger an
asynchronous re-creation of the tip after destroy() is called, even
though all timeouts are cleared.
The following remaining sequence has been identified:
- mouseenter.anchor is triggered: but this is disabled during destroy
- it calls _to_info_mode() which registers the timer_in timeout: but
this timeout is cleared during destroy
- it calls _build_info_mode() which registers the _transitionEndTimer
timeout: but this timeout is cleared during destroy
- it calls _onTransitionEnd() which calls _updatePosition() which
revives the tip
Therefore an additional guard is added to prevent _updatePosition() from
being executed if destroy() was called.
Note that the mouseleave > to_bubble_mode chain being symmetrical to
this one, it is likely that it could also happen.
task-2728994 (was task-2675252)
X-original-commit: 635675398c153e123e62dd30a35ba23a29503c70
Part-of: odoo/odoo#83692
After the update in [1], the tip is centered on text content
instead of text container to prevent asymmetry caused by text
alignment.
The goal of this commit is to prevent tours from failing when
the target node is empty[2] by centering the tip on text content
only when the target "hasChildNodes".
[1]: https://github.com/odoo/odoo/commit/ea3b1ec9a0984560f8fce5b5a04f6f24347f97c4
[2]: e.g. After #66844 : The blog will have title as <h1> tag
which is empty by default > which makes 'blog' tour fail.
task-2454130
closesodoo/odoo#80343
X-original-commit: 574ffa2a9f6ece51e446fefa4bc5f4b5acb4340a
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>
Since commit [1], it crashed when, at the end of a tour, we tried
to display a rainbow man, because we forgot to update the "type"
key.
74dc3f654ee5849982b494e46eefb1fc2b4e0c74
closesodoo/odoo#77306
X-original-commit: 6fa92d38e1945414f45411fc2e2528a8ef6f9fd1
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Tours are automatically disabled when the demo data are enabled on
at least one module. To ensure that, when giving the session_info
object, we read on the `ir.module.module` model to check whether some
of them have demo data.
Before this commit, this check only relied on the user's `is_admin`
flag, which does not give read access on the `ir.module.module` model.
Now, a `sudo` ensures that any admin user can read on the model.
closesodoo/odoo#76864
X-original-commit: 3a8d30d51a392f42d83d24b5f865f77b05205b50
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Rename `Debug Menu` => `Debug tools...`
Remove `Debug tools...` hotkey
The commands in the debug category need to have a search value
to be displayed.
Task-id: 2622240
Part-of: odoo/odoo#74933
*base_automation,iap,im_livechat,point_of_sale
This commit introduces a new file in core/utils: hooks.js
This file contains custom hooks (useEffect, useService, useBus...).
The useHotkey hook is tightly related to hotkeys, so it has been
moved to core/hotkeys.
closesodoo/odoo#74535
Related: odoo/enterprise#20003
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This makes the debug menu more natural to use, and makes the difference
between the "in-dialog" and "out-of-dialog" debug contexts explicit.
closesodoo/odoo#74346
Related: odoo/enterprise#19967
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Requires markup every markup-using tip content as Markup. Would be a
nice occasion to migrate everything to a markup-safe markdown I think,
especially if we could migrate the translations so we don't lose them.
Before, the tour tip was centered on the container tag instead of the
text content. That asymmetry was visible for text with a text-align
different than center.
Therefore the _reposition method of the tip has been modified to better
handle such text elements. If its anchor element has inner text we
use a range to get the width of the text.
task-2477212
closesodoo/odoo#67771
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When mouse hover on tour droplet, it shows tip information but when click on
app name(ex- expenses) and hover on tour droplet, it does not shows tip
information, it is because tip is now part of o_content element i.e. controller
element and when we click on app name it re-renders whole action manager and
due to which tip element also removed and later tip element added but new tip
insteance is not created, element of existing tip instance is added to DOM and
due to which event bound on previous element is not bound on new element, to
fix this we need to explicitly bind events on tip.
after this commit: tip shows information even after clicking on app name as we
explicitly bind events when tip is re-rendered.
task-2376278
closesodoo/odoo#73304
X-original-commit: c25c1d644e84cade8766c1f89930b46e88a33087
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Tip consumption is an RPC request. Because the test did not mock the
model or RPC, a warning would be triggered by the mock server.
* update `createTourManager` to forward parameters outside its very
own to the mock environment setup
* pass in a `data` to set up our model, including `fields` because for
some reason the default RPC mocking is quite cross when a model
doesn't have fields
Before this commit, rainbowman message was displayed using
`t-raw` in template.
Now, the message is escaped by default and needs to be marked as
HTML to be displayed as well.
closesodoo/odoo#72392
Task-id: 2575435
Related: odoo/enterprise#19121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the debug menu, when there is at least a tour "alive", click on
"Disable tours". Before this commit, it crashed because we sent the
whole tour description as argument to the consume method.
Issue reported on the wowl-bugs pad.
closesodoo/odoo#72445
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Be in debug=tests. Go on a Form View for res_partner. Go in the debug menu => start tour
start the tour "mail/static/tests/tours/mail_full_composer_test_tour.js"
Before this commit, the start tour dialog is not closed
After this commit, the dialog is closed
* iap, web_tour
This commit changes the API of the dialog service.
Before, the API gave 2 functions: "open" and "close".
Now, there is only one function "add" which is the same as "open"
but returning a callback that does the close.
closesodoo-dev/odoo#940
Related: odoo-dev/enterprise#171
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit renames the DebugManager to "DebugMenu", changes the
structure of its registry and the signature of its hook (useDebugMenu).
In the previous DebugManager:
- the "debug" registry was flat;
- new items were declared and created with the "useDebugManager" hook;
- these items were arbitrary functions returning a set of items.
The problem with that system was its extensibility, meaning that no
external module could hook on these arbitrary functions passed to the
hook.
In the new DebugMenu:
- the "debug" registry has multiple levels:
> root: "global" items, found in most debug menus
> subcategories: each subcategory has a name corresponding to the
context it's instantiated in (e.g.: the "view" subcategory will only
contain views-related debug menu items)
- all items are pre-declared in their corresponding category, and either
return a debug menu item or null;
- the hook activates/deactivates categories, and passes a context which
will be used by the item factories (passed as argument).
This commit, refactor the dialog api (dialog.js), to easier the creation
of dialog subclasses; force the use of dialog subclass when calling the
dialog service; forbid the use of dialog itself and promotes the use of
dialog subclasses.
closesodoo-dev/odoo#871
Related: odoo-dev/enterprise#151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the community codebase to the rewriting of the
/web application in owl.
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Variable `mutations` may have thousands of records. Using `.push(...mutations)`
would lead to error
STEPS:
* install website_sale
* create many categories:
```
for x in range(0, 4000):
env['product.public.category'].create({'name': str(x), 'parent_id': 9})
```
* open /shop
* click [Edit]
BEFORE:
```
Uncaught RangeError: Maximum call stack size exceeded
```
---
opw-2515707
closesodoo/odoo#72169
X-original-commit: 853a2cab3f896e99d5a4c498eea6ebf02e787b94
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This makes it possible to declare an element unsuitable as parent of the
tour tip via the "o_forbidden_tooltip_parent" class.
We then apply this class to the "o_we_customize_panel" of mass_mailing's
snippets menu so the tip is applied to its parent like in saas-14.2.
Without that, the tip is hidden by the body of the mail. The reason it
was positioned in the parent in saas-14.2 is that the theme selector
wasn't in the customize panel but positioned absolutely above it.
This is an ad-hoc fix to something of an ad-hoc situation, given the
relative weirdness of the html environment (the snippets menu is in the
padding of the body of an iframe).
closesodoo/odoo#69876
X-original-commit: 58d5af5df81926af1a5715dd57f6b5c3b40b1e16
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
This commit changes the way tours are automatically disabled when in
demo data.
Previously, an override of the assets_common template was applied by a
file loaded in the web_tour demo data, ensuring that the tours are
disabled when demo data are loaded in the database.
Now, a "tour_disable" boolean will be given to the session_info object
to determine whether the tour manager must be disabled, meaning that it
will automatically consume all registered tours.
This has been done to improve consistency in asset bundles declarations
by reducing them to the simplest possible templates.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
The tour system is based on many assumptions, some of those not being
true all the time. In practice, it works most of the time, but when
some slight changes occurs, we may observe undeterministic behavior.
This was actually the case in a dev branch working on assets: the order
of some files was changed, and it caused crashes in various tours.
This helped us identify two issues in the Tip class:
- the Tip class may be destroyed before it is completely started (so,
the destroy method should not assume that the code in start was called
- the attach_to method should not resolve if the tip was destroyed
meanwhile. This is critical, because some code uses that promise to act
on the widget.
This commit fixes both of these issues.
closesodoo/odoo#67896
X-original-commit: b88b634a0363a55411290e54e37806cfec1b2de5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Aaron Bohy