OpenERP has two kinds of security restrictions that can be assigned to a group of users:
- Access rights are CRUD yes / no flags (similar to Unix FS permissions) and allow per-model . They indicate whether members of this group can perform the Create, Read, Update, and Delete operations on any document in a particular document model (for example, a project’s task). The default policy is DENY, therefore, by default, any operation will be denied if the user clearly does not have the right to perform it through the access rights of their groups.
- Recording rules are filters applied to CRUD operations and allow access control for each document when access rights are already granted. Users will only be able to perform an operation for a given document if the document complies with at least one of the recording rules. The default policy is ALLOW, therefore, if there is no rule for this model, all documents of this model may be available to users who have the necessary access rights.
Both access rights and recording rules can also be defined globally, without assigning them to a specific group, in which case they apply to all. There is one mistake for write rules: global rules cannot be relaxed by other rules (specifically!), So use with caution.
In your case, it looks like you should define one additional write rule in the Project User group, which explicitly restricts access to Project Tasks to your own tasks (and, presumably, those that have not yet been assigned). You need to create a new entry in the security rules menu with these parameters:
- object / model:
project.task
- name:
See own tasks only
- domain:
['|',('user_id','=',False),('user_id','=',user.id)]
- (means: your own tasks and unassigned)
- apply for reading:
[x]
- Apply for entry:
[x]
- applicable for create:
[x]
- apply to remove:
[x]
- groups:
Project / User
domain
the write rule is the standard OpenERP domain, which is evaluated in the records on which you are trying to perform the operation, and can refer to the user
variable, which contains the current user data (technically, a browse_record
for the current user). Locate search()
in the list of ORM methods for a complete description of domain
.
If you want to allow special users (for example, Project Managers) to view all tasks in the system, you can relax this rule for them by adding another rule to the Project Manager group, which allows you to access all tasks. There is a special “domain filter” which means “ALLOW ALL” and is useful for easing another stricter rule: [(1,'=',1)]
.
Note. Look at existing recording rules to see what they do in the first place, and be sure to read the explanations in the form of a recording rule when you add your own. And remember that if you have something wrong with the access rights and write rules, you can always fix the mess with the admin
account, as these security restrictions do not apply to admin
(similar to the root
on Unix).
odony source share