ir.rule are default values but can be customized based on the company's policy and needs. This is typically a record that is in noupdate as should be customization-friendly.
Managers could see only their sessions like other operators. Now they can see all the sessions so they can check and help the operators. task-2048498 closes odoo/odoo#41175 X-original-commit: 6ae791335a1986aa4cc72f7ed9aadd471c1774c5 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose ======= Access group terminology is missleading. Yous have to be manager to administrate an application. This task consists to rename groups to be understandable for everyone. Groups should be reorganised on the users form to be more explicit. Specification ============= 1/ Rename 'Manager' to 'Administrator' in users groups. 2/ Define a hierarchy on access groups by using the category_id in the manifests A category 'Operations/Project' will create a category Project with a parent category 'Operations', and something smart is already developed (in modules/db.py) to avoid duplicating categories. 3/ Add a group in expenses to be able to approve expenses reports for my team. 4/ Add a group in timesheets to be able to approve timesheets for my team. 5/ Remove partially the useless crap in ir_module_category_data.xml 6/ Sort access rights groups on users form according to its parent category closes odoo/odoo#29362 Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
Purpose is to ease understanding of applications / categories and their links with the access rights labelling. This commit is related to task 1884968 and PR #29176.
User 1 simply becomes a technical user (inactive, no password).
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights when created from the dashboard, which was leading to an error. This bug leaded to a new discussion. Better to have basic employee having user rights for all main applications. For bigger entreprises there is an admin that will carefully remove extra rights, if necessary. The target is small businesses, it makes sense that every way to create a user gives the same result. In conclusion, each new user has a full access to the applications by default How is it implemented ? We added an inactive default user which original access right to the groups 'base.group_user' and 'base.group_partner_manager' in base. Each application will extend the default user's access right by adding the maximal access right for this application. On user creation, we will use by default the 'group_id' field from the default user. We will in the same time remove the ugly 'default_groups_ref' key which was passed sometimes in the context for some fields in some views, and sometimes nothing. So, the user can modify the access rights for the default user, but he should be aware that removing project user access rights for a default user will prevent a *created on the fly in a task* user will not be able to access the task.
These two rules were used to restrict livechat users to the read access to their own messages, and allow livechat managers to see all messages. Since 9.0, livechat messages are no longer `im.chat.message` records (8.0), they are now `mail.message` records, and this model already implements its own security rules. See `check_access_rule` of `mail.message` to know more about the access rules of this model. Therefore, these security rules are no longer necessary in 9.0. Besides, it had as side-effect to restrict the access of livechat managers for `mail.message` records. For instance, livechat users were no longer able to create customers. opw-651958
* There is no `mail` field on model `mail.message` * There is no `mail.channel_ids` field on model `mail.channel` opw-650656