The ERP managers (users with 'Access Rights' rights) cannot even click on the Settings app menuitem. Because of 2 things: - The Dashboard settings is accessing the model ir_module_module. So we set a groups 'group_settings' on it. - The Users view is accessing the model ir_module_category to groups the aggregate and display the settings. So we change the security rules by giving the access to the group_erp_manager instead of group_settings - The global rules opn companies was applied to the erp managers. We splitted this ir.rules into three new ones on portal,public and employee users to allow the erp managers to access the companies - Writing on the res_groups was calling the method _update_user_groups_view in all the cases. This method should be called only when the view was needed to be modified, i.e. when the category_id is modified for this group.
A translation of a field value for a given record can only be created/updated/ deleted if the current user has access rights for updating the record. Access rights on translations are restricted to the group "Employee". Those still need create/write/delete access, in order to be able to edit records in the user interface. Other users (portal, etc.) simply have no explicit access rights at all on translations.
Writing frequently to master data, and particularly to res.users records is dangerous because it can temporarily delay/abort concurrent transactions due to FK locking/serializability heuristics. (Even with PostgreSQL 9.3+) The `login_date` field updated when a user is authentiocated is still useful but better handled in a separate table that exclusively receives independent INSERTs (no UPDATE/DELETE). This minimizes the chances of transactional conflicts. This commit moves the login_date info into a separate `res.users.log` table for this purpose, replacing it with a related field. The user and login date info are automatically handled by the magical fields (create_uid, create_date) in `res.users.log`. The related field must not be stored because that would create the same problems as the original field. In order to cleanup redundant entries in res.users.log the 'auto-vacuum' cron job used for TransientModels was extended to be a generic "internal data vacuum cleaner", and now takes care of this as well. The code for updating last login and vacuuming was split up into smaller methods to make extensions easier. Fixes #8585 Fixes #8590
* listing of modules in website already bypassed session user * altered authenticated endpoint so it does the same * sudoed a few read accesses & name_get in groups * other accesses are list/form views, menu only accessible to system_user * new-API-ified some calls & unified listing of installed modules
Should not be necessary for the correct working of odoo (normal cron lookup & processing is performed using raw SQL anyway). * fixed a few ref calls just in case * also cleaned up a few unused imports
This is only a model in case third parties need to override stuff, it has no field and no reason to be a "concrete" model. Also * remove corresponding access rule giving CRUD to every user * remove unnecessary import * replace set() call by set literal * replace dict(generator_expr) by dict comprehensions
Legacy model, doesn't seem to be used anywhere or have any point at all yet was accessible CRUD to all...
Multi_company.default was used to set the default company on newly created records in a multi-company environment. We remove it because it is redundant with User-Defined Default. The function _company_default_get is left for backward compatibility and to allow the creation of modules that implement more complex policies.