Strange profile auto-population issue in D7/C4

[jaymcgraw]

I've created a profile with primary address, primary email, and primary phone fields. I'm finding in testing that sometimes those fields are not auto-populated for logged in users, even though the logged in user does have a primary address, primary email, and primary phone specified in Civi. The true cause is elusive as it seems to occur when changing location types on these fields, but there's no consistency with it.

I have reproduced this on the demo site.

http://d7.demo.civicrm.org/civicrm/contact/view?reset=1&cid=105

http://d7.demo.civicrm.org/civicrm/profile/edit?gid=10&id=105&reset=1

Anyone else experiencing this?

[petednz]

oddly when i change even one of those profile fields to be 'home' all of them start prefilling - though not sure why you reference
http://d7.demo.civicrm.org/civicrm/contact/view?reset=1&cid=105&context=search as that isn't the logged in person afaik it is http://d7.demo.civicrm.org/civicrm/contact/add?reset=1&action=update&cid=103&context=search

but you seem to have picked up a problem

[jaymcgraw]

Yes, I noticed that when you change the location type on any of those items, that sometimes resolves the issue. Keyword is sometimes and I haven't found consistency. Every time I think I've found the issue, I look and find a result I didn't expect.

Also, yes, you're correct. The example I provided from the demo site is not with the currently logged-in person. In testing on my current site, it IS the authenticated person who is not seeing their profile fields populated, which is what made me discover the issue in the first place.

[jaymcgraw]

Alright, I think I've determined how this is happening within the code.

CRM_Contact_BAO_Contact::getPrimaryLocationType is returning the first location type specified as primary from these objects in this order:

• email
• address
• phone
• im
• openid

And then CRM_Core_BAO_UFGroup::setProfileDefaults uses that to set the default values on any primary fields. The issue is that it uses one location type (based on the first one found in above list) to find and set default values for primary email, address, and phone fields.

As an example, if the email specified as primary has a location type of "Home" and the address specified as primary has a location type of "Work", setting of the default value on the address will be skipped because it's looking to use the "Home" address object to set defaults.

I don't know why it's even looking at the location type. Shouldn't it just ignore the location type and instead focus on finding the object that is set as primary regardless of location type?

[Donald Lobo]

This is a bug and we need to figure out and fix it. This will involve some query stuff. the old behavior is primarily due to the data model we had in the 1.x version of civicrm

The problem is i think its non-trivial, i.e. a bit hard of a fix. u'll need to check and clean up the location type based queries in CRM/Contact/BAO/Query.php

lobo

[jaymcgraw]

After fussing with this for some hours, I've resolved that I simply don't have the capacity to make this happen right now. Filed an issue: http://issues.civicrm.org/jira/browse/CRM-8740

[jaymcgraw]

Just an update on this.

I ended up working around this issue by using the buildForm hook to set (overwrite) the defaults, grabbing the primary values for phone, email, and address via the API.

This still needs to be fixed in Civi, but there's an even larger issue that I had to work through as well. Not only are the defaults not always populating (dependent upon whether all of the location-based fields are of the same location or not), but when submitting the data via the profile, additional records are being created. Here's the scenario:

• Create a profile with "primary" contact fields, such as phone, email, address.
• Find (change) a contact with a primary address or primary email or primary phone that differ in location types. For instance, a primary email specified as "home" and a primary address specified as "work".
• Use the profile to edit the contact. You should see that the defaults do not fill in. Problem #1
• Fill in the SAME exact values as the contact currently shows and submit.
• Go back and look at the contact and you will see there is now at least one duplicate location-based field. In this scenario, since my primary address location type differed from my primary email location type, I end up with 2 addresses, both the same, one for "home" and the other for "work", the "home" now being the primary. Problem #2

Developers: I messed with core code (in a custom code folder of course) to resolve Problem #2. I'm still testing some, but I think I made this work by editing the following (which is definitely not an ideal and therefore I don't think it's helpful to submit a patch).

In CRM_Contact_BAO_Contact::formatProfileContactParams:

Code: [Select]

if ($locTypeId == 'Primary') {
            if ( $contactID ) {
                    $locTypeId = $primaryLocationType;
// Hacked - Inserted the following
if ( is_numeric($locTypeId) && !in_array( $fieldName, $multiplFields ) ) {
$blockName = 'address';
if ( in_array( $fieldName, $blocks ) ) {
$blockName = $fieldName;
}
if ( $blockName == 'address' ) {
$locTypeId = self::getPrimaryLocationType( $contactID, false, 'address' );
} elseif ($blockName == 'phone') {
$locTypeId = self::getPrimaryLocationType( $contactID, false, 'phone' );
} elseif ($blockName == 'email') {
$locTypeId = self::getPrimaryLocationType( $contactID, false, 'email' );
}
$blockName = '';
}
                                    // End Hacked
                } else {
                    $locTypeId = $defaultLocationId;
                }
            }

// Hacked
$count = 1;
// End Hacked

In CRM_Contact_BAO_Contact::getPrimaryLocationType:

Code: [Select]

     // Hacked
      static function getPrimaryLocationType( $contactId, $skipDefaultPriamry = false, $object = null )

if ($object == 'email') {
$query = "SELECT civicrm_email.location_type_id as locationType
FROM civicrm_email
WHERE civicrm_email.is_primary = 1 AND civicrm_email.contact_id = %1";
} else if ($object == 'address') {
$query = "SELECT civicrm_address.location_type_id as locationType
FROM civicrm_address
WHERE civicrm_address.is_primary = 1 AND civicrm_address.contact_id = %1";
} else if ($object == 'phone') {
$query = "SELECT civicrm_phone.location_type_id as locationType
FROM civicrm_phone
WHERE civicrm_phone.is_primary   = 1 AND civicrm_phone.contact_id = %1";
} else {
// End HACKED
        $query = "
SELECT
IF ( civicrm_email.location_type_id IS NULL,
IF ( civicrm_address.location_type_id IS NULL,
IF ( civicrm_phone.location_type_id IS NULL,
   IF ( civicrm_im.location_type_id IS NULL,
   IF ( civicrm_openid.location_type_id IS NULL, null, civicrm_openid.location_type_id)
   ,civicrm_im.location_type_id)
,civicrm_phone.location_type_id)
,civicrm_address.location_type_id)
  ,civicrm_email.location_type_id)  as locationType
FROM civicrm_contact
LEFT JOIN civicrm_email   ON ( civicrm_email.is_primary   = 1 AND civicrm_email.contact_id = civicrm_contact.id )
LEFT JOIN civicrm_address ON ( civicrm_address.is_primary = 1 AND civicrm_address.contact_id = civicrm_contact.id)
LEFT JOIN civicrm_phone   ON ( civicrm_phone.is_primary   = 1 AND civicrm_phone.contact_id = civicrm_contact.id)
LEFT JOIN civicrm_im      ON ( civicrm_im.is_primary      = 1 AND civicrm_im.contact_id = civicrm_contact.id)
LEFT JOIN civicrm_openid  ON ( civicrm_openid.is_primary  = 1 AND civicrm_openid.contact_id = civicrm_contact.id)
WHERE  civicrm_contact.id = %1 ";

}



 

[andersiversen]

Bumped into the same problems - for problem #1 I did the following to set the defaults inside a buildForm hook (in my situation it was the phone and email fields not getting populated):

Code: [Select]

if(is_a($form, 'CRM_Profile_Form_Edit')) {
                $contact_id = $form->getVar('_id');
                $contactArray = array   (
                                        'id' => $contact_id,
                                        'version' => 3
                                        );
                $mycontact = civicrm_api("Contact","get",$contactArray);
                $contact_phone = $mycontact['values'][$mycontact['id']]['phone'];
                $contact_email = $mycontact['values'][$mycontact['id']]['email'];
                $defaults['email-Primary'] = $contact_email;
                $defaults['phone-Primary-2'] = $contact_phone;
                $form->setDefaults($defaults);
        }


[gastrit]

Hi!

I had the same issue when using a profile for letting our members update their contact information. Your two solutions combined solved my problem. I have not tested it thoroughly but it seems to work.

This is my hook (in my own module civicrm_extensions):

Code: [Select]

function civicrm_extensions_civicrm_buildForm($formName, &$form) {
    if(is_a($form, 'CRM_Profile_Form_Edit')) {
        $contact_id = $form->getVar('_id');
        $contactArray = array   (
                                'id' => $contact_id,
                                'version' => 3
                                );     
        $mycontact = civicrm_api("Contact","get",$contactArray);
        $tmp = $mycontact['values'][$mycontact['id']]['email'];
        $defaults['email-Primary'] = $tmp;
        $tmp = $mycontact['values'][$mycontact['id']]['street_address'];
        $defaults['street_address-Primary'] = $tmp;
        $tmp = $mycontact['values'][$mycontact['id']]['supplemental_address_1'];
        $defaults['supplemental_address_1-Primary'] = $tmp;
        $tmp = $mycontact['values'][$mycontact['id']]['postal_code'];
        $defaults['postal_code-Primary'] = $tmp;
        $tmp = $mycontact['values'][$mycontact['id']]['city'];
        $defaults['city-Primary'] = $tmp;
        $tmp = $mycontact['values'][$mycontact['id']]['country_id'];
        $defaults['country-Primary'] = $tmp;
    }
}


[gastrit]

While testing these solutions I found out that the <code>$count = 1;</code> messed things up for profiles containing more than one phone type text boxes (my client has a profile with home phone, home fax and home cell phone).

I was not sure why this line was added in your fix. I can't find a reason for it to be there so I removed it and everything seems to work. Otherwise the loop will overwrite last phone type and therefore just change the last phone type in the profile.

// Jonas