CiviCRM Community Forums (archive)

I've run into two problems with using address custom fields:

 1. On importing contacts, when importing an address custom field there is an error and it doesn't work.

    http://issues.civicrm.org/jira/browse/CRM-10822

 2. When editing address custom fields, the previous values are lost

     http://issues.civicrm.org/jira/browse/CRM-11525

I'm wondering if anyone is using custom address fields or could help with tracking the causes & solutions to these problems.

I did quite a bit of work trying to track down problem #1 but couldn't get to the ultimate cause of the problem.

Here are my notes from that effort:

There are two problems:

#1. Contact.php is picking up the wrong field out of the api return array for the custom field value. I don't know if this is a bug for all custom fields or only address custom fields or may only select and/or multi-select custom fields. This causes the message reported above:

Message   explode() expects parameter 2 to be string, array given in /..oursite/www/sites/all/modules/civicrm/CRM/Import/Parser/Contact.php on line 1974.

I was able to fix that error with this line replacement on line 1974:
                        //$mulValues = explode( ',', $formatted[$key] );
                        $mulValues = explode( ',', $formatted[$key]['0'][$key]);

However I'm not sure if that is the best/universal solution or only needed in the special case of address custom fields.

#2. Import/Parser/Contact.php does a bunch of work and then calls _civicrm_api3_custom_format_params($params, $formatted, $extends); to create the $formatted array that is then used to insert or create the data to be imported.

In the custom_XX field within $formatted for address custom fields, the id value is left blank--which is reasonable at this point, since the id is the 'id' (primary id) of the table that holds the address custom data, and the new table row hasn't been created yet so the id doesn't exist.

When Contact.php passes the $formatted array on down the line to save the data, one of the routines fills in the missing entity_id field with the ****contact_id**** rather than the address_id which is needed since this is an address custom field (entity_id for an address custom field is an address_id not a contact_id).

That is what causes the 'db constraint error'.

If you figure out the address_id and fill it in in the id field of $formatted, the sql query then tries to insert on the (id,status) fields which malfunctions because it should be (entity_id, status) instead.

So somewhere along the line, some routine needs to be modified to recognized that an address custom field is being created/updated and use address_id rather than contacdt_id o match with entity_id in the custom data table. I couldn't really figure out where that problem is happening.

we did do a quick check when u filed the earlier issue to see how easy it would be to "fix" import.

It was a fair bit of work, since import for contacts does not handle custom fields for other objects and hence we had to push that one out. If you want to pursue a solution, please ping deepak on IRC next week (he's on vacation this week)

lobo

I've run into two problems with using address custom fields:

 1. On importing contacts, when importing an address custom field there is an error and it doesn't work.

    http://issues.civicrm.org/jira/browse/CRM-10822

 2. When editing address custom fields, the previous values are lost

     http://issues.civicrm.org/jira/browse/CRM-11525

FYI a fix for problem #2 is here--it will be included in 4.3: 

  http://issues.civicrm.org/jira/browse/CRM-11525?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel