Thread Details
  • State Verified Answer
  • Replies 2 replies
  • Subscribers 365 subscribers
  • Views 1308 views
  • Users 0 members are here
Forum Actions

Custom Field Type field definition mandatory_fetch not working

Artis Plocins

I have built a Custom Field Type similar to the built-in Relate field which stores a record name and requires two additional custom fields alongside it to store the record ID and module. I have not inherited from the relate field because the functionality doesn't suit my use case.

I have the main field, let's say custom_relate_c which is added to a layout. When it is saved, it also saves values in additional fields created by the Dynamic Field template class TemplateCustomRelate.php called custom_relate_id_c and custom_relate_module_c.

Then, when I reload the view, I can see that only the main field custom_relate_c has been fetched and the other two are not on the model. To get these fields, I have to fetch both of them specifically using fetch again:

model.fetch({fields: [...]})

I have tried adding the mandatory_fetch field definition to the additional ID and module fields, but that never appears in the field definitions when checking on the front end.

I have also tried adding the field definition group on all three fields so that their group is the same: custom_relate_c.

Fetching after the model has been synced in the JS controller is bad because it introduces another delay for displaying the field after the whole view has been rendered fully (apart from my custom field because of this issue).

And, of course, it would also be a bad idea to store all three values concatenated within the main custom_relate_c field itself, because that would not make sense in reports and any other basic functionality.

Note that I save a reference to the names of the additional fields in one field definition related_fields in JSON format, which I parse in the JS controller to get their values from the model.

Could you please share any experience you might have with creating custom field types and ensuring that some fields which are not on the layout are configured to always be fetched?

  • 0

    Hi Artis Plocins,

    Try to check how sugar has manage to get currency_id and 'base_rate' for currency type of field.
    This might be helpful to you for pushing more fields along with your field into the view when your field being render on the view.
    Possibly you just need to pass on record.php like below.

    'related_fields' => array(
        'amount',
        'currency_id',
        'base_rate',
    ),


    Like sugar is doing for currency field like below

    array(
        'name' => 'amount',
        'type' => 'currency',
        'label' => 'LBL_LIKELY',
        'related_fields' => array(
            'amount',
            'currency_id',
            'base_rate',
        ),
        'span' => 6,
        'currency_field' => 'currency_id',
        'base_rate_field' => 'base_rate',
    ),

     

    If need anything else please let us know.

    Thanks

  • 0 in reply to Prashant Patel

    I checked currency.js, TemplateCurrency.php, TemplateCurrencyId.php, SugarFieldCurrency.php and found no reference to the record view or layout and, again, nothing that explains how the currency field ensures the additional fields are always fetched.

    Then I somehow thought of changing my related_fields definition into an array like you showed above. That's how it was in the currency field files too. I moved my JSON data about the related fields into a new definition additonal_fields for my JS controller to use more easily and added this line to get_field_def() in my TemplateCustomRelate.php file:

    $def['related_fields'] = !empty($this->related_fields) ? $this->related_fields : [];

    Then since, in that same file in the save() method I create my additional custom fields, I also set the property on the instance, which, at some point, becomes responsible for permanently providing these custom field names to the related_fields definition:

    $this->related_fields = [$idField->name, $moduleField->name];

    Awesome! Could have been infinitely less painful to find this out. Would be great if it made any sense or had any apparent origin for this behaviour, but at least this one has been busted! Thanks, Prashant Patel for mentioning the currency field and pointing out the realted_fields definition.