One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
Overriding method has_group() in some extension of model 'res.users' is
not possible because of code invoking model.has_group.clear_cache().
As clear_cache() is no longer invoked on ormcached methods, we can
simply replace the code by a global cache invalidation. In this case,
it is not even necessary, since method call_cache_clearing_methods()
does it already.
closesodoo/odoo#95071
X-original-commit: 2dc80fe49ec2cb11e65465d4616b9bbb136bf6ab
Signed-off-by: Raphael Collet <rco@odoo.com>
Commit c3717f3018 added a (5, 0, 0) command when modifying groups_id of any
non-internal user, to avoid the situation where the various implications would
end up giving the portal user group_user rights.
This risk is avoided by commit f206714af0, which added a constraint
check_one_user_type, which would raise in that specific case.
The last missing piece was 9badedcd98f; when groups are added through settings,
they are added through the implied_groups of the group model.
The (5,) command has the unfortunate side-effect to remove the portal group
from a user if a write is triggered programmatically.
If that happens, then the 'signing up' process end-destination is a 500 error.
Now we simplify the logic that keeping the same behaviour for implied_ids for
internal (group_user) and non-internal users.
We keep the (5,) command in one case: if a user is demoted to portal or public,
he may have groups should be reserved to internal users, but that do not imply
group_user (which would raise).
To avoid that, we remove all its groups, since there is no clear distinction
between technical display groups and actual privilege-granting groups.
opw 2041606
closesodoo/odoo#37144
X-original-commit: 29723e351d5dc5e5ea055c80da86f4e871909de9
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Since commit 5f12e244f6, the write of implied groups is done directly in SQL,
bypassing the ORM writes, and thus bypassing the python constraints checks.
In particular such a constraint was added in f206714af0.
We add back an explicit check of this constraint;
however we rewrite it in SQL to be fast.
closesodoo/odoo#35411closesodoo/odoo#36769
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When creating a portal user from the User & Companies menu in the
Settings.
Before this commit, the created user had both groups' portal user and
internal user, which generated an error in the display of the user
accesses and rights. This also occurred if we manually add a portal
user to the internal user group.
Now, when creating a portal user, the user only has this group. Also,
if we manually add a portal user to the internal user group, an error
is raised to inform that only one user type is allowed.
OPW-1929367
closesodoo/odoo#30958
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
Create new methods on `BaseModel` to create records with given xml ids in
batch. Those methods replace the methods `_update` and `_update_dummy` of
model 'ir.model.data', which are now deprecated.
Adapt XML and CSV import code to create records in batch.
Xavier-Do