Contacts not appearing in ListViews in One-to-Many relationships

Hi all,

I hope you can help me.

We’ve created a custom module called Properties, which has a relationship to the Contacts module. The relationship type is one-to-many. That is, a Property can have one Contact. Whilst a Contact can have many Properties.

All the linking works fine and the linked Contact correctly displays in the Detail View. However, the linked Contact doesn’t appear in the ListView - does anyone know why? Or what needs to be adjusted to make this work?
Here’s a screenshot:



I can’t test right now, but I seem to remember this is done by adding ‘link’ => true, in the list view defs or subpanel defs, something like this

We have very similar, perhaps the same definitions in listgviewdefs.php:

  array (
    'type' => 'relate',
    'link' => true,
    'width' => '10%',
    'default' => true,

And the relevant entries in the vardefs.ext.php are as follows:

// created: 2023-06-22 10:01:53
$dictionary["gcmp_Properties"]["fields"]["contacts_gcmp_properties_1"] = array (
  'name' => 'contacts_gcmp_properties_1',
  'type' => 'link',
  'relationship' => 'contacts_gcmp_properties_1',
  'source' => 'non-db',
  'module' => 'Contacts',
  'bean_name' => 'Contact',
  'id_name' => 'contacts_gcmp_properties_1contacts_ida',
$dictionary["gcmp_Properties"]["fields"]["contacts_gcmp_properties_1_name"] = array (
  'name' => 'contacts_gcmp_properties_1_name',
  'type' => 'relate',
  'source' => 'non-db',
  'save' => true,
  'id_name' => 'contacts_gcmp_properties_1contacts_ida',
  'link' => 'contacts_gcmp_properties_1',
  'table' => 'contacts',
  'module' => 'Contacts',
  'rname' => 'name',
  'db_concat_fields' => 
  array (
    0 => 'first_name',
    1 => 'last_name',
$dictionary["gcmp_Properties"]["fields"]["contacts_gcmp_properties_1contacts_ida"] = array (
  'name' => 'contacts_gcmp_properties_1contacts_ida',
  'type' => 'link',
  'relationship' => 'contacts_gcmp_properties_1',
  'source' => 'non-db',
  'reportable' => false,
  'side' => 'right',
1 Like

I’m not certain how helpful that is. Can you please review the code that I pasted and identify any issues with it.

ok i will review this

1 Like

@GCDimitry have you done a Admin / Repair / Repair Relationships? Sometimes that helps.

Also, make sure you delete the compiled tpl files from cache directory.


If that doesn’t solve it, I think it’s better to try and set some breakpoints to see what’s happening. Do you have a debugger set up on that system? Like XDEBUG + some IDE?

1 Like

None of that helped. I did however note that this line:

'rname' => 'name',

is referring to a field that’s not there defined in the Contacts table. If I change it to anything that is actually present, such as “first_name”:

'rname' => 'first_name',

The Contact column populated correctly. I presume because it now has a valid field.

It would be good to work out if it’s the relationship generator that is creating an incorrect entry OR is it something that our team did incorrectly. Is there a reference to generation sequence for varchars that I can review?

So far I’ve traced it to public/legacy/custom/Extension/modules/gcmp_Properties/Ext/Vardefs/contacts_gcmp_properties_1_gcmp_Properties.php - is that file generated by something else? And if so what?

1 Like

sure,please his code.

To see what is being generated, I guess the easy way is to generate again. And check git, if you have the directory under source control, to see what is being changed at each step.

Other than that, the generation process is not very documented. My rule of thumb is this:

  • anything under custom/Extension is original material for the QR&R
  • anything under directories named */Ext/*, as long as it’s not under custom/Extension, is automatically produced material resulting from the QR&R

Note that the “original material” could be either produced manually by a developer, or by SuiteCRM in Studio.

I would not be surprised to find there’s a Studio bug, with that field, because it’s a special field in SuiteCRM - only first_name and last_name exist in the DB, then name exists as a aggregate of both, produced by special cases handled in the code.

Look what I just found…

Yeah, looks like the issue is caused by the studio generator that spawns these relationship definitions. So this fix will only fix specific modules, but won’t fix any custom modules being generated which then have a one-to-many relationship to Contacts.

Probably this will be a generic fix for this issue
File: core/backend/Data/LegacyHandler/BaseListDataHandler.php

     * @param $fieldDefinition
     * @return void
    protected function isNonDbField($fieldDefinition): bool
        $relateBean = BeanFactory::newBean($fieldDefinition['module']);

        if (empty($relateBean)) {
            return true;

        $relateFieldDef = $relateBean->field_defs[$fieldDefinition['rname']] ?? [];
        $relateFieldSource = $relateFieldDef['source'] ?? '';
        $relateFieldConcat = $relateFieldDef['db_concat_fields'] ?? [];

        return empty($relateFieldDef) || ($relateFieldSource === 'non-db'&&empty($relateFieldConcat));

Yeah, that looks great! You should probably replace your fix PR with this.

This solution worked for me, but is there an upgrade safe way to implement it?