#1687 - Security Suite Performance Issue
Hello,
we have severe Performance Issues with the Security Suite and the following group structure:
We have a Global Group (related to a Global role) and other Groups (related to another role) like: Sales, Marketing, IT, ...
Every record (Accounts, Calls, ...) is related to the Global group and every record that is created is also related to the Global Group. For example if a record should be visible only for Marketing we remove the Global Group and add the Marketing Group to that record.
Our securitygroups_records database table has now approximately 850 000 entries and the load of the server where the database is located is extremely high. The result is that our system can not be accessed.
My Questions Would be:
1) how can we optimize security suite, so our system would run smoothly? 2) is our current group structure (replicated from Sugarcrm Pro) the cause of this performance issue? how should we change it for a better performance?
Regards
System: Suitecrm 7.2.2 (Sugar Version 6.5.20 (Build 1001))
9 years ago
I would first recommend removing the Global Group from all records. It's not needed and just adds to much overhead. The "Additive Rights" option under SecuritySuite Settings accomplishes the same thing as the Global Group technique in Pro.
Then from there follow my recommendations here for optimizing SecuritySuite and SuiteCRM: https://www.sugaroutfitters.com/support/securitysuite/496
9 years ago
Hello,
the problem with removing Global group and activating additive right is that records can not be restricted by groups. For example: User A has the Role Sales. The Sales Role has access rights (view, edit, etc.) to all Accounts. With additive right if you assign Account B the group Marketing, sales User A has still access the Account B
Without additive Rights User A can't see Accounts except that are assigned to User A.
What we are trying to achieve is: Sales user A should have access to all Accounts until a specific Account B is assigned to another group like Marketing. How can we achieve this with additive right and without the Global group. (Also tried to add and remove the Strict Rights option without any success)
Kind Regards
9 years ago
To sum that up, it's basically meant to make certain records private, right? I usually suggest that companies avoid going the private route as much as possible if there isn't a real security need for it. There are a few different ways to approach this in your case. I believe that the easiest route is to just leave it as you have it and address the database optimization side with the suggestions I linked to before. Another alternative is to always assign the Sales group to new accounts, adjust roles to be Group access, and remove the Sales group when transferring to Marketing.
If the biggest goal is to remove them from the list view to make it easy for sales to focus on what to work on next it might make sense to customize the list view to remove any accounts that are assigned to the Marketing group. This would require tweaking code for the Account's view.list.php.
9 years ago
Its not only about restricting the users to certain record views, but generally about the Groups concept
I think a solution (feature request) would be that security suite handles records without a group so that all users can access them: For example: To user A is the role "Sales" assigned with the following rights for Accounts: List and View "Not Set" To user A is also the Group Sales assigned with following rights for Accounts: List and View "Group"
Current situation: With additive Right (Strict Rights: checked, User Role Precedence: not checked) User A can only view Account B if it is assigned to the "Sales" Group
Feature: Account B is not assigned to any group and user A can view it. Or additive right only for roles or only for groups.
Could you point us to the direction how we could implement the feature: If a record is not assigned to a group than it should be visible for all users (that have group or "normal" view rights) If you like we could also send you the code that we would have developed for us so you can decide to (or not to) implement it to the security suite.
Kind Regards
9 years ago
Here's an alternative that will limit the # of groups and relationships in your database:
With Strict Rights the roles associated to the groups associated to the Account are the ones that get applied. So Marketing will have access to the Account if the role associated to Marketing allows for it. If a user is not in Marketing (such as sales) then the Restricted rights would be applied. If a user is in both groups (such as marketing) then the greater of the rights would be applied so they would have access.
This limits the number of group associations then as a global group is needed on every record.
There's almost always a way to do anything with a combination of groups and roles. It can just take some work up front to find what works best for your unique needs. I hope this method will do the job.
Here is another possibility that I suggest on this support case about private records: https://www.sugaroutfitters.com/support/securitysuite/427
The one downside is that the non-assigned user can see it in the list view. The user cannot click a link to get to it, however. The list view visibility is a limitation of how SugarCRM works.
8 years ago
Closing this out, but feel free to follow up if you have any more questions.