The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit fixes the totp tours which fail on a step in
the profile dialog. The step searches for an element
".o_dialog_container" that is removed since commit
e51112e0df7f5e05d3cdf2c01d236c6bbbf123a6
closesodoo/odoo#117451
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Login is a noun and not a verb. The corresponding verb is Log in.
And indeed the translation in French was "Identifiant" instead of
"Se connecter".
closesodoo/odoo#99478
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit fixes the style of the field, which was
pretty broken since the Owl conversion.
It also bring back the tooltip (as in legacy) when
the button is clicked.
The button now only shows the tooltip if the text
has been copied successfully to the clipboard, and
not appear when it is not allowed or not available
in the browser.
Tests have been added to assert those behaviors.
Enterprise PR to adapt a selector in tests:
https://github.com/odoo/enterprise/pull/30832closesodoo/odoo#98340
Related: odoo/enterprise#30832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous pass in #97567 missed a small window of race condition
in *closing the fecking dialog*. Apparently that's still not
instantaneous enough and it's possible to have the check trigger in
the interval between clicking the button and the dialog being
completely torn down.
Add an explicit test for this to the existing `closeProfileDialog`
utility function.
closesodoo/odoo#97969
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When #96517 was merged, it was missed that if hr is *not* installed,
then the user profile opens in a dialog in edition mode (always, can't
be readonly).
Since half the tours of `auth_totp` end in the profile screen (to
check that the totp state is what we expect) this means they work fine
in most test contexts where `hr` is installed, but they fail as soon
as `hr` is *not* installed.
Fix this by adding a helper function which checks whether the profile
screen uses a dialog or not, and closes the dialog if so (otherwise it
does nothing as the "form" profile screen is not in edition mode).
While at it, improve a bunch of steps:
- fold check steps which were really `extra_triggers` (something we
wanted to check but not manipulate, in the same screen as something
we do want to manipulate)
- convert a few promise-based functions to `async` (tours don't
support promises but async functions work either way and lead to
simpler code here)
- make better use of the tour action helpers (no need for explicit
`_get_action_values` calls for the most part, and no need to
call the internal versions either)
- clarify a pair of fixmes as I'd completely forgotten what they meant
closesodoo/odoo#97567
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The new list and form views were merged recently [1], but they
weren't activated because they weren't 100% ready yet. This is now
the case. This commit adds those views to the view registry. As a
consequence, a lot of qunit tests and tours needed to be adapted,
mostly for selector changes.
We also add legacy list and form views to the view registry, with
keys 'legacy_list' and 'legacy_form'. This allows to force those
legacy views when necessary. For instance, we did it in views
using complex custom legacy x2many field widgets that haven't been
converted yet (we have a compatibility layer but it isn't complete
and doesn't support every advanced usecases).
[1] odoo/odoo#92475
Part-of: odoo/odoo#78221
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>
Co-authored-by: luvi <luvi@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 mail dependancy has been extracted into a bridge module auth_totp_mail,
the test about "Invite to use 2FA" is misplaced in the wrong module.
This commit moves the test on 2FA invite button to the bridge module and fixes
the test on auth_totp module to use another indicator that 2FA has been disabled
for the currently tested user (see test file).
Task-2645206
Parent Task-2638538
COM PR: odoo/odoo#76381closesodoo/odoo#76579
X-original-commit: 305f94bf1b7ac7c106e05e60601640feca934005
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Original commit was adding the feature in stable but was replaced by
2dee29a7dc in 15.0
This is the forward port of 4736344a57e176 keeping only the test
closesodoo/odoo#76476
X-original-commit: f707d5887c168604b7b7571ae4adc47d64b4a55a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
Review the UX of the 2-factor authentication flow in order to make it more clear
and easy to use.
Specifications
==============
This commit applies multiple rewording of instructions, button, etc. Tests have
been adapted accordingly.
It also adds an 'invite to use two-factor authentication' flow that will
send an email to the selected used to redirect them their account security
settings.
- If portal is not installed yet, the user is redirected to his account security
settings in backend.
- If portal is installed, the user is redirected to /my/profile if them are
portal user. Otherwise, the redirection is still done at backend side.
As the backend view of auth_totp wizard is used at frontend side, copyclipboard
widget has to be rebuilt at frontend side (click event, style etc..).
As API key section is now displayed only on debug mode, test urls have been
adapted accordingly.
Task-2487630
Part-of: odoo/odoo#71142
Some of the TOTP-related forms contained an attempt at making a centered
modal pop-up, using a bootstrap `card` that would also serve to
emphasize that the interaction was sensitive and security-related.
Some of the "footer buttons" were moved inside the form to make it
more obvious that they were part of the interaction flow.
However some of this caused breakages of responsiveness and did not yield
a really satisfactory result anyway.
This commit switches back to using regular non-centered forms. It looks
quite ugly because the content is better suited for a narrow modal, but
it means less surprises in terms of layout and less responsiveness
issues.
closesodoo/odoo#58541closesodoo/odoo#58544
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This is a followup to #57826: turns out discuss isn't necessarily
installed (who knew?), so the tour would break if mail was not
explicitly installed alongside base, which is not great.
So instead of opening discuss to try and fix the profile race
condition, reload the *entire web client* by navigating to `/web`.
Further discovery: async run functions don't actually do anything in
tours, not sure where I got that, maybe used one for the convenience
of `await` then the next time around having decided to wipe any
knowledge of tours I had, I figured it wasn't possible that tours were
so stupid as to not support promises.
So yeah, can't just return a "pending" promise in order to force the
tour manager to wait until the page has reloaded to carry on, that
doesn't work. Instead use marker classes. Also remove the `async run`
I had in the rest of the file to avoid being misleading, use a marker
class for the one step where it probably matters.
closesodoo/odoo#58128
X-original-commit: d252b0c6311fd389295e980e6f9725673ce8b650
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
On runbot the tour shows transient failures related to race
conditions.
The issue here is that when a user updates their own TOTP status, if
hr is not installed this will close the Preferences dialog requiring
reopening the dialog in order to check that everything worked.
However if hr is installed there is no dialog ("My Profile" opens as a
full action, which will not disappear on TOTP updates).
We still reopen the My Profile action, but if the server is a bit too
slow the tour may see the "old" version of "My Profile" which has not
been unloaded, click the tab to go to the next step, but because it's
already there the action has no effect, the next step is triggered
when "My Profile" finally (re)loads at which point we're back on the
first tab while the tour believes it should be on the second, and the
tour breaks.
Fix this by forcing a full reload of the action: between updating TOTP
status and checking for the status change, navigate to the Discuss
application then back to the preferences / profile screen.
closesodoo/odoo#57843
X-original-commit: 7a1dc71186d00ece21cede205a045fa93cd6dcfb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* Not sure how the tour passed during merge as it would not be looking
for the button in the right tab, it would fail locally, fix this
issue by properly switching to the Account Security tab
* add the missing test of RPC (which should not work on an account
with totp enabled)
* also reorder ops & fix comments: turns out `totp_login_enabled`
checks that totp is enabled *then disables it*
closesodoo/odoo#55979
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
New module for supporting two-factor authentication via time-base
one-time-password (TOTP).
Users (including portal users) can choose to enable two-factor auth in
their user account settings, by scanning a QR code and adding it to an
authenticator app, such as Google Auth, 1Password, etc.
When two-factor is enabled, password-based non-interactive RPC is only
possible by using API keys.
Co-authored-by: Olivier Dony <odo@odoo.com>
Bastien PIERRE