Dynamic Panels

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?

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

Hello,

I checked your order history and found that the purchase was made in 2019. Could you please confirm whether you have upgraded the package since then or installed it in a new CRM setup?

Regards,
Variance Infotech PVT LTD

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?

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

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

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.