Details
-
Type: Improvement
-
Status: Done/Fixed
-
Priority: Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.7
-
Fix Version/s: 4.7
-
Component/s: None
-
Labels:None
-
Documentation Required?:None
-
Funding Source:Paid Issue Queue
-
Payment Status:Paid
Description
This follows up CRM-10551 and CRM-16870
Issue summary
Currently there are multiple methods for 'block' fields to be updated. Editing via the AJAX interface, editing via the Contact > Edit screen, editing via Profiles.
The main issue is CRM/Core/BAO/Block.php currently tries to match up submitted values with those already on the contact to detect an edit. It does this by looking at the location types of each block field, because the ID of the block value is not included.
We tried to work around this in CRM-10551 and CRM-16870 to allow blanked values on Profiles to be deleted, but it created more problems than it solved.
Proposed solution
Rather than trying to match up submitted values by location type, all the block form fields in Civi should contain the ID of the block (if set). Then the system will instantly know if it is an existing phone number / email address being edited, or a new one being added. It would also understand that if it was deliberately 'blanked' it should be deleted.
It would also now understand if an existing value was having its location changed/corrected - rather than deleting and re-adding the value: ie a change of home phone > work phone.
It would be useful if this change were made everywhere editable 'block' fields are rendered so that we only need one process to handle saving block fields:
- Is there an ID? If no, and there is a value then create it. If yes:
- Is there a value? If no, and this is a deliberate deletion (ie: not an auto-matched registration or contribution) then delete the value. If yes, then update this value on the contact.
We think this would be a lot simpler, and more consistent, than the current process, which loads up the existing fields on the contact and tries to match up when block fields are saved. This would also improve the haphazard process via the Contact > Edit form that currently adds/edits/deletes fields 'in order': Currently the buildQuickForm functions for the block elements (Contact/Form/Edit/Email.php) set the 'block ID' as a sequential number from 1. This should become the actual block ID.
Sponsorship
We may be willing to sponsor the core team for this work for 4.7 if someone would like to contact me with an estimate for the work - unless there are suggestions for a better way to handle this.
I hope I've explained the issue clearly, please do contact me if not!
Tests
An initial list of tests for this issue:
Test each block type: phone, email, address, IM, website, open ID
Inline contact edit:
- Add
- Edit
- Change location/type
- Change primary
- Delete
Full contact edit form:
- Add
- Edit
- Change location/type
- Change primary
- Delete
On an event with a profile, as a logged in user (ie: yourself):
- Add profile fields for each block type (two of each)
- Check new details are added
- Check existing details can be edited
- Check that erasing details deletes them
On an event with a profile as an anonymous user that will be auto-matched:
- As above, but check that blanked fields are NOT deleted from the record
Test as above but with a Contribution Page.
Test that using profiles in 'Edit' mode also work as expected:
- Add
- Edit
- Test that a a phone/email can be deleted and is removed from contact record
- Check other fields not on the profile (ie: other location types) remain on
the contact record when the profile is saved