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

šŸ’¬ General Discussion
1

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:

image
image2538Ɨ398 39.9 KB

Cheers!

2

Hi

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

3

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

 'CONTACTS_GCMP_PROPERTIES_1_NAME' => 
  array (
    'type' => 'relate',
    'link' => true,
    'label' => 'LBL_CONTACTS_GCMP_PROPERTIES_1_FROM_CONTACTS_TITLE',
    'id' => 'CONTACTS_GCMP_PROPERTIES_1CONTACTS_IDA',
    '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',
  'vname' => 'LBL_CONTACTS_GCMP_PROPERTIES_1_FROM_CONTACTS_TITLE',
  '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',
  'vname' => 'LBL_CONTACTS_GCMP_PROPERTIES_1_FROM_CONTACTS_TITLE',
  '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',
  'vname' => 'LBL_CONTACTS_GCMP_PROPERTIES_1_FROM_GCMP_PROPERTIES_TITLE',
);
1 Like
5

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

6

ok i will review this

1 Like
7

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

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

cache/smarty/templates_c/*
cache/themes/SuiteP/*

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
8

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
9

sure,please his code.

10

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.

11

Look what I just foundā€¦

12

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.

13

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));
    }
3 Likes
14

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

15

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