Odoo User Access through Role Policy: a Game Changer
Location: Track 1 - 10/28/21, 4:35 PM - 10/28/21, 5:05 PM (+0200) (30 minutes)

Els Van Vossel, Richard Varghese and Luc De Meyer els.vanvossel@noviat.com, luc.demeyer@noviat.com, r.varghese@canna.com +32494705632


Company team

Els Van Vossel

Els Van Vossel is a senior Odoo Consultant and has been working with Odoo software since 2008. In 2010 she was Training Program Manager for OpenERP SA. As such, she wrote a couple of books and documentation about Odoo Accounting, Logistics, Manufacturing, CRM and Marketing. Currently, Els is working in various large Odoo projects (finance, access rights, project & service management, logistics, manufacturing, HR, …). 


Company team

Luc De Meyer

Senior Odoo Architect and Director of Noviat, Belgium

Company team

Richard Varghese

Corporate IT Head of CANNA, Netherlands

Richard is responsible for end to end IT Services and the Open Source IT landscape for the group with a keen focus on Canna's Odoo implementations. In the past he has served in a similar capacity for Coca-Cola and comes with 18 years of industry experience in IT management for the sectors such as FMCG, Manufacturing, retail & wholesale operations.

Security in Odoo works in a sense that on installation of an app, every user has almost full access and sees all corresponding menu items. This approach is changed by the Role Policy app: a user only has the access rights that have explicitly been granted.

On installation, all security groups are removed from users, actions, menu items and views. The admin, of course, keeps all access. The role policy app allows you to create roles through the Odoo UI or in a spreadsheet. Roles can easily be imported and exported, you can even delete lines through the import of a role. As soon as a role has been configured, export it and adapt it to start defining your new role. Menu items can be specified per role, allowing you to indicate for instance that a user only has access to Sales Invoices, but not to Supplier invoices. View modifier rules allow you to set fields required / invisible / removed / read-only per role. You can also hide a complete view.

Suppose you have a role which needs to create customers, but does not necessarily know the VAT number. Create a role which does not have the VAT number as a mandatory field, and create a second role which will validate the customer data, and while doing so, will see the VAT number as a required field. A sales user should be able to post sales invoices, but is not allowed to create other account moves on the spot? No problem with the Role Policy App; view type attributes such as create, edit, delete, duplicate, import, export_xlsx become role-based!

Model methods can be created by developers and allow you to define per role who is allowed to post entries, for instance. You only want certain roles to be able to print a sales order? Simply add a reporting action Sales Quotation / Order to the roles allowed to print it. A role who is not assigned to a reporting action will not be able to print reports. You can also use xpath expressions for more complex rules.