User Login

Tip

Managing Passwords

If you let users change their passwords for themselves you’ll 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.

Tip

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 Open ERP.

Note

LDAP

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 Open ERP is how to manage access rights to the information in it.

You’re 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 Stockmay only be given access to some of the menus in Stock Management, and may have no access to any of the accounting information. Each system user who works in Stores is given membership of the Stock group. If some users also work elsewhere, they’d also be given membership of other groups.

Open ERP users can also belong to various roles. Just as group gives a user access rights, each role determines the user’s duties. This is managed at the level of workflows, which form the company’s business processes.

Groups and Users

To configure access rights you’d start by defining the groups. It’s 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’re 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 a departmental areas that have different levels of access rights. For example, if you create a Sales Directorgroup 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 Directora member of both groups, and give the Sales Director group a limited set of extra rights, or give the Sales Directorgroup 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.

Tip

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 for menus

To get a feel for rights management in OpenERP you’ll create a new Stock1 group, with access to the Stock Management menu items. You’ll then create a stores person user who’s a member of the Stock1 group.

To create a new group, use the menu Administration ‣ Users ‣ Groups. Enter the group name Stock1.

Then to create a new user linked to this, use Administration ‣ Users ‣ Users to enter the following:

• Name : Stores Person ,
• Username : stores ,
• Password : stores ,
• Company : <your company> ,
• Action : Menu ,
• Menu Action : Menu .

In the second tab of the user form, Security , add the Stock1 group that you just created.

Groups that have access to the Stock Management menu

Save the user, then go into the menu Administration ‣ Security ‣ Grant Access to Menus to get a list of menus. Filter this list using the search field Menu to get the Stock Management menu item. In the form describing the menu, add Stock1into the Groups field. While you’re at it, also add the admin group there. From now on, only members of the Stock1 group and the admin group will be able to see this menu item in their main menu list.

Tip

Menu hierarchy

Since menus are hierarchical there is no need to hide access to lower menus: once you’ve configured Stock Management this way, all lower-level menus become invisible to members of other groups.

Tip

Security

This method of managing access to menus doesn’t guarantee that users are prevented from reaching hidden business objects in the system in other ways. For example, hiding the Invoices menu won’t prevent people reaching invoices through purchase and sales orders, or by guessing the URL.

For effective security management you must use the methods for managing access rights to objects presented in the following section.

Note

Initial access configuration

In the initial configuration, Open ERP’s admin user, a member of the admin group, is given access to the Configuration menu in each section of the main menu. This is a general convention. For example, Partners ‣ Configuration is visible in the administrator’s menu amongst the other Partner menu items, but only those other menu entries are visible to other users. Similarly, the main menu entry Administration is, by convention, visible only to users who are members of the admin group.

Access Rights to Objects

The menu access rights determine who can access which menu, but doesn’t define what you can do once you’re 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.

Note

Object

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 don’t lock the admingroup out of any objects that control 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.

Access control to invoices for the Finance/Admin group

To configure access rights on a Open ERP objects, use the menu Administration ‣ Security ‣ Access Controls ‣ Access Controls List and click New or choose one there and click Edit. You give a Name to the access control, select a Group, and the object (Model), then check the checkbox corresponding to each of the four Access modes.

If you don’t 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 rule on 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

• Test : A list of all the tests for the object

  • If there are mulitple 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 can not be unchecked. If all of them are unchecked it would raise exception.

For eg : If we have a rule defined on res.partner object which tests if the user is the dedicated salesman of the partner [('user_id', '=', User)]. We check only the create and write access mode and keep other access modes unchecked.

So this means 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 can not 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.

Note

Currently record rules are enforced for all operations (read, create, write, delete). But the above described feature is new for version 5.2.

Modification history

Partner Record history

Each record in a 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 icon at the top right of any form in the web client (but only when it’s read- only, not when it’s editable) to display a dialog box showing this information, as shown in the figure Workflow for order SO005. It can help you identify who to contact if there are any problems with the data in the records.

Tip

Audit Trail

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.