Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
And make configurable via an ICP. Provide a reasonable default value,
and use it as a lower bound so user error can't lead to an insecure /
unsustainable amount of hashing.
Aside from being somewhat overdue on account of age (passlib's current
default were last updated 6 years ago), this is also made much more
feasible by API keys, meaning non-interactive use (RPC) is less
strained by the (interactive) password hashing.
Also modernize passlib usage:
* Remove global `DEFAULT_CRYPT_CONTEXT`, create inline (as overhead
should not be too huge given what we're doing with it), and
`ormcache()` for safety, the caches should be invalidated on any ICP
addition, removal, or update, so user update to the rounds
configuration should get reflected immediately.
* Switch on `deprecated=["auto"]`, feature was added in 1.6 and we now
depend on 1.7.
* Remove mentions of `encrypt`, it is deprecated in 1.7.
closesodoo/odoo#81498
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Without this index, finding the user(s) of a partner makes a seq scan, which
could take up to 100ms on my machine with only few thousand users. By adding the
index, the time is reduced to around 5ms.
Part of task-2702450
closesodoo/odoo#81176
X-original-commit: 372f1c5ebac4b9b542994ea5aaad59abe7290918
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
Purpose
=======
In the `res.users` view, we can add / remove a group of a user with a
simple selection / boolean field.
This trick is done with an override of "fields_get" to return fields
that don't exist, and override the create / write to write on the
"groups_id" when we write on those "virtual fields". So with this trick
we can create new fields in the `res.users` view by just adding a new
group.
So when you write on the virtual fields, it will add / remove a group.
But this implementation will not trigger the on-change of "groups_id"
(because those field do not exist).
With this commit, the "onchange" of `groups_id` field will be triggered
when you write on those virtual fields (and so the computed method
which depends on `groups_id`, e.g. the `share` field).
Task-2508521
Part-of: odoo/odoo#77766
This is a followup on b6c688caa2, which
has introduced a new bug.
Consider two groups A and B in a given category, where B implies A and
also A.id > B.id. For the sake of simplicity, assume that A.id=2 and
B.id=1. Following the commit above, the name of the group selection
field will be 'sel_groups_1_2'.
Consider a user in group B. Because B implies A, this means that the
user now belongs to both A and B. A call to read() on that user returns
field 'sel_groups_1_2' with value 2, which on the form view appears as
the user belonging to A only.
The error is in read(), which assumes that the group ids in the field
name correspond to the implication order of the groups, which is no
longer the case since b6c688caa2.
closesodoo/odoo#78662
X-original-commit: e73c406671a51e9c1c4872a9e85eebe5656ea38e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
+ Added the 'Trusted Devices' feature
+ Added 'Remember this Device' checkbox on /web/login/totp
+ Added trusted device's OS / browser on Profile > Account Security
Added '2FA Trusted Devices' feature to allow users to remember their
device to bypass the 2FA for the next connections. The trusted devices
are displayed in a 'Trusted Devices' One2Many under the 'Developer API
Keys'. It is possible to revoke all the trusted devices at once with a
special button. It is also possible to revoke one at a time on the
desired one.
Task-id 2523092
closesodoo/odoo#75535
Related: odoo/upgrade#2800
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
Refactor the Environments object into a Transaction object, which is
bound to one cursor, and is no longer shared among several cursors.
The following methods/properties have been changed:
- Environment.envs no longer works (because of the design change);
- Environment.manage() is deprecated (no longer useful);
- Environment.reset() is now an instance method;
- env.clear_upon_failure() is deprecated in favor of cr.savepoint().
closesodoo/odoo#75598
Related: odoo/enterprise#20451
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Xavier Dollé <xdo@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
Description of the issue/feature this PR addresses:
It is currently quite difficult to differentiate users. Most of the time, people
don't take the time to upload an actual avatar so everybody looks the same. This
PR generates a custom avatar with the users initials and random color to
differentiate them. For res.users, res.partner and hr.employee, image fields now
hold the binary image and avatar are used to show the image or svg.
Current behavior before PR:
Avatar had only random colors and was being saved in database, being inefficient
Desired behavior after PR is merged:
A new mixin defines image fields and in case no image is set, it generates an
SVG image with the user's initials and random color.
closesodoo/odoo#69819
Task: 2404630
Related: odoo/enterprise#18199
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
Magic and inherited fields are not really useful on abstract models.
The _inherits specification is used anyway by models that inherit from
those abstract models.
The main goal of this change is to prepare a refactoring of models where
fields are no longer duplicated on the registry classes, but fields
defined on classes are used directly. But this new design cannot be
applied to all fields: a field being overridden simply cannot be used
directly. This branch improves the situation by avoiding unnecessary
field overridings.
closesodoo/odoo#69372
Related: odoo/upgrade#2409
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* Add a new error message upon deleting the partner linked
to an active user.
* Improve the error message wording upon archiving the partner
linked to an active user. Add the linked users names at the end of
the message.
* If the user has 'write' access on res.users, raise a RedirectWarning
instead of a ValidationError, to offer an easy access to the related users :
- If there are multiple Users, redirect to a list view.
- If there is only one User, redirect to the form view.
* Adapt the test_access_deleted_records from test_orm.py to use a more
basic model : `res.partner.category` (with less business logic), because the
new unlink error message is dependent on a condition that will throw an error
in case of multiple unlinks of the same record (MissingError).
* Force close the frontend archive confirmation Dialog since _toggleArchiveState
may be interrupted by another Warning/Error Dialog. If the new Dialog was the
redirectWarning, and the user chose to be redirected, the first Dialog would
stay open even thought the context already changed.
* Modify the placeholders for a partner Name/Company
-> placeholders will change according to an Individual or a Company.
* Adapt the main_flow tour to correctly select the partner name field on
mobile (tested in enterprise).
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
Display names of user, company_id and company_ids in order to better
understand what is failing. Otherwise a generic message does not really
help understanding the actual issue.
Add translation of new constraint. Also add translations of new modules
added recently.
LINKS
Task ID-2421795
COM PR odoo/odoo#63677
X-original-commit: 15d47bec4a6316dd6a873973572273c913801330
To reproduce this issue, install the module "Accounting" in English,
then switch language to Dutch, and go to a user's form. The selection
field for accounting groups is missing from the users' form view.
The source of the bug is the special case introduced for accounting
groups in d8c5cc1335. The groups in that
selection field are not totally ordered, and the non-ordered elements
are de facto ordered by name, which is a translated field! In the
example above, the English version uses the field name
`sel_groups_22_23_24_25` while the Dutch version uses the field name
`sel_groups_23_22_24_25`. Because the first one is used in the form
view, and it is not found in the model's documented fields (which uses
the second one), the field is discarded from the view.
The patch is much simpler than former versions, which are constrained by
the stable branch policy. We simply normalize the selection field's
name by ordering the group ids used in the name.
OPW-2394209
closesodoo/odoo#63462
X-original-commit: 399b4f1ceb31f560ce534ee8d9605ca43733f68c
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Nasreddin (bon) <bon@odoo.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
Before this change, the apikeys' ``_check_credentials`` override would
hard-check the ``'interactive'`` key. This turns out to be less than
ideal for compatibility with older code which might not properly
forward the environment (or might call ``_check_credentials`` from a
non-override and pass in an empty env) as it straight crashes.
Update the override to assume an interactive login if the information
is missing (as that seems like the more secure option: it ignores
apikeys and takes 2FA in account if enabled). Also trigger a warning
if the key was missing from the environment, such that the maintainer
hopefully takes a look at the issue.
Also allow a ``user_agent_env`` of ``None``, this will also trigger
the warning so seems OK.
closesodoo/odoo#62683
X-original-commit: ee2625a9311f308b9df3fc160dc5c9fe4cc5a497
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* override `onchange` in res.users in order to properly generate and
send the reified group fields alongside the rest: while default_get
sets them up, those fields then get stripped by the onchange
machinery as they don't actually exist on the model
* add a test to check for it
* fix SSF in relation with the new default/onchange system
- because fields may not actually exist on the record,
`record_to_values` needs to `read` the record data rather than
directly access the recordset: the recordset likely will not
know about fake fields
- after the initial onchange has run the form must be filled with
falsy values in case the onchange has not sent defaults for
everything
- on creation, all fields in the form should be considered modified
Task 2341153
closesodoo/odoo#58152
X-original-commit: f8658f229180a595d69cd6daefeded082c7f64ea
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
* allows portal users to update their password
* and manage their API keys
* any anything technical / security related we may need to add in the
future
Also bridge module for the password meter (auth password policy).
* 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>
Before this, invalidations to the UID cache is not synchronised
between workers because it's an ad-hoc solution (so a user changing
their password or an admin disabling a user would only lock out an
attacker currently using the API of one of possibly several
workers). Shift the entire thing to ormcache which already has proper
support for synchronising cache invalidation between workers.
Also simplify the cache invalidation mess in Users.write because the
caches have been unified into a single registry-level LRU, so the
half-dozen cache clears on specific ormcached methods & models is
pretty much the same as repeatedly calling clear_caches on the current
model.
**However** registry.cache is trivially accessible from server actions
and safe_eval as long as they provide access to a model (through
`model.pool.cache`). Which is common, and an issue given we're very
much putting sensible data in there.
Fix this by renaming `Registry.cache` to `Registry.__cache`, this
requires few editions and mangled names are not accessible from
safe_eval contexts.
The alternative would have been to add more bespoke handling of the
uid cache to hook it into the cache invalidation propagation
machinery.
After discussion with (@)odony, fixing LRU access and using that seems
cleaner and less error-prone.
Note on lazy_property
=====================
Make Registry.cache / Registry.__cache into a regular attribute: the
overhead of the LRU is not that high (compared to that of the registry
itself), it's rare that we *don't* need it, and it's assumed to be a
persisted attribute (it's not just a cache) so making it a normal
attribute seems fine; and lazy_property doesn't work for mangled
names: the name of the property is mangled using the name of the
definition class, but the name of the symbol (fget) is not mangled so
lazy_property would set the __cache attribute but then Python would
lookup _Registry__cache, creating a new cache every access.
And we can't (always) mangle things correctly on `__get__(obj,
owner)`: `owner` is just `type(obj)`, meaning in the case of
inheritance the type we get is the type through which the property is
accessed rather than the one it's defined on. So it would work in the
cases where no inheritance is involved (such as Registry.__cache) but
not in general (lest we want to play around walking the MRO ourselves
to find the definition source, which doesn't seem worth it).
lazy_property *could* be made to work properly on Python 3.6+: the
descriptor protocol gains `__set_name__(name, owner)`, which is called
with the properly mangled name — and with the definition class to boot
(though there might still be issues when overriding lazy properties as
the override will be mangled & named differently... or maybe that's a
feature?). However we're still supporting 3.5 at this point, AFAIK, so
that's not an option. Plus it feels unnecessary / not very useful.
However add an assertion to `lazy_property` so it signals when we try
to use it on a mangled method (as otherwise it kinda sorta work in the
sense that the property / object is accessible but is in effect a
slower way to write a regular property).
Similar to github's sudo mode, my understanding of the intent is to
avoid third parties being able to perform sensitive / serious
operations when leaving a logged-in machine unattended.
This v1 only handles protecting "action methods" (methods called
through buttons and intended to return action descriptors), although
they can be used to "lock out" any methods they won't be able to
prompt and the caller will likely be surprised.
Allows accessing various keys, especially whether this is an
interactive login or not.
Also have the xml-rpc `login` delegate to `authenticate` instead of
having its own half-assed implementation.
And remove some dead code: as far as I can tell, Session.authenticate
is never called with a uid.
With this commit, the timezone (in the user's preferences) is
automatically set to the timezone of its browser the first time
this user logs in.
Task 2207715
closesodoo/odoo#55726
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
The ir.autovacuum model purpose is to run several garbage collecting
operations like removing files from the filestore when no attachment
references them anymore.
The precedent strategy to register new garbage collection tasks was to
override the `power_on` method and to imperatively execute a vacuum
cleaning method on a given model. All calls were executed in a single
SQL transaction without any error handling, meaning a single fail during
any call resulted in a complete failure of the entire vacuum cleaning
chain.
We introduce a new `@autovacuum` api decorator, its purpose it to
register garbage collecting methods that will be safely executed in
their own transaction by the vacuum cleaner. In order to ensure this
new strategy is used, we deprecate `power_on` extensions.
By the way, garbage-collecting methods can be quite heavy and we don't
want users to directly call them. We now ensure they are private.
closesodoo/odoo#47842
Task: 2154079
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Olivier Dony <odo@odoo.com>
ref() always trigger a database query to verify record still exists.
In frequently used methods, it's best to avoid ref calls if not needed:
* either the records should always exist
* either the record isn't always needed and the ref can be sometimes
avoided.
X-original-commit: c1e05da7b71c8274aff00d67f8d1bc7e209fcaab
Followup fix of #48912
The multi-company group should be given to users if they have access to
multiple companies and do not already have this group.
closesodoo/odoo#50233
X-original-commit: 0c721d90c5cd428ef8d51f195da8e02ee91d4364
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Instead of triggering one has_group by user (one sql query/user if not already ormcached),
and potentially filling the `has_group` cache with new users data (we don't know if and when this data
will be used anyway), compute this field from the groups information already in cache.
X-original-commit: d771d7e9c8503543d29fdbf2ab961c2a32cc3bac
Improve the performance of the default method for user groups by avoiding a `ref` call,
using the group in cache instead.
Calls to ref always trigger one SQL query to verify record still exists
This means that creating 10k user would trigger 10k queries only for the default.
X-original-commit: e67efb88338ef669059591728e7722fe1dff4bf0
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
Set a default email signature to an empty string to avoid `False` when
evaluating `${user.signature | safe}` in email templates.
opw-2229846
closesodoo/odoo#49558
X-original-commit: 96f46fba2635d8050aef03c7d4744a87ac8a597e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
While installing a module on an existing database, the modification of
groups should reset the `base.user_groups_view` to a dummy view in order
to validate user views. The `user_groups_view` is set to its "right"
value at the end of the installation.
closesodoo/odoo#49114
X-original-commit: 071bd77944484bad6f2c0cb9a7a98785dcc693c6
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When a user is created, its partner_id shall not have any company_id.
A test has been added to check that in 'base/test'.
Update test_mail tests by setting a company to partner_id linked to users
as now, by default the partner linked to a new user has no company_id.
closes odoo/odoo#46515
Task: 2198688
Forward-port-of: #45900
X-original-commit: 187b12fc5715721efdd9af283e086dfc3f856fc2
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Xavier Morel