"Name" in list views sorts by "Last name". How can I change that?

[pgr]

Eheh it’s been a long while since I actually made a question in these forums, I figure the community owes me an answer or two so let’s try my luck…

In the Contacts list view, and in any Contacts subpanel (for example, under Accounts), there is a field called “Name” which seems to be a special field, combining the First Name and the Last Name fields from the Contact.

Whenever I sort by this field, it sorts by Last Name, which is a bit weird when my Names are displayed with first-name-first (“John Doe”, not “Doe, John”).

So this is what a sorted list looks like (data from the demo):

Clement Abston
Vivian Apgar
Beverley Apperson
Shawna Armor
Billy Attebery
Rick Baillargeon

You get the point: it’s sorting by Last Name, but producing a weird, un-intuitive list in the process.

My question: how do I change this and make it sort by the full Name as it is displayed (first name + last name)?

SuiteCRM 7.8.7 on PHP 7.0 on Ubuntu 16.04, but any version will show this issue, really.

[amariussi]

Just a quick tip:
Under the “Advanced” tab in edit mode of the user profile you can select the way in which names are displayed:

(at least it’s not “weird”)

Additionlally you should be able to change it in config.php (or override) by modifying:

‘default_locale_name_format’ => ‘s f l’,

where (I beleieve): ‘s f l’ are for title, first and last name

With respect to how to change the sorting, I found the following piece of code in utils.php:

        //get the user preference for name formatting, to be used in order by
        $order_by_string = ' user_name ASC ';
        if (!empty($current_user) && !empty($current_user->id)) {
            $formatString = $current_user->getPreference('default_locale_name_format');

            //create the order by string based on position of first and last name in format string
            $order_by_string = ' user_name ASC ';
            $firstNamePos = strpos($formatString, 'f');
            $lastNamePos = strpos($formatString, 'l');
            if ($firstNamePos !== false || $lastNamePos !== false) {
                //its possible for first name to be skipped, check for this
                if ($firstNamePos === false) {
                    $order_by_string = 'last_name ASC';
                } else {
                    $order_by_string = ($lastNamePos < $firstNamePos) ? 'last_name, first_name ASC' : 'first_name, last_name ASC';
                }
            }
        }

(In the version I searched id it’s ath line 691 but I didn’t check which version it is but I am pretty sure you will find it.)

I believe that this is where the job is done.

Possibly we could add an extra config variable and manage it from here. It should be quite easy.

Currently config allows only the way the name is displayed. Changing also the order would be an improvement and would provide higher flexibility.

[amariussi]

Hmm…

Maybe I was too quick in my previous response.

I now searched for a few more strings:
last_name ASC
last_name

I found another intersting piece of code in include/ListView/ListView.php:

		// Bug 8139 - Correct Subpanel sorting on 'name', when subpanel sorting default is 'last_name, first_name'
		if (($this->sortby == 'name' || $this->sortby == 'last_name') &&
			str_replace(' ', '', trim($subpanel_def->_instance_properties['sort_by'])) == 'last_name,first_name') {
			$this->sortby = 'last_name '.$this->sort_order.', first_name ';
		}

I also found the following in include/ListView/ListViewData.php:

		// If $params tells us to override for the special last_name, first_name sorting
		if (!empty($params['overrideLastNameOrder']) && $order['orderBy'] == 'last_name') {
			$orderBy = 'last_name '.$order['sortOrder'].', first_name '.$order['sortOrder'];

I haven’t done any testing yet but maybe one of these is the place where things should be changed for list views in general.

[pgr]

Thank you amariussi!

It’s funny, I hacked the code in all the three places you listed to make it always sort by “first_name, last_name”, unconditionally, and the behaviour hasn’t changed.

I’m starting to believe this is a bug, because there is so much code in SuiteCRM to handle this case, and yet none of it ends up having an effect.

I’m using the Contacts list view to test. I wonder if it has some overriding List View, and ignores the code from the generic List View…?

[pgr]

It’s working well in the Contacts subpanel showing under Accounts, though.

[amariussi]

If you modify cache/modules/Contacts/Contactvardefs.php in the section of code:

    'name' => 
    array (
      'name' => 'name',
      'rname' => 'name',
      'vname' => 'LBL_NAME',
      'type' => 'name',
      'link' => true,
      'fields' => 
      array (
        0 => 'first_name',
        1 => 'last_name',
      ),
      'sort_on' => 'first_name',  // <--- I canged last_name with first_name here
      'source' => 'non-db',
      'group' => 'last_name',
      'len' => '255',
      'db_concat_fields' => 
      array (
        0 => 'first_name',
        1 => 'last_name',
      ),
      'importable' => 'false',
    ),

This will work without doing a quick repair and rebuild or any other repair.

Unfortunately this is a generated file so we are bound to lose the changes made here pretty soon.

Did you rebuild before trying?

I am trying to find where is this file generated to understand where it takes the info. Probably from modules/Contacts/vardefs.php I assume.

[pgr]

I’ve spent the last hour trying to fix this, nothing worked (with plenty of rebuilds in between).

I think your tip finally put me in the right direction. That cache file is coming from here:

include/SugarObjects/templates/person/vardefs.php

Changing the sort order there, fixed the Contacts list view, after a Rebuild…

Thanks a lot! This was harder than I initially thought.

Now I wonder how could we make this more intelligent and recognize the user’s options dynamically. I definitely think this deserves to be called a bug!

[amariussi]

I tried also include/SugarObjects/person/vardefs.php the QRR but nothing.

[pgr]

That is very strange…

I changed about 10 different places in the code in my attempts. I’m not sure if there could be some strange interaction between these changes and this final change? Or perhaps other customizations you have in place that override this change?

[amariussi]

I looked (quickly) into many files and I didn’t find a place where to override it. The only place seems to be at the source in include/SugarObjects/person/vardefs.php

Maybe we can add some code that takes into consideration a config variable.

If we want to go further we can also add the extra cod to modify it from Admin.

Additionnally, but this may require more thought, we may add one extra config variable so that the sort order could be decided directly from the ListView (I mean instead of the up / dow arrow under name, we could have to sets of these arrows under name: one for first_name and another for last_name)

If we do the above we may go even firther and add an extra config option letting each user decide whether he wants to have this option or displayed or not.

[pgr]

Of course all those options would be interesting, but I fear nobody will have time or motivation to program them…

Maybe a simple approach would suffice: sort what is being shown. That’s what a user expects when he sees a list of values and asks the computer to sort them.

Since we already have options to configure what is being shown (David Livingstone VS. Livingstone, David), SuiteCRM should simply sort according to that.

Note that my sort is currently fixed, but only partially: it sorts by first_name, when in reality it should be sorting by CONCAT(first_name, ’ ', last_name).

[amariussi]

I realised that this vardefs.php has a ‘name’ and a ‘full_name’.

Now I changed both and it works.

I will test more to understand what happens by modifying just one.

By the way, which did you modify?

[pgr]

I changed only “name”, I hadn’t noticed there was a “full_name” also.

BTW, I also didn’t override “include/SugarObjects/person/vardefs.php” in custom, I edited the original file, which is not upgrade-safe

[amariussi]

Maybe we can try adding in config.php or override:

$dictionary['Contact']['fields']['name']['sort_on']='first_name';

I haven’t tried it yet

[amariussi]

I did three tests in config_override, each followed by QRR + clear cache:

$dictionary['Contact']['fields']['name']['sort_on']='first_name';
$dictionary['Contact']['fields']['full_name']['sort_on']='first_name';
$dictionary['Contacts']['fields']['name']['sort_on']='first_name';
$dictionary['Contacts']['fields']['full_name']['sort_on']='first_name';

The lisview is displayed with blank values only

$dictionary['Contact']['fields']['name']['sort_on']='first_name';
$dictionary['Contact']['fields']['full_name']['sort_on']='first_name';

Same result as above

$dictionary['Contacts']['fields']['name']['sort_on']='first_name';
$dictionary['Contacts']['fields']['full_name']['sort_on']='first_name';

The list view is displayed normally

Conclusions:
Probably something is happening. Maybe I did something wrong, but the fact that the list view is there but the avlues (all) are blank means that what’s happening is the wrong thing.
I was expecting to get something using ‘Contact’ but, instead something happening using 'Contacts.

Any othe ideas?’

[pgr]

I followed this tutorial
http://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_6.5/Extension_Framework/Extensions/Vardefs/#Overriding_an_existing_Vardef

I was able to do it in a new file called

custom/Extension/modules/Contacts/Ext/Vardefs/name_sort_fix.php

Containing this

<?php
$dictionary['Contact']['fields']['name']['sort_on'] = 'first_name';
?>

Notice module name is singular: “Contact”. Do a QRR and refresh the Contacts Listview page.

It works. But there is still only one problem, though not very significant: the original view is still not correctly sorted, only after clicking the column header to sort ascending or descending. This is because the above setting is affecting the javascript in the column header correctly, but not the other code that runs when the view opens.

But since it seems SuiteCRM remembers these sorting options when you go back to that view, this is not very important…