If you let users change their passwords for themselves, you will have no direct control over the password they choose. You should have a written policy about password strength to try to maintain a level of security in your system.
Managing Users through LDAP
With the users_ldap module, user accounts can be managed through an LDAP directory that can be made common to various different company resources.
Connection parameters for the LDAP directory are then registered with the company definition. You can provide a user profile template there from which new users are automatically created during their first connection to OpenERP.
The LDAP protocol (Lightweight Directory Access Protocol) enables you to manage common directories for various different resources through your standard TCP/IP network.
This enables users in the company to have the same username and password to access all their applications (such as email and intranet).
Managing Access Rights¶
One of the most important areas in configuring OpenERP is how to manage access rights to the information in it.
You are planning to put everything significant to your business into the system, but most of your staff need see only part of it, and may need to change even less of it. Who should have rights to what, and how do you manage that?
OpenERP’s approach to rights management is highly flexible. Each user can belong to one or more groups, and the group(s) you belong to determine(s):
- the visibility of each menu item and
- the accessibility of each table in the database.
For example, the group Warehouse / User may only be given access to some of the menus in Warehouse, and may have no access to any of the accounting information. Each system user who works in stores is given membership of the Warehouse / User group. If some users also work elsewhere, they would also be given membership of other groups.
Groups and Users¶
To configure access rights, you would start by defining the groups. It is important for the groups to be representative of your company’s job functions rather than of its individual employees.
So if your finance director is also your sales director, you should create both a Finance Director group and a Sales Director group, even though they are both the same person, and would both be assigned to this user in practice. This gives you flexibility for the future.
You should also create groups within departmental areas that have different levels of access rights. For example, if you create a Sales Director group and a Sales group avoid assigning exactly the same rights to each group. The first could see all the of reports, while the second could be restricted to seeing quotations. You could either make the Sales Director a member of both groups, and give the Sales Director group a limited set of extra rights, or give the Sales Director group all the rights it needs for a Sales Director to belong only to this one group. You should choose the scheme that gives you most flexibility and then stick with it to maintain consistency.
Flexibility in Managing Access
To give yourself flexibility, you can ensure that a trusted staff member (perhaps a director or someone in accounts, or even the system administrator) is given wide rights to use the system, and is authorized by the management to carry out specific tasks for people.
Access Rights to Objects¶
The menu access rights determine who can access which menu, but does not define what you can do once you are in the menu.
Access controls on the objects give you the possibility of defining what your users have the right to do with your data when they get access to it. Access control of objects is structured the same way as access to menus.
An object represents a document in the system. Objects are linked to database tables, and also have additional concepts, such as the functions of fields, inheritance from other objects, and class methods that give them behavior.
If no group is assigned to an object, all users can access it without any restriction of any sort. Conversely, when an access control is defined for an object, a user must be a member of a group owning appropriate access rights to have any sort of access to that object.
You must always ensure that you do not lock the Administration / Access Rights group out of any object that controls administration and configuration options, such as the ir.model.access model.
You can manage four access modes on objects independently:
- Read access : members of the group can read the data in the object,
- Create access : members of the group can create a new record in the object,
- Write access : members of the group can modify the contents of records in the object,
- Delete access : members of the group can delete records from the object.
To configure access rights on an OpenERP object, use the menu Administration ‣ Security ‣ Access Controls List and click New or choose an existing one and click Edit. You give a Name to the access control, select a Group, and the Object, then check the checkbox corresponding to each of the four Access modes.
If you do not specify any group in the access rules, the rule is applied to all groups. So to remove access to an object for all users you could create a rule:
- which is defined for a specific object,
- which is linked to no group,
- for which none of the four access options is checked.
You can then create additional rules on the same object to give specific rights to certain groups.
Record Rules For Objects¶
Record rules determine who can access the objects, depending on the rules set for the particular object. A record rule has some tests to be performed on objects.
You can manage four access modes on objects independently, depending on the test:
- Read access : can read the data in the object,
- Create access : can create a new record in the object,
- Write access : can modify the contents of records in the object,
- Delete access : can delete records from the object.
To configure a rule on an object, use the menu Administration ‣ Security ‣ Record Rules. The fields in the ir.rule object describe:
Object : Object on which to have the rule
Name : Name of the rule
Global : If global is checked, then that rule would be applied for all the groups; and if it is unchecked, then that rule would be applied only for the groups selected for it
Domain : A list of all the tests for the object. It is specified through a Python expression as a list of tuples.
- If there are multiple tests on same object, then all of them are joined using AND operator, and depending on the result the rule would be satisfied
- If there are multiple rules on same object, then all of them are joined using OR operator
Access Modes : Read, Write, Create, Delete as described earlier
- If only one access mode is checked, then only that mode would be applied
- If all of them are checked, then all the access modes would be applied
But at least one access mode has to be checked, all of them cannot be unchecked. If all of them are unchecked, it would raise an exception.
For example : We can have a rule defined on res.partner object, which tests if the user is the dedicated salesman of the partner [('user_id', '=', user.id)]. We check only the create and write access modes and keep other access modes unchecked.
This would mean that a user in the group for which the rule is applied can only create/write records where he himself serves as the dedicated salesman, and cannot create/write records where he is not the dedicated salesman. As other access modes are unchecked, the user can read/delete the records of partners where he is not the dedicated salesman.
Each record in an OpenERP database carries a note of its history. You can find out who it was created by and when that occurred, and who last modified it and when that occurred. Click the View Log link at the right of any form in the web client to display a dialog box showing this information, as shown in the figure Partner Record History. It can help you identify who to contact if there are any problems with the data in the records.
OpenERP has an Audit Trail module audittrail, which can be used to track any or all of the changes to one or more objects. It should be used with care, because it can generate huge amounts of data in the live database, but can be an invaluable tool.