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
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>
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>
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>
* ability for a user to request / create keys associated to their user
* overrides can block RPC solely through API keys, by overriding
`_rpc_api_keys_only()` (to require API auth even in
situations where the user has not requested it themselves)
* hash keys just in case as we can do so and might as well, add a
cleartext index (first 4 bytes of 20) to avoid blowing up the DB if
a user decides to create millions of keys for some daft reason
* users can delete their own keys, admins can delete (invalidate)
anyone's keys
* `scope` on API keys can be used to restrict usage to certain
kind of applications, so API keys can be used for other things
than global authentication. New keys manually created by users
have no scope by default so they are valid everywhere (global
keys). RPC auth (stateless XML-RPC/JSON-RPC) requires global keys
Co-authored-by: Florimond Husquinet <fhu@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
David Beguin