Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-16877

Include ID when editing 'block' fields (+ allow deletion of block values via Profiles)


    • Type: Improvement
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.7
    • Fix Version/s: 4.7
    • Component/s: None
    • Labels:
    • Documentation Required?:
    • Funding Source:
      Paid Issue Queue
    • Payment Status:


      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.

      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!

      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




            • Assignee:
              dgg David Greenberg
              john John K.
            • Votes:
              0 Vote for this issue
              5 Start watching this issue


              • Created:

                Time Tracking

                Original Estimate - Not Specified
                Not Specified
                Remaining Estimate - 0 minutes
                Time Spent - 3 days, 6 hours
                3d 6h