Mystery of the disappearing display names

[alanms]

One simple question, one slightly stranger mystery.

Simple question: How can I kick Civi into rebuilding a selection of contact's display names? All the other name fields are present and correct, but the display name field has vanished. So for example, when you look at a contact's summary page, the name section is blank, but when you hit edit, the first name and last name are fine. Hitting save rebuilds the display name - but there's hundred so it's not a solution!

Mystery: What could cause a selection of contacts involved in an import to lose their display names, without losing any other fields? e.g. first name, last name - even sort name is there and fine. It's not the first time I've seen this happen either - although this time I can see the event that led to it. I imported a sheet with contact IDs for existing contacts, suffixes and a custom field. The import worked fine, no errors, custom fields and suffixes imported perfectly - but for each and every one, the display name is now the suffix and nothing else.

Any ideas, insights or suggestions?

[Donald Lobo]

Simple Answer: petednz has a sql statement on the forums that does the needful. A search for it via:

http://civicrm.org/civisearch

should find it (or he'll respond with the exact forum post)

Mystery Answer: Its a bug Can you double confirm and reproduce on our sandbox server (http://sandbox.civicrm.org/) and if so, please file an issue. we'll fix for a future release

lobo

[alanms]

Thanks Lobo! I'm glad to hear it's not a feature

I'd already done a few searches and adding in petednz and/or sql hasn't helped find the thread in question: can you remember what the discussion was about? Searches relating to this problem don't find it.

To replicate on the sandbox:
1) Create a contact, First name "Man", Middle name "With No", Last name "Name".
2) Create a CSV of Man With No Name's contact ID and "Mr"
3) Import (dupe check turned off) mapping ID number to Internal Contact ID and "Mr" to prefix.
4) Find "Name, Man" in quick search.
Result: His display name is now simply "Mr". He's no longer Man With No Name, he's now the man with no name.

My man with no name is currently contact ID 109 on the sandbox, import from man.csv

[Donald Lobo]

http://forum.civicrm.org/index.php/topic,14516.15.html

can you file an issue (http://issues.civicrm.org/) and add a link to the forum topic.

thanx

lobo

[petednz]

Lovely example Alan.

[alanms]

I'm afraid that's not the right one Lobo - that fills in sort_name and it's display_name that gets messed up by this bug. Display name is a whole lot trickier to fix with one SQL function, since it needs to look up the suffixes and prefixes by ID from the options table, and it also needs to not freak out on the frequent occasions where these are null.

Urgh... There must be some extractable PHP script somewhere in the CiviCRM save contact function that does this that could be copied and pasted into a specially written for_each loop - any suggestions on where to start looking for this? Contact BAO, core BAO, or the supporting PHP for the contact edit form maybe?

Perhaps just piping all the IDs for the broken contacts into the contact update API function would work, updating nothing or something inconsequential and reversible, as that (I trust...) will trigger the standard save function.

Re. what causes this bug, looking at it, I'd put money (not very much money, but money ) on it turning out that the import script has its own separate display_name generator that uses from import data only, rather than just using the robust existing one after the contact is updated.

[Donald Lobo]

check:

            require_once "CRM/Contact/BAO/Individual.php";
            CRM_Contact_BAO_Individual::format( $params, $contact );

this does most of the work across all cases to set the display name for individual. You'll need to abstract it and use it to do the needful


lobo

[alanms]

No joy with the BAO function so far. From wading through the various functions used to find what kind of data it's expecting to be passed, it looks like passing a valid id as $contact->id alongside passing $params['contact_type'] = "Individual" should be enough, but it has no effect and gives no meaningful feedback.

For this task I'm going to cut my losses and work to the limitations of the bug for now, exporting all the effected names with a contact ID and re-importing them so that the import's display name builder has all four fields handed to it on a plate by the import. Not elegant but it'll have to do to get this done.

Also, it seems the update contact API has the same issue with display names as the import: it only uses data passed to it to generate a display name, ignoring data already there (as of 3.2). To replicate: (not fully tested, I'm trusting create is uniform to update):

Code: [Select]

        require_once 'api/v2/Contact.php';
        $create['contact_type']  = "Individual";
        $create['first_name']     = "Jo";
        $create['last_name']     = "Gregarious";
        $create['suffix_id']     = 1;
        $create['prefix_id']     = 1;
        $create_result = civicrm_contact_create( $create );

        $update['contact_type']  = "Individual";
        $update['contact_id']     = $create_result['contact_id'];
        $update['last_name']    = "Anonymous";
        $update_result = civicrm_contact_update( $update );

Look up Jo and it'll display simply 'Anonymous'.

Bug is in Jira, for both API and import: http://issues.civicrm.org/jira/browse/CRM-7085

[alanms]

p.s., did you ever have a chance to look at a bug related post I put up a while ago, about forms opened in seperate tabs all using the specification of the last tab to be opened? http://forum.civicrm.org/index.php/topic,16000.0.html

Mentioning it here because in doing some exports to CSV to fix this I found (the hard way!) it also applies to exports. For example:-

• Open the 'Basic search' form in two tabs. In one, find some individuals. In the other, find some organisations.
• Select and 'export' individuals. While the wizard loads, do the same with organisations.
• Configure field mappings in one. Export. Configure field mappings in the other. Everything looks fine..
• ...until you open the CSV files and find that both used the search results of the last tab to open. So in this example, your CSV file of exported individuals will have the correct field mapping, but it'll be full of the same set of organisations as the other export

Has this been looked into at all? I couldn't find anything last time I looked - I think my theory was that it was something to do with form submits using session data where I'd have expected them to use variables written in to the form or into a hidden field, but I haven't had time to dig deeply on this one.

Another recent instance I found of this bug is with relationships. Say you have two different contacts open in two tabs, and you add a relationship to each contact, the relationships are both added to the most recent contact.

I'll try to make my next thread something more positive than bug reports!