"custom" type vardefs.php caveats

bsoremsugar —  January 5, 2011 — 2 Comments

Recently, someone pointed out some strange behavior in using the “custom_type” vardefs.php override. He wanted to use the “custom_type” override in a vardef entry so that he could use the SugarFields framework to customize the listview display of the field value.

Assuming the following vardef definition snippet for a commit_url field in his custom module:


‘commit_url’ =>
array (
‘required’ => false,
‘name’ => ‘commit_url’,
‘vname’ => ‘LBL_COMMIT_URL’,
‘type’ => ‘varchar’,
‘custom_type’ => ‘github’,
‘massupdate’ => 0,
‘comments’ => ”,
‘help’ => ”,
‘importable’ => ‘true’,
‘duplicate_merge’ => ‘disabled’,
‘duplicate_merge_dom_value’ => ’0′,
‘audited’ => false,
‘reportable’ => true,
‘calculated’ => false,
‘len’ => ’255′,
‘size’ => ’20′,
),

He discovered that changes to the edit view for the field value was not being saved. His SugarField code seemed correct (file SugarFieldGithub.php) so we even tried to force setting the value to “FOOBAR!” as shown below:

require_once(‘include/SugarFields/Fields/Base/SugarFieldBase.php’);

class SugarFieldGithub extends SugarFieldBase
{
function getListViewSmarty($parentFieldArray, $vardef, $displayParams, $tabindex)
{
//Custom ListView display here…
}

public function save(&$bean, $params, $field, $properties, $prefix = ”){
$bean->$field = “FOOBAR!”;
}
}

This still did not work. The database table would not save the field value as “FOOBAR!”, but leave it empty instead. It turns out that in SugarBean.php, when the database query is being generated to insert/update the field, the following line of code caused the query to skip the field:


if(isset($this->field_name_map) && !empty($this->field_name_map[$field]['custom_type']))
{
continue;
}

//write db query and execute

The ‘custom_type’ override for the vardefs is used to handle the special relationship saving for the Teams widget. The takeaway to note is that if you use the ‘custom_type’ override you have to manually take the steps to write the value into the database yourself. This could have been done in the save method of the overriding SugarField instance above, but really we just wanted the application to take the edit view textfield value and save it.

In his case, the correct solution was to not use ‘custom_type’, but just a ‘type’ override instead. The ‘dbType’ entry allowed the module to know that this was still a varchar field.


‘commit_url’ =>
array (
‘required’ => false,
‘name’ => ‘commit_url’,
‘vname’ => ‘LBL_COMMIT_URL’,
‘dbType’ => ‘varchar’,
‘type’ => ‘github’,
‘massupdate’ => 0,
‘comments’ => ”,
‘help’ => ”,
‘importable’ => ‘true’,
‘duplicate_merge’ => ‘disabled’,
‘duplicate_merge_dom_value’ => ’0′,
‘audited’ => false,
‘reportable’ => true,
‘calculated’ => false,
‘len’ => ’255′,
‘size’ => ’20′,
),

2 responses to "custom" type vardefs.php caveats

  1. 

    This is kind of problem you have when you work with a software that doesn’t care about developers and documentation. You simply get lost trying to figure out how to do simple things like that.

  2. 

    I searched the wiki, the forum, the web for any documentaion regarding “custom_type” but did not find any. Could you give me a link to the documentation?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s