Security in ODOO : Users, groups, access rights, record rules.
Security in ODOO
Users and user roles are critical points concerning internal security in ODOO. ODOO provides several security mechanisms concerning user roles, all implemented in the ODOO Server. They are implemented in the lowest server level, which is the ORM engine. ODOO distinguishes three different concepts:
user: a person identified by its login and password. Note that all employees of a company are not necessarily odoo users, the user is somebody who accesses the application.
group: a group of users that has some access rights. A group gives its access rights to the users that belong to the group. Ex: Sales Manager, Advisor, etc.
security rule: a rule that defines the access rights a given group grants to its users. Security rules are attached to a given resource, for example the Invoice model.
Security rules are attached to groups. Users are assigned to several groups. This gives users the rights that are attached to their groups. Therefore controlling user roles is done by managing user groups and adding or modifying security rules attached to those groups.
Users represent physical persons using OpenERP. They are identified with a login and a password,they use Odoo, they can edit their own preferences, ... By default, a user has no access rights. The more we assign groups to the user, the more he or she gets rights to perform some actions. A user may belong to one or several groups.
The groups determine the access rights to the different resources. A user may belong to several groups. If he belongs to several groups, we always use the group with the highest rights for a selected resource. A group can inherit all the rights from another group
Security rules are attached to groups. You can assign several security rules at the group level, each rule being of one of the following types :
access rights are global rights on an object,
record rules are records access filters,
fields access right,
You can also define rules that are global, i.e. they are applied to all users, indiscriminately of the groups they belong to. For example, the multi-company rules are global; a user can only see invoices of the companies he or she belongs to. Concerning configuration, it is difficult to have default generic configurations that suit all applications. Therefore, like SAP, Odoo is by default pre-configured with best-practices.
Access rights are rules that define the access a user can have on a particular object . Those global rights are defined per document type or model. Rights follow the CRUD model: create, read (search), update (write), delete. For example, you can define rules on invoice creation. By default, adding a right to an object gives the right to all records of that specific object.
When accessing an object, records are filtered based on record rules. Record rules or access filters are therefore filters that limits records of an object a group can access. A record rule is a condition that each record must satisfy to be created, read, updated (written) or deleted. Records that do not meet the constraints are filtered. For example, you can create a rule to limit a group in such a way that users of that group will see business opportunities in which he or she is flagged as the salesman. The rule can be salesman = connected_user. With that rule, only records respecting the rule will be displayed.
Field access rights
Odoo supports real access control at the field level too, not just on the view side. Previously it was already possible to set a groups attribute on a <field> element (or in fact most view elements), but with cosmetics effects only: the element was made invisible on the client side, while still perfectly available for read/write access at the RPC level.
code = fields.Char(string='E-commerce Promotional Code', groups="base.group_user")
There is a major difference with the view-level groups attribute: restricting the access at the model level really means that the field will be completely unavailable for users who do not belong to the authorized groups:
Restricted fields will be completely removed from all related views, not just hidden. This is important to keep in mind because it means the field value will not be available at all on the client side, and thus unavailable e.g. for on_change calls.
Restricted fields will not be returned as part of a call to fields_get() or fields_view_get() This is in order to avoid them appearing in the list of fields available for advanced search filters, for example. This does not prevent getting the list of a model’s fields by querying ir.model.fields directly, which is fine.
Any attempt to read or write directly the value of the restricted fields will result in an AccessError exception.
As a consequence of the previous item, restricted fields will not be available for use within search filters (domains) or anything that would require read or write access.
It is quite possible to set groups attributes for the same field both at the model and view level, even with different values. Both will carry their effect, with the model-level restriction taking precedence and removing the field completely in case of restriction.
Warning At the time of writing the implementation of this feature is partial and does not yet restrict read/write RPC access to the field. The corresponding test is written already but currently disabled.
In Odoo, granting access to menus can be done using user groups. A menu that is not granted to any group is accessible to every user. It is possible in the administration panel to define the groups that can access a given menu. However, one should note that using groups to hide or give access to menus is more within the field of ergonomics or usability than within the field of security. It is a best practice putting rules on documents instead of putting groups on menu. For example, hiding invoices can be done by modifying the record rule on the invoice object, and it is more efficient and safer than hiding menus related to invoices.
Customizing views based on groups is possible in Odoo. You can put rules to display some fields based on group rules. However, as with menu accesses customization, this option should not be considered for security concerns. This way of customizing views belongs more to usability.
When installing your particular instance of Odoo, a specific first two users are installed by default. In odoov12 this first user is the Super User(Odoobot) and second user is Administrator. The SuperUser does not have any access restriction. While admin user is just like other system user and hence Administrator have restriction based on the record rule defined. For both user by default added access rights to every existing group, as well as to every group created during a new module installation. They also have access to a specific administration interface accessible via the administration menu, allowing the administration of Odoo. The administrator has rights to manage groups; he can add, create, modify or remove groups. He may also modify links between users and groups, such as adding or removing users. He also manages access rights. With those privileges, the administrator can therefore precisely define security accesses of every user of Odoo. There are user groups that are between normal groups and the super user. Those groups are Administration / Settings and Administration / Access Rights. It gives to the users of those groups the necessary rights to configure access rights.
Wonderful goods from you, man. I've consider your stuff previous to and you are just extremely wonderful. I actually like what you've obtained right here, certainly like what you are saying and the best way wherein you assert it. You are making it entertaining and you still take care of to stay it wise. I can not wait to read far more from you. This is really a tremendous web site.| tips for healthy http://healthpointer.eu