Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Steps to reproduce
==================
- Go into sign-in > Don't have an account
- Enter a password starting with a special character (ie: $)
Uncaught Javascript Error > Failed to set the 'value' property on 'HTMLMeterElement': The provided double value is non-finite.
Cause of the issue
==================
`(password.split(/[^\W_]+/).length - 1)` -> 0
`0 / 0` -> NaN
`Math.min(NaN, 1.0)` -> NaN
opw-3397932
closesodoo/odoo#127337
X-original-commit: e377aae101477b414d5391036477280a0c18445c
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Steps to reproduce
==================
- Go to /web/signup
- In the password field, type something
- Clear the input
Cause of the issue
==================
A bunch of conditions evaluates to NaN inside
`ConcretePolicy.score(password)` when passing en empty string as a
parameter.
Solution
========
An empty password should always have a score of 0 anyway, so we can
do an early return. (The lengthscore would be 0, and we multiply by it
at the end)
opw-3269555
closesodoo/odoo#120711
X-original-commit: 6aa16bb740af14fcebd8f05bdc19c9e8879d77ed
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Not sure what I was thinking (there was no chance the validation would
be structural, probably didn't think about the validation itself).
Possibly thought of creating a proper `Recommendation` type then ended
up not doing it, but left the props types in.
closesodoo/odoo#100206
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The changes in `auth_password_policy` are largely the owlification of
the password meter widget:
- modernize the password policy module and convert it to an
odoo-module (note: now exports a pseudo-abstract class which is
really a policy, for the sake of somewhat sensibly typing
`recommendations`)
- replace the implementation of the Meter and PasswordField widgets by
owl versions
The changes to web and base stem from taking a look at converting the
ChangePassword wizard, and finding that it would be a pain in the ass
but also... unnecessary? It seems to have been done as a wizard
completely in javascript despite being backend-only for legacy
reasons: apparently one of the very old web clients (v5 or v6
probably) implemented it as a "native action" which was directly part
of the client's UI, and so it had to be implemented entirely in the
client.
Over time it was moved back into the regular UI (and moved around
quite a bit), hooked as a client action to maintain access to the
existing UI / dialog.
But since it's been an action opened via a button for years it can
just... be a normal wizard, with password fields, which
auth_password_policy can then set the widget of.
So did that:
- removed the old unnecessary JS, and its dedicated endpoint (which is
*not* used by portal, portal has its own endpoint)
- used check_identity for the "old password check"
- split out `change_password` with an internal bit so we can have a
safer (and logged) "set user password" without needing to provide
the old password, which is now used for the bulk password change
wizard as well
- added a small wizard which just takes a new password (and
confirmation), for safety a given change password wizard is only
accessible to their creator (also the wizard is restricted to
employees though technically it would probably be fine for portal
users as well)
Rather than extensive messy rewrite / monkeypatching (the original
wizard was 57 LOC, though also 22 LOC of template, the auth_policy
hooking / patching was 33, plus 8 lines of CSS),
`auth_password_policy` just sets the widget of the `new_password`
field in the new wizard, much as it did the bulk wizard.
Also improve the "hide meter if field is empty" feature by leveraging
`:placeholder-shown`. This requires setting a placeholder, and while
empty works fine in firefox, it doesn't work in chrome. So the
placeholder needs to be a single space. Still, seems better than
updating a fake attribute or manipulating a class for the sake of
trivial styling.
Notes on unlink + transient vacuum
Although the wizard object is only created when actually calling
`change_password`, and is deleted on success, it is possible for the
user to get an error and fail to continue (it should be unlikely
without overrides since the passwords are checked while creating /
saving but...).
While in that case the `new_password` in the database is not the
user's own, it could be their *future* password, or give evidence as
to their password-creation scheme, or some other signal useful to
attack that front of the user's life and behavior. As such, quickly
removing leftovers from the database (by setting a very low transient
lifetime) seems like a good idea.
This is compounded by the `check_identity` having a grace period of 10
minutes. 0.1 is 6 minutes, but because the cron runs every 10 the user
effectively has 6~10 minutes between the moment they create an
incorrect / incomplete version of the wizard and the moment where it
is destroyed if they just leave it.
closesodoo/odoo#99458
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Revision on https://github.com/odoo/odoo/commit/a47f6093f80cefa51c5a1bc1301db01007f97761
The commit above introduced a visual 'password strength' next to
the password wizard in Settings > Users, when the module
`auth_password_policy` is installed.
However, there was an traceback when trying to access the 'General
Settings' when some specific apps and modules were installed.
This issue comes from the small design issue with the new
PasswordField: it was designed as a field object that was
instantiated and returned in the `init` function of an InputField
with the password attribute set. This is not a solid design,
because the documentation of the `init` function does not
specify that it should return the newly instantiated object.
As a result, the implementation was very fragile and only worked
on FieldChar but not FieldText.
This commit fixes the issue by turning the FieldPassword a field
widget. As a result, the enabling of the password meter next to
a password input has changed:
Before this commit:
```
<field name="new_passwd" password="True" options="{'password_meter': True}"/>
```
With this commit:
```
<field name="new_passwd" password="True" widget="password_meter"/>
```
Closes#27440closesodoo/odoo#27586
When auth_password_policy is installed, and a field with
`password="True"` is in a res.config.settings (eg. google calendar is
installed) we could have an error caused by deferred not expected in the
res.config.settings _render.
Since the RPC is only needed when the password_policy has been been
defined, this commit do this removing the error that currently happened.
A customization of res.config.settings adding password_meter would still
break settings (but it is currently not done) and will be solved in a
future fix.
closes#27426
* generic strenght meter widget which can be included in various
places
* password field, taking over the isPassword special cases strewn
throughout the codebase, this should probably become an actual thing
in core /cc @ged-odoo, the meter is opt-in as most uses of
`field[@password=True]` are passwords & secrets for third-party
services or external servers for which a meter would not make sense
* separate override of the ChangePassword wizard which isn't a regular
view for some reason
* direct implementation for signup pages (create user & reset password)
Skip/comment/remove existing testing of @password fields: the policy
replacement/augmentation needs to make an RPC call and does not
support readonly use (because it doesn't seem to be used anywhere so
that made sense?); and there currently is no way to augment or
override/replace existing tests, so the tests will either fail when
auth_password_policy is installed (current situation) or fail when
auth_password_policy is not installed (if updated to be compatible
with APP).
Jorge Pinna Puissant