Custom field sets for other activity types appear on activity create form

Summary

Custom field sets for other activity types appear on activity create form in 4.6.16 . This can cause significant problems for users where there are many other CF sets and they contain mandatory fields, effectively preventing users from creating activities.

I mentioned this on CRM-18504. Have created this as a separate issue because it's different behaviour.

Steps to replicate

1. Create custom field set "Test Follow-up Fields" extending Activity of type Follow-up (activity type id 14)
2. Create a field in above CF set.
3. Go to create Meeting activity form (activity type id 1)

Expected behaviour:
Meeting form shows only CF sets defined for Meeting or for all activity types.

Actual behaviour:
Meeting form shows "Test Follow-up Fields" CF set.

Versions affected

Replicated in 4.6.16 and on d46.demo.civicrm.org . Problem did not occur on 4.7.7 or dmaster.demo.civicrm.org .

Diagnosis

In this clause for entity subtypes in CRM_Core_BAO_CustomGroup::getTree() :

$subTypeClauses[] = "civicrm_custom_group.extends_entity_column_value LIKE '%" . self::validateSubTypeByEntity($entityType, $subType) . "%'";

the LIKE matches sloppily. The value returned by validateSubTypeByEntity has any value separators stripped, so $subType may be e.g. '1' for activity type Meeting , in which case we're then doing this match:

civicrm_custom_group.extends_entity_column_value LIKE '%1%'

which will match e.g. 1, 10, 11, 12, ..., 21, 31, ...
So it matches activity type 14 = Follow-up.

See https://issues.civicrm.org/jira/browse/CRM-18504?focusedCommentId=88916&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-88916

Solution

Fixed by this:

--- CustomGroup.php.PR8301+preg	2016-05-13 14:30:19.000000000 +0100
+++ CustomGroup.php	2016-05-13 18:01:40.000000000 +0100
@@ -433,7 +433,9 @@

    if (!empty($subTypes)) {
      foreach ($subTypes as $key => $subType) {
-        $subTypeClauses[] = "civicrm_custom_group.extends_entity_column_value LIKE '%" . self::validateSubTypeByEntity($entityType, $subType) . "%'";
+        // Fix regression from 4.6.16 fixes: the value returned from validateSubTypeByEntity does
+        // not include value separators, so they need to be added for the query.
+        $subTypeClauses[] = "civicrm_custom_group.extends_entity_column_value LIKE '%" . CRM_Core_DAO::VALUE_SEPARATOR . self::validateSubTypeByEntity($entityType, $subType) . CRM_Core_DAO::VALUE_SEPARATOR . "%'";
      }
      $subTypeClause = '(' .  implode(' OR ', $subTypeClauses) . ')';
      if (!$onlySubType) {

However other changes to related code are under discussion in CRM-18504 so I don't suppose a PR is useful here.