SecuritySuite - SuiteCRM and CE Teams

Thanks for the reply and link, Jason. We have purchased the Security Suites for SuiteCRM current version, which we have under development. Unfortunately, our production version is SugarCRM 6.1. So the Security Suite version there (10 years ago) has no Hookup in the Admin. Our developer has a lot of custom code for Security Groups, such as group filters in searches, so we hesitate to upgrade at this point (we have 40+ custom modules). Any other suggestions for us based upon this?

Thanks again!

I'll dig up some old documentation tomorrow for manually creating the relationships correctly and send it to you via email. If you don't see anything by end of day please do let me know.

I'm looking forward to it! Thanks for you help!!

Just sent it to you.

Thanks! I'm looking at it now. The custom module relationships have NOT been created in Studio. They look the way you specify in your document page 13. As far as I can tell.

But is this supposed to be this way for the CUSTOM modules, where the relationship name starts with the custom module: $dictionary["cms_inventoryverify_securitygroups"] = array ( 'true_relationship_type' => 'many-to-many', 'relationships' => array ( 'cms_inventoryverify_securitygroups' => array ( 'lhs_module' => 'SecurityGroups', 'lhs_table' => 'securitygroups', 'lhs_key' => 'id', 'rhs_module' => 'CMS_InventoryVerify', 'rhs_table' => 'cms_inventoryverify', 'rhs_key' => 'id', 'join_table' => 'securitygroups_records', 'join_key_lhs' => 'securitygroup_id', 'join_key_rhs' => 'record_id', 'relationship_type' => 'many-to-many', 'relationship_role_column' => 'module', 'relationship_role_column_value' => 'CMS_InventoryVerify', ), ), );

Whereas in the SUGAR modules the relationship starts with securitygroups in the relationship name? Does that matter?

'securitygroups_leads' => array(
        'lhs_module'=> 'SecurityGroups', 'lhs_table'=> 'securitygroups', 'lhs_key' => 'id',
        'rhs_module'=> 'Leads', 'rhs_table'=> 'leads', 'rhs_key' => 'id',
        'relationship_type'=>'many-to-many',
        'join_table'=> 'securitygroups_records', 'join_key_lhs'=>'securitygroup_id', 'join_key_rhs'=>'record_id',
        'relationship_role_column'=>'module','relationship_role_column_value'=>'Leads'),

This is how it is set up in our Sugar6.1 now. None of my custom modules display the pop up when multi group user creates and SELECT POP UP is the setting.

Thanks so much!

Some of the custom modules actually do have the pop up when there is a Division assigned due to a related field being selected during Create of the custom module. But custom modules that have no related record are the ones that are having the issue of permission and no pop up. I'm going to examine specifically those modules. Here is one of them: $dictionary["cms_citypermits_securitygroups"] = array ( 'true_relationship_type' => 'many-to-many', 'relationships' => array ( 'cms_citypermits_securitygroups' => array ( 'lhs_module' => 'SecurityGroups', 'lhs_table' => 'securitygroups', 'lhs_key' => 'id', 'rhs_module' => 'CMS_CityPermits', 'rhs_table' => 'cms_citypermits', 'rhs_key' => 'id', 'join_table' => 'securitygroups_records', 'join_key_lhs' => 'securitygroup_id', 'join_key_rhs' => 'record_id', 'relationship_type' => 'many-to-many', 'relationship_role_column' => 'module', 'relationship_role_column_value' => 'CMS_CityPermits', ), ), );

Have a great Holiday weekend! I'll be back at it on Tuesday. :)

I also test the Cases subpanel Create a Case from the Accounts module, and I get this same behavior for the popup. It does NOT pop up after the Case is saved. Instead it pops up after I go back in and view or edit the Cases for the Account. Thanks again!

There is a global logic hook found at custom/modules/logic_hooks.php that calls modules/SecurityGroups/AssignGroups.php->popup_select() in an after_save hook. Somewhere along the way it's either failing to get in AssignGroups or something within that class isn't working well with your instance.

I think my Cases issue is that the Cases module was customized to have a flex relate field. Each custom module which is related to the Cases has an issue. When attempting to create a Case in the subpanel, there is no GROUP related (even though the custom module is the parent and the PARENT_ID is populated). The create from the Cases module works fine. THe pop up appears there. It's the Cases subpanel for these custom modules using custom flex quickcreate that is an issue. There, the pop also does NOT appear. So there is no GROUP when the Case is created. Only when going back into view or edit the Case will the pop up appear. Is there something particular for the custom flex relate I should check? This would be the PARENT setting. Something isn't working with that for our custom modules. As long as the related parent custom module GROUP is updated when creating the Case via subpanel, I don't think it's necessary for the pop up to select. The problem is that NEITHER is happening here.

Sorry for the long post.

I still don't have an answer either on my other custom modules with the permission / access issues.

Any code you could direct me to would be most helpful!

Sounds like a tough one! I suggest working backwards within the files I mentioned earlier and debug why it isn't getting into the logic to trigger the popup. My personal favorite technique is to just add fatal() debug statements along with variable values to see why it is working in general and not for specific cases for you. My guess is that the after_save hook isn't being called due to an exit() call in some other hook.

It looks like my Parent inherit has an issue from the Cases subpanel in my custom miodule. The module to relate GROUP from has the relationship name instead of the module name from Security Group records. How is this passed from the created record to SecurityGroup.php?

SecuritySuite: Inherit from Parent: insert into securitygroups_records(id,securitygroup_id,record_id,module,date_modified,deleted) select distinct uuid() ,r.securitygroup_id,'7c0018aa-c12b-9afa-beea-5f0645abfdd4','Cases',CURDATE(),0 from securitygroups_records r inner join securitygroups g on r.securitygroup_id = g.id and g.deleted = 0 and (g.noninheritable is null or g.noninheritable <> 1) left join securitygroups_records d on d.securitygroup_id = r.securitygroup_id and d.record_id = '7c0018aa-c12b-9afa-beea-5f0645abfdd4' and d.module = 'Cases' and d.deleted = 0 where d.id is null and r.module = 'cms_sites_cases' and r.record_id = '36' and r.deleted = 0

the relationship is cms_sites_cases, but the module is CMS_Sites

Thanks so much, Jason!

Maybe what I really need to ask is how do I get the Parent Inherit GROUP to work in a custom FLEX RELATE field on Cases subpanel? That's my biggest issue right now. The module being populated in the Inherit Parent SGR query is using the relationship name instead of the parent module name, so the SGR doesn't get created. How do I fix this? I've included Accounts and Contacts, in addition to my custom modules, in the flex relate type and those don't work right either when creating a Case from the subpanel. Thanks again!

The flex relate defines who the parent of the Case is?

I don't have an exact answer, but I suggest outputting the REQUEST var in SecurityGroup.php->inherit_parent() to see what variables are set. Then alter the if statement to get into the inherit logic to support your flex relate.

$GLOBALS['log']->fatal(print_r($_REQUEST,true));

Save a new case and see what is in sugarcrm.log

Yes, that is correct that the flex relate define the parent of the Case. That query that I posted 16 hours ago is in the log from the Inherit Parent Query function. I had also posted the $parent_type to the log and confirmed that.

This is the output from in that function before it performs the Inherit Parent Query function. Thu Jul 9 10:15:51 2020 [23425][c85680e3-8cbb-c73c-1488-5c537c9d083e][FATAL] Array ( [module] => Cases [record] => [isDuplicate] => false [action] => Save [return_module] => CMS_Sites [return_action] => DetailView [return_id] => 36 [module_tab] => [contact_role] => [relate_to] => cms_sites_cases [relate_id] => 36 [offset] => 1 [full_form] => full_form [name] => test case in site again 7.9.20 [status] => New [type] => Bin Graffiti [parent_type] => CMS_Sites [parent_name] => 36 - Agape Presbyterian Church [parent_id] => 36 [assigned_user_name] => Lucy - ALL Najera [assigned_user_id] => c85680e3-8cbb-c73c-1488-5c537c9d083e [description] => [resolution] => [button] => Save [__utmc] => 226962713 [__utmz] => 226962713.1580235068.28.9.utmcsr=cms.usagain.com|utmccn=(referral)|utmcmd=referral|utmcct=/index.php [__utma] => 226962713.1275433274.1557249853.1585920474.1587153531.35 [ck_login_language_20] => en_us [timezone] => America/Chicago [cms_Bin_Refurbish_divs] => securitygroups_v=# [Tasks_divs] => securitygroups_v=# [Users_divs] => securitygroups_v=# [CMS_Inventory_divs] => securitygroups_v=# [CMS_Receiving_divs] => cms_inventory_v=#securitygroups_v=# [Leads_divs] => securitygroups_v=# [ck_login_theme_20] => Sugar5 [Documents_divs] => securitygroups_v=# [session_locale] => en [Meetings_divs] => securitygroups_v=# [Notes_divs] => securitygroups_v=# [Opportunities_divs] => securitygroups_v=# [Calls_divs] => securitygroups_v=# [Cases_divs] => securitygroups_v=#history_v=# [ModuleBuilder] => helpHidden=true [CMS_Shipping_divs] => securitygroups_v=# [CMS_Bins_divs] => cms_binstatus_v=#cms_collections_v=# [Contacts_divs] => securitygroups_v=# [CMS_RouteSchedules_divs] => securitygroups_v=# [CMS_Collections_divs] => securitygroups_v=# [CMS_Scanners_divs] => securitygroups_v=# [ProspectLists_divs] => securitygroups_v=# [CMS_SiteCharities_divs] => securitygroups_v=# [CMS_Parents_divs] => securitygroups_v=#cms_sites_v=# [CMS_TerritoryZips_divs] => securitygroups_v=# [CMS_Processing_divs] => securitygroups_v=# [CMS_InventoryVerify_divs] => securitygroups_v=# [cpsession] => :VVQwyz05Ob70Jul1,5155b4889de73dffa8f55b8501326f21 [CMS_Sites_divs] => securitygroups_v=#history_v=#cases_v=#tasks_v=# [PHPSESSID] => e5584f624986ef30f39f26c25b0ed63c [ck_login_id_20] => c85680e3-8cbb-c73c-1488-5c537c9d083e )

Should the relate_to be CMS_SITES, to find the Site's GROUP to relate to the Case, since that is also the parent_type? Instead it is using the cms_sites_cases.

Thanks!

relate_to and relate_id are the keys.

You'll see a section similar to below in that inherit function. Put this above the others that look like this:

            if((empty($parent_type) || empty($parent_id)) && isset($_REQUEST['relate_to']) && isset($_REQUEST['relate_id'])) {
                $parent_type = $_REQUEST['relate_to'];
                $parent_id = $_REQUEST['relate_id'];
            }

This is not upgrade-safe so be sure to document this somewhere so that you can include it back in after updating your CRM and/or SecuritySuite.

Best of luck!

So in the above array, the relate_type is not accurate. The parent_type is accurate. I'm not seeing this code working that I insert above the other code there. Am seeing same results.

Am I missing something?

Here's the function - did I insert code wrong?

function inherit_parent(&$focus,$isUpdate)
{
    global $sugar_config;
    //new record or if update from soap api for cases or bugs
    //TEST FOR PORTAL NOTES
    //if((!$isUpdate || ($isUpdate && !empty($focus->note_id) && ($focus->object_name == "Case" || $focus->object_name == "Bug")))
    if(!$isUpdate
        && isset($sugar_config['securitysuite_inherit_parent']) && $sugar_config['securitysuite_inherit_parent'] == true) {

        $focus_module_dir = $focus->module_dir;
        $focus_id = $focus->id;

        //inherit only for those that support Security Groups
        $groupFocus = new SecurityGroup();
        $security_modules = $groupFocus->getSecurityModules();
        if(!in_array($focus_module_dir,$security_modules)) {
            return; //don't inherit for this module
        }

        //from subpanel
        //PHP Notice error fix
        $parent_type = "";
        $parent_id = "";

** //CH 7.9.20 NOT UPGRADE SAFE - provided by Jason to fix Cases subpanel issue if((empty($parent_type) || empty($parent_id)) && isset($_REQUEST['relate_to']) && isset($_REQUEST['relate_id'])) { $parent_type = $_REQUEST['relate_to']; $parent_id = $_REQUEST['relate_id']; }

        //CH 7.9.20 END**

        if(isset($_REQUEST['relate_to']) && isset($_REQUEST['relate_id'])) {
            $parent_type = $_REQUEST['relate_to'];
            $parent_id = $_REQUEST['relate_id'];
        }

        if(isset($_SESSION['portal_id'])) {
            $parent_id = $_SESSION['user_id']; //soap stores contact id in user_id field
            $parent_type = "Contacts";
        }   

        //from activity type creation
        if((empty($parent_type) || empty($parent_id)) && isset($_REQUEST['parent_type']) && isset($_REQUEST['parent_id'])) {
            $parent_type = $_REQUEST['parent_type'];
            $parent_id = $_REQUEST['parent_id'];
        }   

        //full form from subpanel
        if((empty($parent_type) || empty($parent_id)) && isset($_REQUEST['return_module']) && isset($_REQUEST['return_id'])) {
            $parent_type = $_REQUEST['return_module'];
            $parent_id = $_REQUEST['return_id'];
        }   
        **$GLOBALS['log']->fatal(print_r($_REQUEST,true));**








        /** need to find relate fields...for example for Cases look to see if account_id is set */
        //allow inheritance for all relate field types....iterate through and inherit each related field
        //if(empty($parent_type) || empty($parent_id)) {
            foreach($focus->field_name_map as $name=>$def) {

               if($def['type']=='relate' && isset($def['id_name']) 
                    && isset($def['module']) && strtolower($def['module']) != "users" ) {

                    if(isset($_REQUEST[$def['id_name']])) {
                        $relate_parent_id = $_REQUEST[$def['id_name']];
                        $relate_parent_type = $def['module'];

                        SecurityGroup::inherit_parentQuery($focus, $relate_parent_type, $relate_parent_id, $focus_id, $focus_module_dir);
                    } else if(isset($_SESSION['portal_id']) && isset($_SESSION[$def['id_name']])) { //catch soap account
                        $relate_parent_id = $_SESSION[$def['id_name']];
                        $relate_parent_type = $def['module'];

                        SecurityGroup::inherit_parentQuery($focus, $relate_parent_type, $relate_parent_id, $focus_id, $focus_module_dir);
                    }
               }
            } 
        //}

        if(!empty($parent_type) && !empty($parent_id)) { // && $parent_type != "Emails" && $parent_type != "Meetings") {
            SecurityGroup::inherit_parentQuery($focus, $parent_type, $parent_id, $focus_id, $focus_module_dir);
        } //end if parent type/id

            **$GLOBALS['log']->debug("SG: NOT empty parent if gets here: $parent_type");**


    } //end if new record
}

//need to find out why the parent_type would be INVALID here 7.8.20 CH --- for Cases in Site it is cms_sites_cases which is relationship instead of MODULE! //

So sorry to keep troubling you with this, but I, like you, just need this to be resolved. A new CENTRALIZED (this MULTI GROUP USERS) will be counting on this to enter Cases. THANKS!

Maybe I should try to use this code (replace between the PHP notice code and the portal) from the SuiteCRM SecuritySuites code that I have?

        if(isset($_REQUEST['relate_to']) && isset($_REQUEST['relate_id'])) {
            //relate_to is not guaranteed to be a module name anymore.
            //if it isn't load the relationship and find the module name that way
            if(!in_array($_REQUEST['relate_to'],array_keys($security_modules))) {
                //check to see if relate_to is the relationship name
                require_once('modules/Relationships/Relationship.php');
                $rel_module = Relationship::get_other_module($_REQUEST['relate_to'], $focus_module_dir, $focus->db);
                if(isset($rel)) {
                    $parent_type = $rel_module;
                    $parent_id = $_REQUEST['relate_id'];
                }
            } else {
                $parent_type = $_REQUEST['relate_to'];
                $parent_id = $_REQUEST['relate_id'];
            }
        }

Keep in mind I have a very old SecuritySuites 2.2 in my Sugar. I'm sure that throws debugging off.

It seems like that code did the trick!! YAY!!!

Nicely done!

Thank you SO MUCH for all of your help!

I'm wondering if my remaining issue with the custom modules and no pop up, access/permission error could be resolved with any updated code from AssignGroups in the Suite version since I do have the SecuritySuites 2.2. I know there isn't really a true pop up in the SuiteCRM the way there is in Sugar., so there are some differences. Any insight would be appreciated.

You suggest 'isn't working well with our instance', such as some kind of javascript race condition causing a timing issue? One of the custom modules where we get the permission/access error doesn't even have any logic hook. It is getting to AssignGroups from what I see. But we get that access/permission error and it returns to the 'home' module (which we set as a custom module - is that an issue?) When the user goes back to the custom module where they tried to create a record then the mulit group popup to select appears. Is it in the Security Suite module where the access/permission error is generated?

I'm also wondering if I can disable the popup when the Group is assigned based on the parent. Is the design when both POP UP SELECT for multi group user AND Inherit Parent are both set in Group Settings, that the Inherit Parent FIRST gets processed and then after that the POP UP?

Thanks again!

This was in reply to your previous comment: There is a global logic hook found at custom/modules/logic_hooks.php that calls modules/SecurityGroups/AssignGroups.php->popup_select() in an after_save hook. Somewhere along the way it's either failing to get in AssignGroups or something within that class isn't working well with your instance.

I doubt it's a race condition. I just don't think it's getting to the AssignGroups logic hook like a normal process does. This seems very contained to your instance, relating to how things work in your heavily customized version. What I suggest is doing some dirty debugging to find why it isn't getting to the logic hook like it does normally.