Related Field not saving

💬 General Discussion
1

I am trying to create a related field on the Users module that allows you to select a location. Here is my custom vardef code:

$dictionary['User']['fields']['building_id'] = array (
      'name' => 'building_id',
      'vname' => 'LBL_BUILDING_ID',
      'type' => 'id',
      'required' => false,
);

$dictionary['User']['fields']['building_name'] = array (
      'source' => 'non-db',
      'name' => 'building_name',
      'vname' => 'LBL_BUILDING',
      'type' => 'relate',
      'inline_edit' => true,
      'reportable' => true,
      'id_name' => 'building_id',
      'module' => 'FP_Event_Locations',
      'table' => 'fp_event_locations',
      'rname' => 'name',
      'studio' => 'visible',
      'link' => 'building_link',
      'source' => 'non-db',
      'side' => 'right',
);

$dictionary['User']['fields']['building_link'] = array (
      'source' => 'non-db',
      'name' => 'building_link',
      'vname' => 'LBL_BUILDING',
      'type' => 'link',
      'link_type' => 'one',
      'side' => 'right',
      'relationship' => 'user_building',
      'bean_name' => 'FP_Event_Locations',
      'module' => 'FP_Event_Locations',
      'id_name' => 'building_id',
);

$dictionary['User']['relationships']['user_building'] = array(
    'lhs_module' => 'Users',
    'lhs_table' => 'users',
    'lhs_key' => 'building_id',
    'rhs_module' => 'FP_Event_Locations',
    'rhs_table' => 'fp_event_locations',
    'rhs_key' => 'id',
    'relationship_type' => 'one-to-many',
);

The building_name field is added to both my edit and detail views.

After doing a rebuild, the field appears, and I am able to select a location, but after saving, the building_id field in the users table ends up being the user id. Can anyone see the problem?

Using 7.11.4

2

Why don’t you just create from Studio. That way the system takes care of the code

3

Well, because I have tried that and then I’ve run into issues with Studio and trying to use studio created fields as related fields in other modules. It does not seem to work. Plus, I’d rather get a handle on how the code works.

4

Just to clarify. From studio you can create Relate fields and also Relationships. Relate field will be created on the module you are inserting it to only. Relationships will create fields depending on the type of relationship you create.

For more code insights, I’ll recommend you to start here:
https://support.sugarcrm.com/files/317538cc-6bff-11e7-916c-067914c4cb97.pdf

Thanks,

AlxGr

5

It works when I create it in Studio but the problem is that I also want to show that field as a related field in Cases, but it does not show up. Also it seems like if you create a related field in Studio it will only ever display the name field of the related record, correct? Well I also need to display other fields from my related records.

Can anyone answer my question?

6

A relate field will be displayed on a the module you create the field and is not a relationship on it self. You are just adding a link to that module B from module A. if you want to see the link on Module B you need to create a relate field on module B pointing to module A. AND it won’t automatically save in both modules unless you do it via workflow or logichooks.

Regarding extra fields from the related record, I have seen some posts were people have achieved it via custom code. Unfortunately, I have no idea on how to do it so food luck.

Thanks,

AlxGr

7

Thank you. I understand now what you are saying about relationships. My relationship should have been in the Locations module, not Users, as it is one location to many users. I am now following this example: https://community.sugarcrm.com/thread/20572

But alas, it is still not saving. I’m not sure what you mean about how it won’t save automatically? All I need is for the building_id to be saved in the Users table, and the correct ID is being received in the POST array. But by the time it gets to the after_save hook it isn’t there. Any more suggestions?

8

OK I have found the source of the problem. In modules/Employees/Save.php: populateFromRow(), there is an array containing the field names that are saved:
$e_fields=array(‘first_name’,‘last_name’,‘reports_to_id’,‘description’,‘phone_home’,‘phone_mobile’,‘phone_work’,‘phone_other’,‘phone_fax’,‘address_street’,‘address_city’,‘address_state’,‘address_country’,‘address_country’, ‘address_postalcode’, ‘messenger_id’,‘messenger_type’);

Adding building_id to this array allows it to be saved.

Looking further in the function, I see that it also saves fields that have the “custom_fields” source. However setting this on the building_id doesn’t seem to do the trick.

I’m not super happy with the solution since I can’t export that as a customization, but at least it works now. I’m still not sure why custom_fields way doesn’t work though.

9

The section for custom fields only calls the SugarField handler’s save function (which I am not sure what it does), it doesn’t seem to affect the e_fields array, which seems to be a list of which fields to copy into the Bean (from $row to $focus).

I really don’t like the inclusion of a list of field names in that part of the code. Fields are supposed to be driven by the vardefs, not hard-coded in arrays…

I think a long time ago when this commit was introduced exactly to improve the way fields are saved

https://github.com/salesagility/SuiteCRM/commit/a72428db3b974ab69bf1cf91ecfa9a85d62b8cda#diff-68f706c7e8e6f2b0b910ab213c9daa1f

maybe that line

$e_fields[] = $fieldName;

shouldn’t have been completely removed from the first “for each”. Maybe in some conditions it should still be executed. But I am unsure about all the different kinds of fields, and I didn’t go check what that “save()” is doing, in order to be able to fix it. Can you figure it out?

10

Yeah, when I put that line back in, the field is saved. But that only works if the field has “source” = “custom_fields”.

Kinda looks like the field list is hard-coded intentionally, for the non-“custom_fields” fields in the Employees module… But yeah, I think you are right and that line should go back in.

11

I spoke too soon. For some reason, the Repair wasn’t initially creating a column in the custom table. So that line is NOT required.

The only issue is that the other fields are hard-coded, but as mentioned, looks like that may have been intentional.

12

En mi caso era un proceso que coloca informaciĂłn sobre el campo, al borrarlo se soluciono el problema