Answers.Body: <p>UPDATE: I know this doesn't fully answer the question but noting the ability to change the code to an id or remove the subject code is now an extension: <a href="https://lab.civicrm.org/extensions/caseidinsubject" rel="nofollow noreferrer">https://lab.civicrm.org/extensions/caseidinsubject</a></p>
  <p>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.</p>
  <p>I don't have a scientific study to reference, but anecdotally many non-technical people don't &quot;read&quot; emails the same way people who stare at code all day do. Your experience may be different.</p>
  <p>Here's the block from CRM/Activity/BAO/Activity.php that has the modification:</p>
  <pre><code>$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      = &quot;SELECT id FROM civicrm_case WHERE SUBSTR(SHA1(CONCAT('$key', id)), 1, 7) = '$hash'&quot;;
  } 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      = &quot;SELECT id FROM civicrm_case WHERE id = '$hash'&quot;;
  } 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      = &quot;SELECT id FROM civicrm_case WHERE id = '$hash'&quot;;
  } 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      = &quot;SELECT id FROM civicrm_case WHERE id = '$hash'&quot;;
  }
  if (!empty($matches)) {
    $caseParams = array(
      'activity_id' =&gt; $activity-&gt;id,
      'case_id' =&gt; CRM_Core_DAO::singleValueQuery($query),
    );
    if ($caseParams['case_id']) {
      $merge_info = CRM_Mergetrack_BAO_Mergetrack::getLatest(array('type' =&gt; 'civicrm_case', 'id' =&gt; $caseParams['case_id']));
      if (!empty($merge_info)) {
          $caseParams['case_id'] = $merge_info['new_id'];
      }
      CRM_Case_BAO_Case::processCaseActivity($caseParams);
    }
    else {
      self::logActivityAction($activity, &quot;unknown case hash encountered: $hash&quot;);
    }
  }
  </code></pre>
  <p>The &quot;mergetrack&quot; 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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-20T17:43:36.900Z
Answers.Text: 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.
Answers.UserDisplayName: Jaap Jansma - CiviCooP
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-25T14:50:47.523Z
Answers.Text: Added a core issue for this, counting on some suggestions on approaches? https://lab.civicrm.org/dev/core/-/issues/2212
Answers.UserDisplayName: ErikH - CiviCooP
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2015-11-20T15:11:53.253Z
Answers.LastActivityDate: 2020-11-25T14:49:21.723Z
Answers.LastEditDate: 2020-11-25T14:49:21.723Z
Answers.UserDisplayName: Demerit
Body: <p>When sending e-mails from a case in CiviCRM the subject line contains a hashed case id between square brackets. 
  It looks something like <code>[case #a234db] Subject of the e-mail</code> which is not really user friendly. </p>
  
  <p>I have traced this behaviour back to the originating issue on <a href="https://issues.civicrm.org/jira/browse/CRM-5916" rel="nofollow noreferrer">https://issues.civicrm.org/jira/browse/CRM-5916</a> and the last comment is from Coleman in 2010:</p>
  
  <blockquote>
    <p>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.</p>
    
    <p>Has anyone explored more unobtrusive options such as hashing the reply-to address or other message metadata?</p>
  </blockquote>
  
  <p>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. </p>
  
  <p>Has anyone thought of a technique to do so? If so I might have time and funding to work on this.</p>
  
  <p><strong>References header</strong></p>
  
  <p>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: <a href="https://stackoverflow.com/a/7591704/3853493">https://stackoverflow.com/a/7591704/3853493</a></p>
  
  <p>What do you think?</p>
  
Tags: <civimail><civicase>
Title: Case ID in e-mails from case
ThreadText: # Case ID in e-mails from case
  
  (Asked by: username_0 on 2015-11-20)
  
  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?
  
  **Tags:** civimail, civicase
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-11-20. Score: 2
  
  UPDATE: I know this doesn't fully answer the question but noting the ability to change the code to an id or remove the subject code is now an extension: https://lab.civicrm.org/extensions/caseidinsubject
  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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_2**: Added a core issue for this, counting on some suggestions on approaches? https://lab.civicrm.org/dev/core/-/issues/2212  
  
  ---
  
  