Authentication modules are supposed to override res_users.check_credentials()
in order to plug in their own mechanism, without actually modifying the
behavior of res_users.check(), res_users.authenticate() or
res_users._login().
auth_openid was incorrectly overriding check() instead of
check_credentials(), and unnecessarily accessing private
attributes of res_users. Fixing the implementation of auth_openid
to follow the API means we can completely make those attributes
private.
Since revs 53582c2ea6 & f65c913027,
this was no more possible for portal users to read groups
on purpose, for privacy reasons.
fields_get of res.users model is overriden, for
the access rights form view features
(The groups selections and checkboxes).
At each call to fields_get, which happens at each call
to fields_view_get on the res.users model, operations are
done on the model res.groups (basically, to
build the selection groups and checkboxes). So,
each time a view of model res.users is displayed,
whatever the view, operations on res.group model were performed.
The thing is, these operations on res.groups
are actually needed only for the user access rights
view, or at least only for users having the group
Administration > Access rights. These group operations
aren't needed for the preferences view, nor for portal users.
We therefore avoid to do these if the user is not part of the
Administration > Access rights group, which lead to
performances improvment, and solves the fact
portal users couldn't access their user preferences view.
opw-627391
[IMP] base: safer locking at user login
When a users connects, a lock is taken on the res_user table to modify the last login date. If another running transaction uses a foreign key to res.users (e.g. write_uid column), postgres may detect the update as a concurrent update and rollback the transaction.
In pg 9.3, the lock_strength parameter 'NO KEY' allows a weaker lock which is less likely to break another transaction.
Fixes#552
This config parameter is automatically updated when the admin log-in.
As this value is mean to be used in emails and links given to users, we sometime don't want
it to be updated inconditionnaly. In some cases, the admin may use alternative, private or
even local uri to connect to the server, which may not be suitable for users
bzr revid: chs@openerp.com-20130301095551-fzrlwblnawxqj9di
Discarding the cache completely is suboptimal but
makes the code simpler, and this is not performance
critical anyway. The cache is mostly useful during
module installation, which involves no call to clear_cache.
bzr revid: odo@openerp.com-20121219101315-1ccuwm6nvmov12zv
When _() fails to find a context lang it looks
up the user language by calling context_get().
During module installation this may happen
thousands of times, and drastically slow down
the installation. Caching context_get calls
is an effective way to work around this,
until we find a better solution.
bzr revid: odo@openerp.com-20121217214700-6r7ju8iiaeowgj8i
The case where no constraint existed at all was not working,
and after fixing it, the ORM started to re-create the same
constraints multiple times for some modules. This was for
models that are split within a module (such as res.users in
base, which is made of several small classes): all the
partial models were going through _auto_init instead
of only the final one - doing useless extra work.
Unfortunately establishing the FK happens before the
XML data files are loaded, so a number of FK and
NOT NULL constraints failed to apply due to missing
tables/records. base.sql had to be extended a bit
to cover these cases in a minimalist fashion
bzr revid: odo@openerp.com-20121217214645-av9n003yzterhujw
Paul Catinean
Olivier Dony
Denis Ledoux
Martin Trigaux
Sandy Carter
Richard Mathot (OpenERP)
Denis Ledoux
Xavier ALT
Cecile Tonglet
Rifakat
Jigar Amin (OpenERP)
Cedric Snauwaert
Christophe Simonis
Raphael Collet
Vo Minh Thu
Fabien Meghazi
Antony Lesuisse
Thibault Delavallée
niv-openerp
Fabien Pinckaers
Bharat Devnani (OpenERP)
Pinakin Nayi (OpenERP)
Nimesh (Open ERP)