t - Profile

Doesn't work properly, all records needs tweaking from database

Support December 23rd, 2025 @ 12:19 pm

I figured it out more about this for the edit view for a dyanamic panels configuration record.

So We've using different layouts (edit/detail) for different security groups, this plugin assumes the user would only ever have 1 sets of layouts for any security group (the default one) so for example lets say there are 2 sets of edit and detail view layouts for the Opportunities module. 1 set for 1 security group, and the other set for the other security group, and then there is the default set (edit/detail layouts) for users who are not members of security groups which have a specific layout for the given module.

If you add the grpLayout parameter to your VIDynamicPanelsAllModuleFields entrypoint and set it to the security group ID which has a specific layout for a module it will return the fields which are present in that layout and not the default one. if you provide either an invalid ID or an id of a security group which does not have a specific layout for the module then an empty response is returned. example /index.php?entryPoint=VIDynamicPanelsAllModuleFields&flow_module=Opportunities&grpLayout=some_security_group_id

This works because the grpLayout request parameter is checked within the layout parser and nothing extra needs to be added to the VIDynamicPanels php files

This explains why the fields we are using are not showing up in the configuration (as they are specific to this security group layout) and why we are having to tweak the plugin files like mentioned before.

A proposal to support security groups with their own layouts: You could either add something to your plugins editview to check if a module has a specific view for a security group ahead of time, or you could fire 2 requests to the VIDynamicPanelsAllModuleFields entrypoint 1 which includes the grpLayout, if it returns an empty response then you can get the default layout by omitting the parameter.

This only fixes it on the configuration screen, I imagine there would be some tweaking to be done for the js code which runs on the view. I still stand by not tying users to specific field types though,

if someone wants to use a custom type I don't think they currently could.

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 1:41 pm

it is 100% because you are using getValidFieldsTypes from AOW this function does not support radio buttons / checkboxes dropdown lists or dynamic dropdown lists you should make your own function

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 1:37 pm

I think I've tracked this down. this is due to modules/AOW_WorkFlow/aow_utils.php getValidFieldsTypes

this function does not handle many field types and may not be a good option to rely on. there may be better implementations in later versions of Suite

but essentially I would not rely on getValidFieldsTypes from modules/AOW_WorkFlow/aow_utils.php

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 1:31 pm

I would look over custom/VIDynamicPanels/VIDynamicPanelsFunctions.php and custom/VIDynamicPanels/VIDynamicPanelsModuleFields.php

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 1:13 pm

custom/VIDynamicPanels/VIDynamicPanelsDetailViewCheckCondition.php around line 500

there is a foreach loop going through all the fields for a record type, it then checks the $defaultFields variable against all the fields before adding to to the $defaultFieldsHideArray variable. all this seems to be some kind of sanity check to make sure only fields that exist in variable definitions are considered for the plugin.

because the plugin is unable to properly find all fields for a record type this makes sense why it does not work. after removing the sanity check because VI dynamic panels to fails to find all fields, the hide and show functionality works an unlimited amount of times instead of only for the first time.

Would you like me to go through the code which finds the fields for a record type and hopefully I can help you fix this problem?

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 12:56 pm

so on the second time /index.php?entryPoint=VIDynamicPanelsCheckCondition is called where the conditions are not met (success is set to false)

data['defaultFieldsHideArray']; is empty when it should contain the names of fields to hide by default I am guessing there is an issue with the VIDynamicPanelsCheckCondition entrypoint

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 11:33 am

The first message I've stated I am using version 16.0 which is the latest version listed on this site.

continuing from my issue hide/show only works once. after a field has been hidden once and then reappears, it will not hide again when the conditions are met a second time.

I will test all the above in a brand new CRM system, I will do this when I have a spare moment.

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 10:47 am

actually I think these are placed in the field_show column of the vi_dynamic_panels table

View Comment

Doesn't work properly, all records needs tweaking from database

Support December 15th, 2025 @ 10:43 am

to make a field appear after a condition is met, do I need to create a vi_dynamic_panels_subpanel_module_fields record or a vi_dynamic_panels_fields record?

View Comment

Non-static method SugarView::getBreadCrumbSymbol()

Support September 24th, 2024 @ 12:25 pm

corrected code is as follows: $module_title = join((new SugarView())->getBreadCrumbSymbol(),$new_params);

View Comment

Plugin doesn't select correct layout

Support July 8th, 2024 @ 3:18 pm

I have added the following method to both

custom/VIDynamicPanels/VIDynamicPanelsAllModuleFields.php

and

custom/VIDynamicPanels/VIDynamicPanelsAllModulePanels.php

        function getViewPanels($view, $module)
        {
                require_once &#039;ModuleInstall/PackageManager/PackageManager.php&#039;;
                $lView = strtolower($view);
                $secsuiteproInstalled = false;
                $pm = new PackageManager();
                $installedModulesInfo = $pm->getinstalledPackages();
                foreach ($installedModulesInfo as $installedModuleInfo) {
                        if ($installedModuleInfo[&#039;name&#039;] === "SecuritySuite - Enhanced, Professional, and Enterprise") {
                                $secsuiteproInstalled = true;
                                break;
                        }
                }

                if ($secsuiteproInstalled) {
                        $moduleDirectory = BeanFactory::newBean($module)->module_dir;
//                      $moduleDirectory = (new $module())->module_dir;
                        include "custom/modules/$moduleDirectory/metadata/$securityGroupID/{$lView}defs.php";
                        $editViewPanelArray = $viewdefs[$module][$view]["panels"];
                        $panelArray = $editViewPanelArray;
                        return $panelArray;
                } else {
                        $view_array = ParserFactory::getParser($lView, $module);
                        $panelArray = $view_array->_viewdefs[&#039;panels&#039;];
                        return $panelArray;
                }
        }

This function replaces the parts of the code which gets the panels metadata. it will check if the full version of security suite is installed. if it is then it will use an alternate method to get the view metadata, otherwise it will use the standard method.

I may need to tweak this slightly after battle testing. not sure if I need to do extra handling for default layouts.

View Comment

Compatibility with ParserFactory

Support July 8th, 2024 @ 10:13 am

delimiter*

View Comment

Plugin doesn't select correct layout

Support July 8th, 2024 @ 10:12 am

delimiter*

View Comment

Compatibility with ParserFactory

Support July 8th, 2024 @ 10:12 am

my proposal is to expand the first parameter $view,

this can be both the group id and the view name a colon, pipe, or similar symbol can be used as a delmeter,

and could be called like so:

$view = "2d1f3312-6ca8-1fe6-dc2d-2a645d3d2c23|editview";
$module = "Contacts";
$metadata = ParserFactory::getParser($view, $module);

View Comment

Plugin doesn't select correct layout

Support July 8th, 2024 @ 10:03 am

So far I have made modifications to the JavaScript to send the id of the selected Security Group during the calls to the backend. if no security group is selected it will send null for this parameter.

The PHP code will then be able to use this id to select the correct layout for the view and return the panels and fields within it. first the following needs to be addressed.

the function

function getEditDetailViewFields($view,$module)

makes use of the ParserFactory. SecuritySuite does not override the ParserFactory to make it possible to select the correct layout for a view.

I have reached out to SecurtiySuite to see if they have plans to override the ParserFactory. For the moment until this is addressed, I'll use the ParserFactory if no security group id is returned or if the CRM system is not using the full version of Security Suite otherwise, I will use another method for obtaining a views metadata,

View Comment

Plugin doesn't select correct layout

Support July 4th, 2024 @ 1:27 pm

I am already aware that you are not responsible for any changes I make that break the plugin these changes are for your benefit if you wish to include them with your plugin

View Comment

Plugin doesn't select correct layout

Support July 4th, 2024 @ 1:25 pm

Hi,

Within the CRM it is possible to create different layouts for different security groups containing different fields. Currently when using dynamic panels no matter which security group is selected, the UI will always return the fields and panels that are defined in the default layout.

We would like the list of fields and panels from the layout that would be active with the selected security group.

Screenshot from 2024-07-04 14-20-56.png

View Comment

Updating to Version 15 without losing current settings

Support July 4th, 2024 @ 9:26 am

I would also like to know the correct official way to do this. uninstalling the plugin deletes the relevant tables even when "do not remove tables" is selected.

the only way I've been able to do it successfully is to backup the data in the tables first. and then insert the records after installing the new version

View Comment

Relationship::get_other_module cannot be called statically

Support November 8th, 2023 @ 2:09 pm

I've viewed modules/Relationship/Relationship.php from the SuiteCRM 7.14.0 zip and Relationship::get_other_module is not supposed to be a static method.

View Comment

Installation Guide

Documentation September 4th, 2023 @ 9:55 am

I'd reccomdend when updating the CRM system, 1. check to make sure a version of security suite exists for the version of SuiteCRM you are updating to. 2. uninstall SecuritySuite (make sure not to delete tables), 3. install the SuiteCRM update 4. delete the previous SecuritySuite module 5. upload and install the new SecuritySuite module

6 (optional). if using the bitnami docker images. try to run a couple of Suitecrm versions older than your actual SuiteCRM version. Security Suite as well as SuiteCRM does not work with the PHP handler versions set on the latest versions of these images.

View Comment