I created a role called “Assistant” and disabled all but a few modules and set almost all permissions to “Owner.”
I added the role to a security group named “Assistant” as well.
When I assign the role, group, or both the group and the role to a user, it has no effect. They are still able to access EVERYTHIN–all modules and all permissions, including the modules that are “disabled.”
This is a massive security flaw. How can I troubleshoot this? Thank you.
i spent quite long time to understand how it works and now I have something working fine like this:
in role management, add all users assigned to this role , don’t add anything in security group management section
in Security Suite Group Management add all users assigned to this group, don’t put anything in role section
in Security Suite Settings, i have everything checked except strict rights, this can be adjusted based on your needs.
this tells, this user has this role for this modules, if in a role management module line it is specified GROUP instead of ALL, then this user can see only records assigned to the security group of this user. the way the record is created with a specific security group is managed by the user security group.
like you, I was thinking that adding the security group of users to role management was the correct way to add a list of desired users to the role… but it is not the case.
if you assign a security group to a role it is more like you say that this role in Role module is in security group assistant, I’m not sure to be clear but once you forget about security group like a user group in a computer management where assigning a paramter to a group is applying it to all users in the group… then you see the light
There are 3 key steps to setting up Groups so that you work correctly.
Create a group for each team of users and add the appropriate users to the group.
Create a role and select Group for the access level for every appropriate cell in the grid. Assign that role to each group
Add the groups to records in your SuiteCRM instance. You can use the Mass Assign on the List View to do this. Going forward the groups will automatically inherit based on your SecuritySuite Settings. You can also use logic hooks, workflow, or do a direct database insert into the securitygroups_records table if doing a one-time initial setup.
If your users should only typically see their own records then the role assigned to the group would be configured to have Owner only rights. A manager who is a part of the group and who should also be able to see all records in the group would have a role directly assigned to the manager’s record that gives Group access.
The example docs (owner, managers, east/west sales teams) don’t have the sales team with direct role assignment. Only the managers and owner get direct role assignment on their users. The sales team itself are just part of a security group (Sales East/West) which has the OWNER ONLY role assigned.
Basic setup, latest version, no custom modules.
Created a “OWNER ONLY” role called “Owner Only” (owner only across all modules)
Created a Security Group called Sales and
added OWNER ONLY role to it.
added User1 and User2 (regular users) to it
Default security group settings (ie inheritance, additive, etc)
List roles by user for User1 shows OWNER ONLY across the board.
Viewing the user and clicking access tab shows same thing.
As admin created some test leads.
Selected all leads and mass assigned the security group Sales. Inspected these lead records and verified they ONLY have security group Sales.
Assigned some leads to User1 and some to User2.
Logging in as User1 and User2 I can see/edit all leads, not just those assigned to the current user.
Went in and ran repair roles from admin. no difference.
So a lead record with security group Sales and assigned to User1 which has only security group Sales (Sales security group has only one role OWNER ONLY) doesn’t seem to do anything.
Did I miss something? I have read and re-read both the suite and sugar docs on this as well as some forum posts and stackoverflow stuff and I don’t see what I am doing wrong…why the securitysuite doesn’t seem to have any effect.
There are two places where this field can be found. The first is on the group itself. If the “Not Inheritable” field is checked then the group will not automatically be attached to any record. This can be useful for cases such as creating groups to assign roles to.
The second place where the “Not Inheritable” checkbox can be found is in the Users subpanel within a group. The meaning is similar here. If the checkbox is checked that group will not inherit for that user. This can be set by clicking on the “edit” link on the appropriate row in the Users subpanel. An example use case is when a manager needs to be able to view a group’s activity but the group shouldn’t see the manager’s activity. By checking “Not Inheritable” the group will not automatically be assigned to any record that the manager creates.
To be honest, still not really clear/obvious to me how this works (and I’ve personally designed and implemented group/role/permissions management systems for apps).
But it seems like this “Not inheritable” checkbox on the security group is somehow key when using security groups to map roles to users. If someone can confirm, I’ll update the docs to indicate that “Not inheritable” needs to be enabled for the example to work.
Okay. Thanks. I figured since this was a very simple case following the docs that we it should be someone well understood. But perhaps not.
Good to know that this security stuff is maintained by a third party. I didn’t really make that connection as it came with SuiteCRM and wasn’t a third-party add on.
The other weird thing that I just noticed is that my sales users have lost the ability to see the detail view. ie from the lead list view they can edit, but the linking to the detail view for each lead is gone. Of course they have owner-only across the board so there shouldn’t be a different behaviour for list/edit/detail view. Maybe a bug.
Figured it out. I had customized the list view columns and used lastname, firstname instead of name. Apparently the linking to the detail page is only done on the name (combined first/last) field as opposed to the entire row. So if you customize the list view and remove the name column you will lose linking to detail view.