by eggsurplus

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.

Free 30 day trial
Try it Now

#1687 - Security Suite Performance Issue

Closed General Question created by Capsid Verified Purchase 4 years ago


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:

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?


Suitecrm 7.2.2
(Sugar Version 6.5.20 (Build 1001))

  1. eggsurplus member avatar

    eggsurplus Provider Affiliate

    4 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:

  2. software1 member avatar

    Capsid Verified Purchase

    4 years ago


    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

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      4 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.

  3. software1 member avatar

    Capsid Verified Purchase

    4 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

    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

    • eggsurplus member avatar

      eggsurplus Provider Affiliate

      4 years ago

      Here's an alternative that will limit the # of groups and relationships in your database:

      • Turn on Strict Rights in SecuritySuite Settings
      • Have a general role that grants all access to Accounts assigned to all users (could do via the Global Group still to make that easier to manage)
      • Have no groups assigned to Accounts by default
      • Create a new group called Restricted or Private and assign a role to it with Accounts List access set to None
      • Add all users to Restricted
      • When Marketing gets added to an Account also add the Restricted group

      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:

      • Create a Global group and assign a role to it with All access
      • Create a Private group and assign a role to it with Owner access
      • Add all users to both Global and Private
      • Set Strict Rights
      • For an account that should be private add the Private group and remove all other groups
      • Log in as the assigned user for that account to verify that the user has access
      • Log in as some other user and verify that the user cannot access it

      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.

  4. eggsurplus member avatar

    eggsurplus Provider Affiliate

    4 years ago

    Closing this out, but feel free to follow up if you have any more questions.

This case is public. Please leave out any sensitive information such as URLs, passwords, etc.
Saving Comment Saving Comment...
  • "SecuritySuite was a very good addition to our SugarCRM implementation helping to integrate different functional teams with strictly specified roles."

    Read More Reviews

Keep up to date on the latest additions

We'll send you an email every month with handpicked add-ons, reviews, tricks and tips. Don't worry, we hate spam as much as you do.