3

When sending e-mails from a case in CiviCRM the subject line contains a hashed case id between square brackets. It looks something like [case #a234db] Subject of the e-mail which is not really user friendly.

I have traced this behaviour back to the originating issue on https://issues.civicrm.org/jira/browse/CRM-5916 and the last comment is from Coleman in 2010:

Perhaps this has already crossed your minds, but for orgs that are trying to offer friendly and personal services, adding a person's case number (or hash thereof) to message subjects is, well, kind of tactless. I know my org won't want to use this feature for this reason.

Has anyone explored more unobtrusive options such as hashing the reply-to address or other message metadata?

My question is the same as in line with Coleman. Are there any options to solve the inbound e-mail processing and filing e-mails on cases whilst being user friendly in the subject.

Has anyone thought of a technique to do so? If so I might have time and funding to work on this.

References header

My first thought is to use the references header in the incoming e-mail to scan whether this is a reply to an e-mail send from within CiviCRM and then link it to the originating e-mail activity. More info on the reference header is given here: https://stackoverflow.com/a/7591704/3853493

What do you think?

1

I originally had some doubts, but in 7 years have never had a problem, but for one org we removed the hash and just use the actual case id by editing the civimail template, and see code below for the processing side. It also accepts just [1234] without the # symbol. This was more for staff ease of use than for the recipient - this way they can send from their email program and bcc the email processor.

I don't have a scientific study to reference, but anecdotally many non-technical people don't "read" emails the same way people who stare at code all day do. Your experience may be different.

Here's the block from CRM/Activity/BAO/Activity.php that has the modification:

$matches = array();
$subj_to_match = CRM_Utils_Array::value('subject', $params);
if (preg_match('/\[case #([0-9a-h]{7})\]/', $subj_to_match, $matches)) {
  $key        = CRM_Core_DAO::escapeString(CIVICRM_SITE_KEY);
  $hash       = $matches[1];
  $query      = "SELECT id FROM civicrm_case WHERE SUBSTR(SHA1(CONCAT('$key', id)), 1, 7) = '$hash'";
} elseif (preg_match('/\[case #(\d+)\]/', $subj_to_match, $matches)) {
  $hash       = $matches[1];
  // this seems like an odd query but we are checking the id actually exists
  $query      = "SELECT id FROM civicrm_case WHERE id = '$hash'";
} elseif (preg_match('/\[#(\d+)\]/', $subj_to_match, $matches)) {
  // technically this is a subset of the one below, but keeping it allows a subject that had both and prioritize this one
  $hash       = $matches[1];
  // this seems like an odd query but we are checking the id actually exists
  $query      = "SELECT id FROM civicrm_case WHERE id = '$hash'";
} elseif (preg_match('/\[(\d+)\]/', $subj_to_match, $matches)) {
  $hash       = $matches[1];
  // this seems like an odd query but we are checking the id actually exists
  $query      = "SELECT id FROM civicrm_case WHERE id = '$hash'";
}
if (!empty($matches)) {
  $caseParams = array(
    'activity_id' => $activity->id,
    'case_id' => CRM_Core_DAO::singleValueQuery($query),
  );
  if ($caseParams['case_id']) {
    $merge_info = CRM_Mergetrack_BAO_Mergetrack::getLatest(array('type' => 'civicrm_case', 'id' => $caseParams['case_id']));
    if (!empty($merge_info)) {
        $caseParams['case_id'] = $merge_info['new_id'];
    }
    CRM_Case_BAO_Case::processCaseActivity($caseParams);
  }
  else {
    self::logActivityAction($activity, "unknown case hash encountered: $hash");
  }
}

The "mergetrack" part is a separate extension (I'd call it unstable and it has some core hacks). Recently the same org has started sending out emails automatically on case creation, and then often the case has been merged in between the time the email goes out and the reply comes back, and so it was getting filed on the deleted case. You can remove those 4 lines.

  • Thanks for the answer that might help to hack the system. However I am more looking into a quality fix which could be ported back to CiviCRM core. – Jaap Jansma - CiviCooP Nov 20 '15 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.