What is missing in my custom field vardef?

Nagy Zoltan

It is not clear from your post so maybe this step has been done but: you cannot create entries in the *_cstm tables using the Extension Vardefs framework. You have to have an entry in the "fields_meta_data" table in the database as well. It is this table that specifies that a field belongs in the *_cstm table. Studio automatically creates this entry when you create a field there. If you just use the Extension Vardefs framework then Sugar will try to add the field to the core table. However, your vardefs explicitly tell it not to do this as you have included the  entry:

$dictionary['Currency']['fields']['c_primary_key_c']['source'] = 'custom_fields';

which tells Sugar the field definition is to be found in "fields_meta_data".

In your snippet, you don't need most of the entries. They should almost all be defined within the entry in the "fields_meta_data" table.

You are able to override existing fields in the *_cstm tables by including entries in a matching Vardefs extension file (if you use Studio you will probably find it also creates one of these as well for a couple of the values that do not appear in the database table definitions).

If you are working On-Cloud and therefore are not able to explicitly use a database INSERT query to create the entry(ies) in "fields_meta_data" then you should use the manifest.php file to create the custom fields entries. Fields defined in the custom fields section of a manifest are created as items in the *_cstm table. Then you can provide a corresponding Vardefs extension file to override any items needed.

I suggest getting a local (maybe from a backup if you are On-Cloud) instance and inspecting the "fields_meta_data" table to see how it is constructed. Check it after adding a field using Studio if you are looking at a clean instance. There are some items in your snippet that are not quite correct for an entry in "fields_meta_data" - specifically the "id" value needs to be unique (globally) so is usually prefixed by the module name in case a field with the same name appears in another module.

Thanks,

JH.

Nagy Zoltan

It is not clear from your post so maybe this step has been done but: you cannot create entries in the *_cstm tables using the Extension Vardefs framework. You have to have an entry in the "fields_meta_data" table in the database as well. It is this table that specifies that a field belongs in the *_cstm table. Studio automatically creates this entry when you create a field there. If you just use the Extension Vardefs framework then Sugar will try to add the field to the core table. However, your vardefs explicitly tell it not to do this as you have included the  entry:

$dictionary['Currency']['fields']['c_primary_key_c']['source'] = 'custom_fields';

which tells Sugar the field definition is to be found in "fields_meta_data".

In your snippet, you don't need most of the entries. They should almost all be defined within the entry in the "fields_meta_data" table.

You are able to override existing fields in the *_cstm tables by including entries in a matching Vardefs extension file (if you use Studio you will probably find it also creates one of these as well for a couple of the values that do not appear in the database table definitions).

If you are working On-Cloud and therefore are not able to explicitly use a database INSERT query to create the entry(ies) in "fields_meta_data" then you should use the manifest.php file to create the custom fields entries. Fields defined in the custom fields section of a manifest are created as items in the *_cstm table. Then you can provide a corresponding Vardefs extension file to override any items needed.

I suggest getting a local (maybe from a backup if you are On-Cloud) instance and inspecting the "fields_meta_data" table to see how it is constructed. Check it after adding a field using Studio if you are looking at a clean instance. There are some items in your snippet that are not quite correct for an entry in "fields_meta_data" - specifically the "id" value needs to be unique (globally) so is usually prefixed by the module name in case a field with the same name appears in another module.

Thanks,

JH.

You should try to avoid creating your own custom fields using the vardefs as there are several caveats:

If your installation does not already contain custom fields, you must manually create the custom table. Otherwise, the system will not recognize your field's custom vardef. This situation is outlined in the following section.
You must run a Quick Repair and Rebuild and then execute the generated SQL after the vardef is installed.
You must correctly define the properties of a vardef. If you miss any, the field may not work properly.
Your field name must end with "_c" and have the property 'source' set to 'custom_fields'. This is required as you should not modify core tables in Sugar and it is not permitted on Sugar's cloud service.
Your vardef must specify the exact indexes of the properties you want to set. For example, use: $dictionary['<module singular>']['fields']['example_c']['name'] = 'myfield_c'; instead of $dictionary['<module singular>']['fields']['example_c'] = array(['name' => 'myfield_c');. This will help prevent the system from losing any properties when loading from the extension framework.
The initial challenge when creating your own custom vardef is getting the system to recognize the vardef and generate the database field. This issue is illustrated with the example below:

This is a copy pate from sugar docs. So you CAN create it in cstm. I will have to look into the fields_meta_data and about that ID thing. Thanks