Phone/email/website issues when profile editing / saving = data loss [FILED]

[rocxa]

Attached is a screenshot of some issues when editing profiles on the http://dmaster.demo.civicrm.org site.

The issues apply to websites and phones but probably any other field types where primary/location is used. (such as addresses)

Issues summary:

It seems that the profiles are failing to display data in some CiviCRM fields.
It also seems that the way primary phones / locations are set on profiles is a bit odd and it should be being handled in the same way that editing a contact record is handled.  i.e. a radio button to set a field to be primary rather than a separate field.

CiviCRM Webform integration suffers from similar problems.

[John.K]

OK, so:

Create a profile
Add an Email (Primary) field
Add an Email (Other) field
Starting from a blank record, use this profile to insert an email address in each - works correctly.
Use the profile again, to delete (blank out) the Email (Primary) field
Notice that in the contact record, both email addresses are still there, but the 'Email (Other)' field has become 'Primary'
Use the profile again
Notice that both the Primary and Other fields are populated with the value from 'Email (Other)'

This is because, when the 'Email (Primary)' field is blanked, the 'Email (Other)' field is set as the primary email address. So when the profile is loaded again, it's really just listing the same email address twice - the 'Other' IS the 'Primary'.

The complication here is with the Email (Primary) option. Since 'Primary' is not a real email type. As the OP suggests, it would make most sense to mimic the main Contact record edit form. So that users are presented with the normal types and locations, which can be 'forced' on the profile. Ie: Email (Home), Email (Work). When multiple fields of the same type are added, then users should be able to choose which number is 'Primary' using a radio select:

Email (Home) [       ]    Primary? []
Email (Work)  [       ]    Primary? []

A surprise to me was that even through blanked profile fields are not deleted (as noted here: https://issues.civicrm.org/jira/browse/CRM-10551), the 'Other' field became  primary because the existing primary field was blanked. If the data is not deleted, then the 'Primary' value should not be altered?

Furthermore, if you were only putting one email address on a profile and used the 'Primary' type, then there would be no information about the real type of the email address (home, work, etc.). The profile seems to just assume it is 'Home' which is inaccurate.

If you stay away from the 'Primary' type then the profiles work as expected, but there is no way for the user to indicate their primary email address - again highlighting the need to get away from having this weird 'Primary' type available in profiles.

I hope this post makes sense to someone ;]

[John.K]

Diagnosing this issue as being related to the 'Primary' field has turned up this issue that already exist in JIRA:

https://issues.civicrm.org/jira/browse/CRM-14448

That links to a number of previous PRs to attempt to fix the problem; but none of them seem to address the fact that exposing the 'Primary' type to end users probably isn't the best approach.

[John.K]

There is some progress on 'values not getting deleted when they are removed from a profile' over here: https://issues.civicrm.org/jira/browse/CRM-10551

It would be great if we can get some testing done, and feedback, on the proposed fix =]

[petednz]

Unless you are wedded to civi profiles for this, you might find that Webform-CiviCRM gets you closer. Can't promise, but i think it does offer 'is primary'

[John.K]

Hi petednz, the CiviCRM Webform module is a great piece of work, but unfortunately suffers from a slightly different issue which is a killer for us, regarding how it retrieves information with different 'locations', such as phones, emails, etc. See: https://www.drupal.org/node/1503012#comment-9606851

It would be great to improve how profiles work in CiviCRM core, so that's what I'm doing a bit of work on now. If you have time to provide some feedback on CRM-10551 that would be great =]