Including vardef definitions in Extension

👨‍💻 Development Help
1

Hi,

We are adding several custom fields to several of the SuiteCRM core modules. Therefore we are introducing the proper rows into the fields_meta_data db table (as studio does) and defining the properties directly in a file in custom/Extension//Vardefs/ path. We’d like to define all the properties there because we consider it is easier for maintenance, as it is defined in the vardefs.php file in the core module path /module//vardefs.php.

But we realized that, if a property is defined in the Extension/vardef, it won’t be possible to customize it anymore through studio. For example, we have an example custom field in Accounts “test_c” created by studio, with the property definition in custom/Extension/Accounts/Vardefs/example.php, as:

$dictionary[‘Account’][‘fields’][‘test_c’][‘required’]=0;

And repaired.

If an Administrator user tries to modify the behavior of this field, trying to change the require property from studio, it won’t work. Studio will create an empty file in custom/Extension/Accounts/Vardefs and set the column required to 1 in the fields_meta_data database table. It won’t work cause the file created previously from in custom/Extension/Accounts/Vardefs/example.php it has higher priority than any other change.

We understand that we could solve this bringing the definition of the vardef directly to the fields_meta_data table. But we find that this is troublesome to maintain.

Is there any other way to achieve this? Are we missing any point?

Thanks

2

I am not sure I understand how you’re doing it, but just as a clue, does this help?

–> https://docs.suitecrm.com/developer/extension-framework/#_forcing_overrides

3

You can name your file something like below if your field name is test_c

custom/Extension/Accounts/Vardefs/_override_sugarfield_test_c.php

This way studio will pick and update same file.

4

Thank you both, but this doesn’t fully solve what we want to achieve.

@cherub-chum, the _override prefix is working when each of the custom field is defined in a single file, for example _override_sugarfield_test_c.php. And, when a modification in the studio is done, the file will be overwritten by the one created by the studio. This is helpless for us, cause we want to keep the definition files available untouched for future update and maintaining purposes.

@pgr . We aren’t building this for just a single installation of SuiteCRM, but for a pattern that will apply in different instances. Therefore we need a structure that is easy to maintain, upgrade-safe and fully customizable, just as the core vardefs definition are.

Ultimately, what we want to achieve is having the vardefs defined directly in the code. Having an independent definition file for the fields of each module. And this should work on the same way it does with the core field modules, being able to fully customize them from studio.

Right now we have a file with several fields defined in custom/Extension/modules/Accounts/Ext/Vardefs/SinergiacrmVardefs.php

Selection_233
Selection_233672×700 54.6 KB

And, during the installation of a new instance, we also deploy several new rows to the fields_meta_data table:

Selection_232

This works fine BUT, when an Administrator tries to change a property of one of this fields, it won’t work.

Any other idea?

Thanks again.

5

You should not use custom fields rather use Core definitions. That will solve your problem

6

That would be awesome. Although we try to avoid any non upgrade-safe modification.

Is there any way to use Core definitions without overwritting the vardefs.php core files?

7

The path you are using to declare fields is correct.

custom/Extension/modules/Accounts/Ext/Vardefs/SinergiacrmVardefs.php

If you check the vardefs.php of any module, you will find all types of fields that you want to use for your custom changes i.e. varchar, text, int, decimal etc. . Just notice that the source of those fields would not be custom_fields and see how each field is defined.

Here is an example for you for your test field which you can declare inside custom/Extension/modules/Accounts/Ext/Vardefs/SinergiacrmVardefs.php

$dictionary['Account']['fields']['test'] = 
    array (
      'name' => 'test',
      'vname' => 'LBL_TEST',
      'type' => 'varchar',
      'len' => 100,
      'comment' => '',
      'merge_filter' => 'disabled',
      'inline_edit' => '',
      'importable' => 'false',
      'duplicate_merge' => 'disabled',
      'duplicate_merge_dom_value' => '0',
    );
8

Thanks for the suggestion. We will be implementing the solution that you suggested last. We somehow knew this but didn’t consider it until now.

Meanwhile, we have one more question referring the vardefs properties related to this issue:

Having the code that we shared in our last two screenshots, we found that removing the property “custom_module” from a field and its related row in fields_metadata, the field will also have the behavior we were looking for. Then, we got the doubt about: What are the properties “custom_module” and “source” truly doing?

We tried to look through the documentation, but didn’t find any article that would explain those properties. We were using them only cause they were present in the cache-vardefs definitions.

Maybe they won’t be used on most of the contexts but we find that they are important to understand fully the behavior of the vardefs in SuiteCRM.