Answers.Body: <p>Here's the override code I've used to make it accept some variations of case id (with and without the word case, with and without the # sign) as well as hash, prioritizing the fanciest to the plainest. It looks like the original code hasn't changed since 4.2 so this should work against 4.7 too.</p>
  
  <p>Create an override for CRM/Activity/BAO/Activity.php, and in lines 607 thru 622 replace it with this:</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      = "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];
    $query      = "SELECT id FROM civicrm_case WHERE id = '$hash'";
  } elseif (preg_match('/\[(\d+)\]/', $subj_to_match, $matches)) {
    $hash       = $matches[1];
    $query      = "SELECT id FROM civicrm_case WHERE id = '$hash'";
  }
  if (!empty($matches)) {
    $caseParams = array(
      'activity_id' =&gt; $activity-&gt;id,
      'case_id' =&gt; CRM_Core_DAO::singleValueQuery($query),
    );
    if ($caseParams['case_id']) {
      CRM_Case_BAO_Case::processCaseActivity($caseParams);
    }
    else {
      self::logActivityAction($activity, "unknown case hash encountered: $hash");
    }
  }
  </code></pre>
  
  <p>One interesting side effect of this is that saving a non-case activity using the normal civi UI but putting [1234] in the subject will save it as a case activity on case 1234!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-17T02:51:14.287Z
Answers.Text: thanks. i would vote for the 'case id' being okay. need to rustle up some more opinions somehow
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-17T03:08:41.493Z
Answers.Text: More inclined to only accept `[case #1234]` and not `[#1234]` OR `[1234]` in the subject. So, nice to have the first two conditions from the above code :-)
Answers.UserDisplayName: jitendra - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-17T03:11:12.630Z
Answers.Text: would be happy to test the patch if you can raise a related JIRA or PR in core @Demerit.
Answers.UserDisplayName: jitendra - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-17T14:55:59.600Z
Answers.Text: Thanks. https://issues.civicrm.org/jira/browse/CRM-21446 @jitendrapurohit
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-11-17T02:19:52.573Z
Answers.LastActivityDate: 2017-11-17T02:19:52.573Z
Answers.UserDisplayName: Demerit
Body: <p>Happy to be told we are going about this wrong.</p>
  
  <p>SCENARIO: Case Manager gets sent an email from an external source to their private/organisational email address.</p>
  
  <p>They want to forward/resend to it gets stored on the Case.</p>
  
  <p>Manager goes in to Civi (or Views in our case) searches the contact, finds the relevant case, then, as i understand things, they need to include a value in the email such as </p>
  
  <blockquote>
    <p>[case #44fec3a]</p>
  </blockquote>
  
  <p>where that value is the first 7 letters of a hashed value of the civicrm site-key plus the case id</p>
  
  <p>And indeed this works, if I send an email to the 'inbound email processing email address' and have  [case #44fec3a] it gets added to the Case. Wonderful.</p>
  
  <p>But the Case Managers have no way of knowing what the hashed value should be - and we need to be able to show it on both the CiviCase page and in Views.</p>
  
  <p>So do we need to find a way to 'present' this 7-character string on both the Case page, and pull it together in our Views?</p>
  
  <p>Or does anyone have a simpler/better suggestion/solution?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-17T02:02:09.200Z
Comments.Text: My memory tells me the fact that it's a hash and not the case id itself was a communication misunderstanding during development. Making it use case id instead would be my vote (but still accept hash for backwards compatibility). I have some code for this but it's for v4.2 which I can post somewhere. If keeping hash you could use civicrm_hook_caseSummary to display the hash on Manage Case at least.
Comments.UserDisplayName: Demerit
Tags: <civicase>
Title: How to expose the civicase hashed value that gets sent in Subject when sending an email from case
ThreadText: # How to expose the civicase hashed value that gets sent in Subject when sending an email from case
  
  (Asked by: username_0 on 2017-11-16)
  
  Happy to be told we are going about this wrong.
  
  SCENARIO: Case Manager gets sent an email from an external source to their private/organisational email address.
  
  They want to forward/resend to it gets stored on the Case.
  
  Manager goes in to Civi (or Views in our case) searches the contact, finds the relevant case, then, as i understand things, they need to include a value in the email such as
  
  > [case #44fec3a]
  
  where that value is the first 7 letters of a hashed value of the civicrm site-key plus the case id
  
  And indeed this works, if I send an email to the 'inbound email processing email address' and have [case #44fec3a] it gets added to the Case. Wonderful.
  
  But the Case Managers have no way of knowing what the hashed value should be - and we need to be able to show it on both the CiviCase page and in Views.
  
  So do we need to find a way to 'present' this 7-character string on both the Case page, and pull it together in our Views?
  
  Or does anyone have a simpler/better suggestion/solution?
  
  **Tags:** civicase
  
  > **Comments:**
  > **username_1**: My memory tells me the fact that it's a hash and not the case id itself was a communication misunderstanding during development. Making it use case id instead would be my vote (but still accept hash for backwards compatibility). I have some code for this but it's for v4.2 which I can post somewhere. If keeping hash you could use civicrm_hook_caseSummary to display the hash on Manage Case at least.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2017-11-17. Score: 1
  
  Here's the override code I've used to make it accept some variations of case id (with and without the word case, with and without the # sign) as well as hash, prioritizing the fanciest to the plainest. It looks like the original code hasn't changed since 4.2 so this should work against 4.7 too.
  
  Create an override for CRM/Activity/BAO/Activity.php, and in lines 607 thru 622 replace it with this:
  
  ```
  $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];
    $query      = "SELECT id FROM civicrm_case WHERE id = '$hash'";
  } elseif (preg_match('/\[(\d+)\]/', $subj_to_match, $matches)) {
    $hash       = $matches[1];
    $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']) {
      CRM_Case_BAO_Case::processCaseActivity($caseParams);
    }
    else {
      self::logActivityAction($activity, "unknown case hash encountered: $hash");
    }
  }
  
  ```
  
  One interesting side effect of this is that saving a non-case activity using the normal civi UI but putting [1234] in the subject will save it as a case activity on case 1234!
  
  > **Comments:**
  > **username_0**: thanks. i would vote for the 'case id' being okay. need to rustle up some more opinions somehow  
  > **username_2**: More inclined to only accept `[case #1234]` and not `[#1234]` OR `[1234]` in the subject. So, nice to have the first two conditions from the above code :-)  
  > **username_2**: would be happy to test the patch if you can raise a related JIRA or PR in core @username_1.  
  > **username_1**: Thanks. https://issues.civicrm.org/jira/browse/CRM-21446 @jitendrapurohit  
  
  ---
  
  