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

All groups removed from contact when editing

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.4.8, 4.5.5
    • Fix Version/s: 4.6
    • Component/s: None
    • Labels:
    • Documentation Required?:
      None

      Description

      When editing a contact under certain circumstances through CRM_Contact_Form_Contact, all of the contact's groups are removed.

      The circumstances are pretty simple: if Tags and Groups is disabled under Editing Contacts on civicrm/admin/setting/preferences/display, editing the contact through the summary page will remove all the contact's groups.

      In the code, in CRM\Contact\Form\Contact.php, it appears the following section is at fault in postProcess:

      if (!array_key_exists('TagsAndGroups', $this->_editOptions))

      { unset($params['group']); }

      if (CRM_Utils_Array::value('contact_id', $params) && ($this->_action & CRM_Core_Action::UPDATE)) {
      // figure out which all groups are intended to be removed
      $contactGroupList = CRM_Contact_BAO_GroupContact::getContactGroup($params['contact_id'], 'Added');
      if (is_array($contactGroupList)) {
      foreach ($contactGroupList as $key) {
      if ((!array_key_exists($key['group_id'], $params['group']) || $params['group'][$key['group_id']] != 1)
      && !CRM_Utils_Array::value('is_hidden', $key)
      )

      { $params['group'][$key['group_id']] = -1; }

      }
      }
      }

      In the first if, we're removing $params['contacts'] if the Tags and Groups section is disabled, but we never verify in the second if block that the section is enabled. Through my testing on my client's site, I found that simply changing the second if to an else if fixes the problem. The new logic would then be if this section is not enabled, remove it from the params. Otherwise, the logic would proceed as normal and remove or keep the groups on the merits.

      I have successfully recreated this bug on both my client's site and the 4.5 demo site. It appears from looking at the repository this bug also still exists in 4.6.x.

        Attachments

          Activity

            People

            • Assignee:
              monish.deb Monish Deb
              Reporter:
              cgrewe Chris Grewe
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: