Control what your users can access and save time, money, and frustrations. Lock down sensitive data in SugarCRM or SuiteCRM to specific groups or teams. Supports unlimited assigned users, unlimited group assignments to records, custom layouts for each group, login/sudo capabilities and much more.
#434 - I think I understand the model but can't make sense of which records users can and can't see.
What I would like to do is have record that can always be seen by its creator, and everyone in the group of the assigned user.
My concrete example: I'm using SuiteCRM Version 7.0.2 based on Sugar 6.5.16.
I have two groups of sales people, the groups are called "West" and "Midwest". These groups are assigned the role "Owner Rights" which have owner rights to everything.
I have another group, "Technicians" who have group rights to everything.
Someone from the sales team, groups "West" or "Midwest" will create records like projects. They will then assign projects to people in the "Technicians" group.
I want technicians to be able to see all projects that have been assigned to anyone in the technician group. I want project creators to always be able to see projects they create regardless of who it is assigned to.
I have additive rights, strict rights, inherit group from created by user, and inherit group from assigned to user.
This means a project created by someone in "West" and assigned to someone in "Technicians" should inherit the "Technician" group based on inheriting groups from the assigned to user, and therefore be visible to everyone in the "Technician" group. It's not.
I'm not sure if this means that with strict rights on that a record creator should still be able to see it. I have tried with strict rights off as well, which means the project record that's created by West and owned by Technician...
I think I realized where I was misunderstanding the model. When the record creator assigns a user, they give up their owner rights. So it seems the schema I came up with above will have to be modified in order to do what I want. I'm not sure if it's possible.
Here's a crude diagram that I think illustrates the problem http://i.imgur.com/ps5m5X3.png.
There is one tangent that is kind of a mystery to me. If I modified the roles that are assigned to "West" and "Midwest" to include group privileges on projects, then something strange happens. I have 8 projects of sample data. One person in the "West" group can see some projects owned by someone in the "Midwest" group, but not one in particular. I have no idea why this one project is not visible. I have double and triple checked that there is no parent record, both groups have the same role assigned, no users have a specific role, etc.
-
"The features are exactly what is needed to turn a SugarCRM CE into a Teams based CRM."
Read More Reviews
- Most Recent Love from Users
kacsoristvan- damien8105
- anri
- Administrador
- Stefano1
- einkauf2
10 years ago
This is a lot to unpack so I apologize for the long-winded response. Please follow up with any additional questions or clarifications needed.
To back up a little bit, the key point to remember is that groups determine what records a user has access to. Roles determine what a user can then do with the record. For the Group permissions to work records need to be directly assigned to the appropriate groups.
Side track - the challenge here is that SugarCRM does not deal well with "created by" users and permissions. There is an easy hack to make it so that they are treated as "assigned to" users permission-wise so that they count under the Owner role permission. If you are interested in that approach you would edit /data/SugarBean.php->isOwner() and add the following before the assigned_user_id check:
Back to making this scenario work as-is with no code changes.
Both the West and Midwest groups will need to be assigned a role with "Group" rights to records so that they can see all projects that they create because of the isOwner limitation I mention above. When someone in "West" creates a project it will automatically inherit "West" with the "Inherit from Created By" option (given that the project module is properly hooked up to the Security Groups module). When they re-assign it to a user in the "Technicians" group it should then inherit the "Technicians" group if the "Inherit from Assigned To" option is set. This is the only inheritance option that works when editing existing records.
At this point the new project would have both the "West" group and the "Technicians" group assigned to it. The downside is that anyone in the "West" group can see the record. If this cannot be the case then I suggest trying the hack above.
Strict Rights should probably be unset in your scenario.
Important note: a user gets the greatest rights of all roles directly assigned to the user or to the user's groups. If you are in a situation where you can't find why a user can or can't see something always go to the user's permission grid. That will reflect how permissions are inheriting from all applied roles. Also note that any changes to permissions requires that user to log out then back in due to how SugarCRM caches permissions.
10 years ago
And the code chunk did not translate correctly. So if you copy/paste it that will throw some errors. The > symbols need to be replaced with a greater-than symbol. The & replaced with ampersands.
10 years ago
I appreciate your help. I will try some of this stuff out and see how it works but I was hoping you could clarify one thing for me:
Are groups inherited only at certain instances in the life of a record? Like is the "created by" group inherited at the moment of creation, or is it checked dynamically whenever that record is accessed, the groups of the creator are checked too?
Put another way, if someone creates a record, and then they are added to a group some times later, will that record also inherit that group? Or does the user have to be a member of that group at the time the record is created?
10 years ago
Great questions.
Created By and From Parent only inherit at the time of creation. From Assigned To is inherited whenever the record is edited and saved.
If a user is added to a group after a record is created that change in group membership is not applied to records created in the past. Only going forward. The user needs to be a member of the group at the time that the record is created.
10 years ago
Haha oh crap, this explains so much of the strange behavior I observed vs what I expected in the last couple days. Re-examining your docs, it seems obvious now.
10 years ago
No worries! There can be a steep learning curve with this initially.
10 years ago
OK I believe I have everything fully resolved but there is one last thing I'm not totally clear on.
Using your help I was able to get the desired behavior for project records based on their creators and owners, however I did this with strict rights on.
I would rather be more strict than less strict, but I'm not sure how this deployment is going to evolve.
If I came to an impasse some time in the future I needed to flip the strict rights setting, would it be easier to manage the side-effects that would come from starting with it enabled and then having to disable it for whatever reason? Or vice versa? Or is it too difficult to tell?
I can't even begin to foresee what kind of problems might occur in one scenario or the other.
10 years ago
One more thing which is not a question but a bit of feedback.
I was little confused by the metaphor used somewhere in the docs that "groups are what doors you can see and roles are the keys to those doors."
I believe I found an old forum post of yours through a google search where you said this, and it clarified things for me a lot:
"Think of Groups as what groups of users should have access to certain records and Roles as what they can do with those records"
Actually this is almost exactly what you said in your first reply.
10 years ago
Strict Rights just means that the rights that get applied to the user once they access the record will be the rights associated to the groups associated to the record.
So if a user is a member of a Super Admin group with All rights to delete, but the West group has No rights to delete and only the West group is assigned to Company XYZ then the user will NOT be able to delete it.
Strict Rights is meant to handle some pretty specific scenarios. I don't set it by default on purpose for new installations. If you have a common scenario that requires it then it makes sense to have on. Otherwise, it may be confusing depending on the circumstance.
Shorter answer is, it is probably to difficult and early to tell. It's one of those things that when you need it then you'll know. Side effect of turning it on too early is that it could cause some data to be hidden to users which could mean duplicate records created, missed opportunities, and so on.
10 years ago
Great feedback. I'll add that to the docs. Thanks!