In a nutshell, Employees are a representation of the various individuals that work at your organization. In some cases (maybe all), those same individuals are also SugarCRM users, but it is not mandatory. Users, on the other hand, are a representation of all the individuals that have access to the SugarCRM system. Note that anyone defined as a User is also automatically added to the Employees list -- which is often the reason why confusion creeps in when discussing this topic.
Another important difference between the two is that of the two, data can only be assigned to a User but not to an Employee. These subtle differences are specially important on commercial deployments (Professional, Enterprise Editions) as User counts are limited by the number of licenses one has purchased.
But what happens if one had a need to assign data to an Employee, for reference purposes?
Say for example that we are using the Bug Tracker module to log product flaws, but the developers that are responsible for handling them are not SugarCRM users.
Normally one would address these scenarios by simply accessing the Studio customization tool and creating a relate field in the corresponding module, related to the module containing the data from which one will pick an entry. In this example, following this logic would lead us to want to create a relate field on the Bug Tracker module, and relate the field to the Employees module.
Were one to try it, one would notice that the Employees module is not a choice for the relate field properties, thus, it is not possible -- at least via Studio.
To create this type of field we need to define it via manual changes to the Bug Tracker module. In this particular case, it is a modification to the module's structure, and will be added to the vardefs.ext.php file.
So, what do we need to put into the vardefs.ext.php file? Here it is:
<?php
$dictionary["Bug"]["fields"]["assigned_employee_c"] = array (
'required' => false,
'source' => 'non-db',
'name' => 'assigned_employee_c',
'vname' => 'Employee',
'type' => 'relate',
'massupdate' => 0,
'comments' => '',
'help' => '',
'importable' => 'true',
'duplicate_merge' => 'disabled',
'duplicate_merge_dom_value' => '0',
'audited' => false,
'reportable' => true,
'calculated' => false,
'len' => '255',
'size' => '20',
'id_name' => 'employee_id_c',
'ext2' => 'Employees',
'module' => 'Employees',
'rname' => 'name',
'quicksearch' => 'enabled',
'studio' => 'visible',
);
$dictionary["Bug"]["fields"]["employee_id_c"] = array (
'required' => false,
'name' => 'employee_id_c',
'vname' => '',
'type' => 'id',
'massupdate' => 0,
'comments' => '',
'help' => '',
'importable' => 'true',
'duplicate_merge' => 'disabled',
'duplicate_merge_dom_value' => 0,
'audited' => false,
'reportable' => true,
'calculated' => false,
'len' => 36,
'size' => '20',
);
?>
Next, save the vardefs.ext.php file we just created within the following directory:
custom/Extension/modules/Bugs/Ext/Vardefs/
Now we need to perform a repair in order to instruct SugarCRM to apply these changes. This is accomplished via Admin > Repair > Quick Repair and Rebuild. The process will prompt us to click Execute to apply the field. Proceed to do so to finalize the change.
After the repair process successfully finishes, proceed to use the Studio tool to add the Employee field to the EditView and any other relevant layouts and deploy the changes.
If all went well, the Employee relate field should now be functional. Assuming the field was added to the EditView, one can test it by creating a new Bug. Give it a try.
This comment has been removed by the author.
ReplyDeleteThanks Angel - great tip. Is it possible to Relate to a Role or Team in the same way?
ReplyDelete@Big Allan:
ReplyDeleteApologies, but I am not sure I understand what you are trying to accomplish.
The equivalent for Teams is already built in and can be enabled for custom modules one might build.
With regards to a role, they only have relevance when it comes to users. i.e. One doesn't assign a role to a contact record or other data.
@ Angel
ReplyDeleteThe question was not related to the use case you presented. It was actually just to verify if is possible to create a relate field to a Team (since it is not possible through Studio or Builder). Of course it is possible to enable Team-based security, but I want to relate a module to a team without it being "Security-related".
@Big Allan
ReplyDeleteIn theory it should work for any module, but I haven't specifically tried it with Teams.
can you please explain the unique/important array_elements that one might need to change to accomplish for other module. i am doing it for project modules(adding accounts relate field to it). In studio, i get the field...so i added it in detail and edit view, but somehow it doesnt store the value in database. the above example u showed i did implement it and it worked well.
ReplyDeletePlease advice.
Thanks!!
@Clicked cliques:
ReplyDeleteYou would need to change the "module" and "ext2" values in the array for the first field definition above (assigned_employee_c).
In using a type relate (instead of link), how would I add the related bug records under the employee? Is a subpanel possible when using a relate field?
ReplyDeleteFound the answer...thought I'd post the link here.
Deletehttp://developers.sugarcrm.com/wordpress/2012/10/08/customizing-the-query-used-for-a-subpanel/
Is there any performance or other issues to consider if 1000's of records are related in this manner versus a "link" field with a relationship definition?
ReplyDeleteApologies, but I don't know. I don't have any relevant performance stats to comment on.
DeleteCertainly the potential exists for it to slow down, but I would think it would be more related to general scalability issues of the server the implementation is sitting on or the SQL database (or server), versus the type of relationship used.
Thanks for the quick reply.
DeleteWhat benefits in your opinion does using a relate field only instead of a link field with a relationship table record have?
Both use a relationship table nowadays, although there was a time when relate fields did work a bit differently than they do today. That being said, I don't think there is much of a difference now, although I haven't spent much time analyzing the internals of each.
DeleteNice work. Thanks.
ReplyDeletehow to add relationship with employee module from other module
ReplyDelete