Control what your users can access and save time, money, and frustrations. Lock down sensitive data in 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.
#2351 - Issues with assigning roles to security groups
Currently, the way the system was set up was for each salesperson to also have a corresponding security group (we use SuiteCRM where Teams = Security Groups). All of their accounts are then assigned to the security group, however, the role that defines their permissions are assigned directly to the user. The group does not have a role. This has worked up until now.
We now have an add-in that needs to read a configuration document published by the admin (me) from the Documents module. It requires read access (enabled and "View") to Documents and Security Groups Management. I thought I could create a new security group, assign it a new role with these modules enabled and View = Group and then add users to the group to give them access but this does not work.
I then tried to remove all roles assigned directly to the user, assign the sales role to the user's individual security group and then assign the new security group for the add-in which already had it's own role assigned. When I checked under Role Management > List Roles by User, this appeared to work as I could see the elevated access for Documents and Security Group Management. I did this all using a test user so I then signed in as that user and tried to access a document that I had assigned the new security group to but the user could not see it. I also tried setting View & List to "All" for the role in the new security group that is assigned to the Document but my test user still cannot see it.
It appears that assigning roles to security groups just does not work. What am I missing here?
-
"The add-on itself was already a must for my SuiteCRM, which was missing this very important security feature. However, what surprised me the most was ..." - Davint
Read More Reviews
Larry Rudd
4 years ago
Hello - I received an e-mail that this case had been updated so I am following up. Thank you!
4 years ago
Hi Amy,
Under Admin->SecuritySuite Settings make sure that Additive Rights in checked and User Role Precedence is NOT checked. Then log out and back in as that user. Let me know how that goes.
4 years ago
Additive Rights & User Role Precedence are both checked. But if their is no role assigned to the user directly, how can it take precedence? Is assigning roles to groups in this scenario the right way to go about accomplishing what I'm trying to do?
4 years ago
Thanks for checking on that. From my understanding of what you are trying to do this should work as expected. I'm going to attempt to replicate this scenario. Are you using SugarCRM or SuiteCRM and which version of it are you currently on?
Thanks! Jason
4 years ago
SuiteCRM Version 7.10.4 which I guess is built upon Sugar Version 6.5.25 (Build 344) since both show on Help > About.
I was told the reason it had been set up the way it had was so that the sales person could create and access any sub-items created (like a contact for an account). It doesn't appear to me that removing this checkbox would change that.
4 years ago
Thanks Amy,
I will test this scenario out on 7.10.4.
The recommended approach is to assign roles to the groups and for any one-off scenarios have those roles assigned to users. However, either case won't affect whether a sales person has access to sub items. The key for that part will be the inheritance options on the settings page so that any record (e.g. a call) created under a contact would inherit the appropriate groups so that the sales person can also access that record.
I will give this a shot today and follow up before tomorrow morning.
Thanks, Jason
4 years ago
I misread what you are attempting and see what is going on now. When you create a new group that group then needs to be added to each Document. This missing step will cause the behavior you describe.
As an alternative, the existing groups that you already use should be on the Documents already if they were inherited by the parent record or the sales person who created the Document. If so, just using the existing role you already have assigned to the sales person should work if you change the Documents permission to View=>Group and List=>Group. Reminder that whenever a role is edited the user needs to log out then back in for any role changes to go into effect.
Otherwise, when you create the Document be sure to add the new security group to the Document. Once that is done then it should work if you have that new group's role set to View=>Group and List=>Group.
Let me know if you have any questions.