*: base_setup, hr_timesheet, mail, partner_autocomplete, web_tour
Start odoo without -d and with a --dbfilter that allows multiple
databases. Via JSON-RPC access the /web/session/authenticate route
providing a non-filtered database and valid credentials. Traceback,
`request.env` is None.
Since httpocalypse the initialization of the ORM (cursor, registry,
environment) is greedy. It means that the connection to the database is
established very early during the request routing or skip altogether in
case no dbname was known at that time. This contrast with prepocalypse
where the various ORM thingies were lazily setup the first time they
were accessed.
This changement has an important implication regarding authentication.
In prepocalypse, thanks to the lazy approache, a cursor/registry/env
would be setup on the database you just login upon using the
`request.env` for the first time. This was very nice in this regard but
had other problems.
Since httpocalypse such operation is no more possible. Devs must
initialize and use their own cursor/registry/env in case they
authenticate on another database than the one `request.cr` is (maybe)
connected to.
The `/web/session/authenticate` controller is an example of such case.
It crates its own cr/registry/environment after authentication. The
problem the controller uses `ir.http.session_info` and that not all
overrides were updated to use `self.env` (=the env created in the web
controller) instead of `request.env` (=the missing env of the request).
closesodoo/odoo#108063
X-original-commit: 7b9bd9d37731fae724dc5d91da656dab70aa9ad4
Related: odoo/enterprise#35012
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit, the tooltip content of a tour had a font-size set in
rem. As its container dimensions were computed using the root element
font-size, these dimensions were not correct if the tip was inserted in
a document with another root element font-size.
This was leading to a bug after [1] added an iframe to edit the website:
the backend and frontend root elements font-size are different and the
containers of tips targeting frontend elements were clipped.
This commit fixes the tooltip content font-size in px (with the
font-size used to compute the container dimensions), so that it can be
placed in iframes with a different root element font-size.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3035156
closesodoo/odoo#106746
X-original-commit: 8703c01d0c0c84331e4d4adb00c8def962635e17
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Method `consume` is called at the end of a tour. Tour can be started via debug
menu by any admin with "Access rights", however the method requires `Settings`
access level.
Fix it by adding `sudo()`. This issue could be reviewed in master.
STEPS:
* change Administration access level to "Access rights"
* start tour `sale_quote_tour`
* follow the tour steps
opw-2965772
closesodoo/odoo#103801
X-original-commit: c96111bf1cc7611b3b3e0b9f210d50cff527cc91
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
The helper's final trigger was hooked not on the list *view* but on
the list *widget/component*.
As a result, on a form containing an x2many field the trigger would
fire immediately, before the form view was actually discarded, leading
to a race condition in the Python-side check for unsaved forms, and
thus non-deterministic tour failures.
Update the check to look for the view specifically, this should be
exclusive with the form view.
X-original-commit: 28c569d7cb0ffeda4cd9abcb8332e96c551cf03a
Part-of: odoo/odoo#103117
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Some onboarding tours were conflicting between themselves, with some
common steps. This commit introduces the possibility to skip a step
depending on the current DOM, making dynamic tours and ensuring tours
compatibility
task-3002442
X-original-commit: 1e4fb74f2cb8d500effa54d548dc9c29f12b32c1
Part-of: odoo/odoo#103036
Before this commit, the positions of the virtual pointer were not
passed to the mousemove event, preventing draggable code to correctly work.
After this commit, the Event is a proper MouseEvent, with clientX and clientY set
correctly.
X-original-commit: 2e60d1b733fd73021fb1dea490e6fa3ba2fc31d0
Part-of: odoo/odoo#102153
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
This commit makes failing custom `run()` functions logged as a failed
tour step.
task-2687506
X-original-commit: bcd679f1d204a8c3f858aa03a992686545829e4b
Part-of: odoo/odoo#101119
Due to how drag and drop works in grouped kanban views now, no event is
triggered when dragging and dropping, this fix listens to mousedown in
order to define whether the element is going to be dragged.
Part-of: odoo/odoo#98837
*: auth_password_policy, bus, calendar, event, mass_mailing, stock,
survey, web_editor, web_tour, website, website_event, website_forum,
website_mass_mailing, website_sale
This commit is a first step towards a potential deletion of the
assets_common bundle, although that step would need more work, specs and
discussions as some layouts kinda only use the assets_common bundle
(some take the full assets_common but parts of the assets_backend one
for example).
The main goal of this commit is to have the assets_frontend bundle
directly include the "common" files we need. As a first step, this
commit only blindly duplicates them all into assets_frontend (without
removing the potentially useless ones). The goal is to have those
advantages:
- Reaching a frontend page only calls two main JS files (one normal and
one lazy-loaded) instead of 4 (two normals and two lazy-loaded). This
may help reach a better google page speed (which is becoming more and
more strict).
- The frontend CSS is built as one: the common SCSS which was using
bootstrap variables, or even Odoo-based SCSS added by mistake in
common instead of both backend and frontend is now computed with the
right bootstrap customizations. E.g. the tempusdominus datetimepickers
use bootstrap grays... after this PR, they use the right grays as
customized by the user on the website.
It was also chosen to not have a common "sub-asset" which is included in
assets_frontend. Making assets_frontend completely independent makes
sense (as it probably will for other "main" asset bundles): we can focus
on adding the files each layout needs without the need of worrying if it
impacts unrelated layouts. Sub-assets (when not strictly necessary) is
also a source of errors: extending the "main" bundle instead of the
right sub-asset it may use (like it was the case with the sub-assets of
assets_common: _assets_common_scripts and _assets_common_styles as
explained in the previous commit). So this is indeed a small drawback of
not factorizing the code for the inclusion of "common" files in bundles
but it seems more explicit and easier to maintain that way. Note that
adding "common" file is not the most common usecase anyway, apps
generally only need files in backend or frontend.
The __manifest__ declaration will also likely evolve in more and more
uses of wildcards to match entire directories. In the future, adding
"common" web-app files in both backend, frontend and other "main"
bundles could just be about one line duplicated into each bundle.
closesodoo/odoo#100314
Related: odoo/enterprise#31394
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
Julien Castiaux