I only want the person who I have assigned the task to see the task in the project module. I don't want other users of the project to see this persons tasks.
However currently any user who has user access rights can see all the tasks even if they were not assigned it.
Is there a work around this ?
OpenERP/Odoo has two kinds of security restrictions that can be assigned to a user group:
Access Rights are CRUD yes/no flags (similar to Unix FS permissions), and allow per-model access control. They state whether members of this group may perform a Create, Read, Update, and Delete operation on any document of a certain document model (e.g. a project task). The default policy is DENY, so by default any operation will be refused if the user does not explicitly have the right to perform it via one of her groups' access rights.
Record Rules are filters applied on CRUD operations, and allow per-document access-control, once access right are already granted. Users will only be able to perform an operation on a given document if the document matches at least one of the record rules. The default policy is ALLOW, so if no rule exists for a given model, all documents of that model may be accessed by users who have the necessary access rights.
Both Access Rights and Record Rules may also be defined globally without assigning them to a specific group, in which case they apply to everyone. There is one pitfall for Record Rules: global rules may NOT be relaxed by other rules (on purpose!), so use with care.
In your case it looks like you should define one extra Record Rule on the Project User group that explicitly restricts access on Project Tasks to your own tasks (and presumably those that are not assigned yet). 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 ones)
apply for read: [x]
apply for write: [x]
apply for create: [x]
apply for delete: [x]
groups: Project / User
The domain of a record rule is a standard OpenERP/Odoo domain that is evaluated on the records on which you are trying to perform the operation, and can refer to a user variable that contains the current user's data (technically, a browse_record on the current user). The documentation has a description of domain.
If you want to allow special users (e.g. 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 access to all tasks. There is a special "domain filter" that means "ALLOW ALL" and is useful to relax another stricter rule: [(1,'=',1)].
Note 1: Have a look at the existing Record Rules to see what they're doing first, and be sure to read the explanations on the Record Rule form when you are adding yours. One important thing to keep in mind is that group-specific rules are combined with an OR operator. So if you add the rule I described above, you may not see any restriction effect because other group-specific rules are still giving access. You may have to disable them, edit them, or change the user group they apply to, to get the exact effect you want.
Note 2: Remember that if you do something wrong with Access Rights and Record Rules, you can always fix the mess with the admin account, as these security restrictions do not apply to the admin (similarly to the root user on Unix).
Note: In OpenERP 7 you have to modify or disable the defualt rule called
Project/Task: employees: public, portal, employee or following or
assigned
To get your rule working.
Create a new security rule, select Object as "project.task" ,give domain filter as [("user_id","=",user.id)]. No need to add any groups, so that it will be global. Thats it!
My problem was a bit more complex. I wanted to have users who can only their assigned tasks and some who can see the rest, too.
In Odoo 11 I found that the standard project user inherits Employees \ Employee which in turn has the rule Project/Task: employees: follow required for follower-only projects which let users see the other tasks.
What I did:
create a new group -> duplicate of Project / Users
implemented the rule from odony's answer -> ['|',('user_id','=',False),('user_id','=',user.id)]
removed the record rule Project/Task: employees: follow required for follower-only projects from Employees / Employee and added it to Project / Users
Now I can decide who is a project user, who can see all tasks of a project, and who is a worker, who only gets to see tasks assigned to them.
As already pointed by #user1534055 in openERP 7, it's a bit-different.
Find the rule named Project/Task: employees: public, portal, employee or following or assigned
Edit it and remove ('project_id.privacy_visibility', 'in', ['public', 'portal', 'employees']),
'&', from the rule definition and hit Save.
After this tasks will be visible to only those who've been assigned.
Related
I am working with a lot of MODX since 2010. From time to time i coudl need another user group with restricted permissions. Like "Can edit content, but not change settings". So the user can't break anything which is relevant for die CMS itself.
I added users, placed them into roles and groups, but somehow it never works the way I expect it to work. A role is not a "role" but a level of authority. A group is just a link to a set of permissions, which is already setup as a ruleset. Still, if I create and setup the group "content editor", I never get it running as expected.
Is there a guide (or even an extra?) to setup restricted user account without breaking ones brain?
There's a basic tutorial available in the official documentation: https://docs.modx.com/revolution/2.x/administering-your-site/security/security-tutorials/giving-a-user-manager-access
My personal recommendation would be to ignore roles altogether. Whenever you need to enter a role (when adding a policy to a user group, or when adding a user group to a user) just pick "Super User - 0". They're an added complexity to allow, essentially, different permissions within the same user group, that 99% of the people don't need.
The primary thing to do is to create a policy, based on the "Administrator" policy set, that contains the permissions you want the user to have in the manager. Those would include the relevant resource/document permissions, but not settings, for example.
Then you add that policy to the user group of your choice as a "mgr" context policy.
The usergroup will also need context permission to be able of interacting with specific contexts. So on the contexts tab in permissions, add the different contexts you want, with the contexts policy.
As #optimuscrime commented, ACLs can be a little complicated, but that's the general approach.
It's my 1st time i'm working with Yii2's RBAC system.
I used http://www.yiiframework.com/doc-2.0/guide-security-authorization.html to get myself familiar with topic.
As i needed some kind of administration for roles / permissions, i installed this extension: https://github.com/mdmsoft/yii2-admin
I'm working on application that let's users submit articles. There are two kind of users, Administrators, and normal Users.
I created 2 roles for that purpose. Admin role and User role.
Users (both admins and users) must have ability to edit articles. Admins should be able to edit any article, while users can edit only their own articles.
For that i created 2 permissions. "Edit" permission and "EditOwn" permission. Than i created "IsOwner" rule and attached it to "EditOwn" permission.
I assigned "Edit" permission to Admin role, and "EditOwn" to User role and everything works great.
Now i'd like to create "lock" status for each article. If Article is locked, user can not edit it even if it's he's own article. Admins should be able to edit it even if it's locked.
For that i created new rule "IsLocked" but i dont know how to add it to "EditOwn" permission. I don't know is it even possible to have 2 rules attached to one permission?
EDIT:
Right now, i have this "dealt with" in way that i have additional permission "EditOwnIsLocked" to which i attached "IsLocked" rule which is than child of "EditOwn", which is child of "Edit".
This works, but it feels dirty and plain and simple wrong.
As it turns out, there is (for now) no way to attach multiple rules to a permission.
You can deal with need of multiple rules in way i do right now, by creating additional permission and attach rule to it and than make child<->parent connection, or you can edit your rule to check for all situations (in my case to check for IsParent and IsLocked).
Those solutions arn't perfect but it's what it is for now. First solution spawns unnecessary permissions, and clutter your permission list (in case you are using yii2-admin or similar extensions), but keeps your rules clean, and second solution keeps your permission list clean but makes you retype same code in multiple rules which is kinda oposit of what OOP stands for.
I'm trying to make the "Edit" button on the Project form to only be visible if the user logged into the system is the Project Manager of that project. I've been reading various answers online regarding this, gathering some understanding of Access Rights vs. Record Rules but I haven't been able to get this working. To my understanding, Access Rights over-ride Record Rules. So, if I create a record rule under the group "Project/User" that has read and write access with the domain as the following:
[('user_id','=',user.id)]
This will be over-ridden by the Access Rights for Project/User anyway? So How would I get this to work?
Thanks to anyone who can help.
As far as I know, Record Rules can override Access Rights.
Here is an example where record rules are used to change the base_user edit capabilities depending on the Task state: https://github.com/OCA/project-service/tree/8.0/project_baseuser/security
However, the "edit" button is not dynamically visible depending on the Task Status: it's always visible but the rules may or may not allow to write upon "Save".
Access Control List is checked before Record Rules.
Because Access Control List is a CRUD security on models (create/read/update/delete).
Only if ACL is passed next record level security comes in.
As far as I understood you want to give Project User permission to edit his own projects (he is in group Project User not Project Manager but set as Project Manager for exact Project by Project Manager group user LOL).
I did this by doing the following:
1) Give project users Project Manager role.
2) Restrict them to only modify own projects by creating a Global rule (no group is set) with the following domain on update / delete operations:
['|', ('user_id','=',user.id),('create_uid','=',user.id)]
P,S, Here is screenshot - http://awesomescreenshot.com/0083nqyf76
For the model project.project, provide the write permission only to the group project manager.Go to settings/techical/security. There you can see the access control list. CHeck what all group is provided to the project.project model.for every group other than project manager, remove the write permission
I'm working on creating an administrative interface that allows managing users in groups in Active Directory.
I would like to only show groups to the active user if the user actually has the rights to add or remove other users within those groups, but I'm not sure at this point, how to determine which people can modify the groups, or whether the current person has access to modify a specific group.
I suppose the application can find out after the user tries and we get an access error, but I don't like to use error trapping as a way of determining if some feature is available and I would prefer not to tempt the users with a list of groups they can't control.
If possible, please supply an answer that targets vb.net 3.5 using System.DirectoryServices.AccountManagement as that is the environment that I am currently working within. I can translate from C# if necessary.
I'm working on a site, which will have several modules that either fully available to certain users, semi available to other users, and unavailable to the rest.
For example:
An 'employee' is able to respond to the customer support tickets assigned to him.
A 'Manager' is able to manage all employees and support tickets in his team, including viewing the tickets of a specific employee.
An 'Admin' is able to manage all managers, employees, and tickets in all teams, as well as some other core functionality.
In addition, on some pages there will be some additional fields shown if the current user is an admin or manager. (E.g links to delete/flag things). These won't be shown to employees.
I want to create one 'Permissions' model which will handle the logic for:
Determining if a user can access the current page or not.
Determining whether a particular part of a page should be displayed or not. (E.g special links for editing/deleting to be shown to admins and managers only).
I need some recommendations/advice for designing this class, particularly what methods it should have in order to accomplish the 2nd requirement.
The way I have approached this problem when it has come up is to give each action that can be taken or piece of information that can be shown it's own Permission. Each User then has a collection of Permissions. From this, you can add other layers of structure to help manage the huge number of permissions that will exist, such as hierarchies or categories of permissions.
Once that is in place, you can either have the various parts ask the User if they have the needed permission(s), or you can have a PermissionManager take a User and a set of Permissions and determine if the given user has the needed Permissions. Either way will work fine, but which one you choose has an impact on dependencies and the architecture of your system.
The PermissionManager approach has the advantage that your application pieces don't need to depend on a User, so you could use a different PermissionManager that always returns False if no permissions is appropriate, or True if all permissions is appropriate.
For simple situations, this approach can be overkill, and it often seems like it is at first, but I've gone the route of using basic hierarchical or coarse-grained Roles and fond that virtually every system I've worked on quickly got too complicated for most vanilla, pre-built Roles-based permission systems.
My approach to this problem from database point of view would be to have a user table which holds the list of users, a role table for the list of roles, e.g.: employee, manager, admin; and permission table which stores all of the values of every action/feature available in the system and its permission for a specific role, e.g.: say for admin, the values for actions/features like create, edit, delete, view are all true. The relationships can be seen below whereas (N) ---- (N) is a many-to-many relationship.
Users (N) ------- (N) Roles (N) -------- (N) Permission
My impression is that you would require to make use of roles e.g. employee, Manager, and Admin. So a roles table with these would do. Then for the particular actions/permisions you would have to make use of branching logic i.e. for example for the employee you will have
if User.IsInRole("employee")
// insert logic to deal with customer support tickets
else if User.IsInRole("manager")
// insert logic to deal with manager responsibilities
and finally logic to deal with admin responsibilities
So you need both the users table and the roles table to achieve this.
Hope it helps