Some (not all) custom data not available to Drupal Views after upgrade to 4.2

[russneversleeps]

I have a database with 7 custom data sets for CiviCRM contacts. Under CiviCRM 4.1.2 through 4.1.5, all of these sets & their fields were available to Drupal Views (3.5). After upgrading to CiviCRM 4.2, only 3 of these sets are available.

I've double and triple-checked the Drupal integration code in settings.php, and cleared caches repeatedly without resolving the problem.

Looking at my custom data sets, and running a few tests, it appears that Views is only pulling 1 custom data set for each record type. In my original View, the 3 (of 7) custom data sets that were available were 'Used For' different contact types (Individuals, Organizations, All Contact Types).

Has anyone else been experiencing this issue? I poked around the code a bit, but frankly I wouldn't really know where to start.

[mostou]

I have the same issues and I have tried:
- cleared all caches
- tried to create a new custom field group (not working)
- checking the settings.php file (making sure that the relevant custom field tables are listed)
- resaving all custom field groups
- checking custom field tables in database (in case a table needs to be repaired).

Nothing solved the issue.

[mostou]

I have posted this issue in the "Upgrading CiviCRM" board as well.

See:
http://forum.civicrm.org/index.php/topic,25877.0.html

[Coleman Watts]

Views integration is looking for a new maintainer.
Who wants to step up and help out?

[co-operatives uk]

Having the same issue. In the absence of a maintainer, I'm guessing I'll have to revert.

[co-operatives uk]

Doing some debugging, and the problem seems to be in $tree = CRM_Core_BAO_CustomGroup::getTree($entity_type, CRM_Core_DAO::$_nullObject, NULL, $groupID, $subType, NULL); - outputting $tree as soon as its compiled gives the truncated list of custom fields.

Anyone know if either CRM_Core_BAO_CustomGroup::getTree or CRM_Core_DAO::$_nullObject have changed their inputs??

[Donald Lobo]

pretty sure they have not changed their interfaces in the past release or so. They might have expanded it.

can u investigate and figure out what fields are not being shown? is it to do with sub-types?

lobo

[co-operatives uk]

No, not sub-types - it's as russneversleeps said: it only pulls across one custom group per "used for" tag. I suspect somewhere an array isn't spooling through all its content. I'll dig some more and see what I can figure out.

Edit to add:

Bit more of a dig, and it seems that whilst $groupID is incrementing as it should, the $tree query it returns is always the first one for the "extends" value. The $customGroup variable in CRM_Core_BAO_CustomGroup::getTree isn't incrementing in line with $groupID. Telling getTree to output its $customGroup on line 426 AND civicrm.views.inc to output its $groupID and $tree around line 309 gives me the right number of $tree calls for each of my custom groups, but 6 have duplicate $tree data instead of the correct fields.

Will dig again and see if I can work out why that might be.

One last edit:

Turning on the debug in DAO.php shows that civicrm is only making a new query statement as the "extends" value changes (AND civicrm_custom_group.extends IN ('Organization', 'Contact')). I can't quite get my head round how its storing these queries as its reusing them out of order: I've got 13 active Groups and its running through them in numerical order but:

Group 2 uses Group 2 Query
Group 3 uses Group 2 Query
Group 4 uses Group 4 Query
Group 5 uses Group 2 Query
Group 6 uses Group 6 Query
Group 7 uses Group 2 Query.

Time to call it a night.

[co-operatives uk]

Okay - have identified the issue: the query parameters used in gettree are being pulled from the cache until the $entity_id value changes (so it always uses the $group_id from the first query for Organizations, then the $group_id  from the first query for Individuals etc).

I've got a hack fix to get it working -

Line 415 of [root]/sites/all/modules/civicrm/CRM/core/BOA/CustomGroup.php reads:

    $groupTree = $cache->get($cacheKey);

If you add a line immediately after it that is -

$groupTree = '';

- then the queries will never get their parameters from the cache.

This is just a quick hack - I haven't checked to see what else it breaks, and I think it must be civicrm.views.inc that needs amended to stop the cacheing. I'll look at trying to get a proper fix, but I'll be uising this in the meantime to keep my site moving.

[kreynen]

We are also seeing this issue, but I'm just posting this to test the forum UI.

[stefanw]

I was having the same issue with custom fields.

I added $groupTree = '';

After $groupTree = $cache->get($cacheKey); on Line 415 of /sites/all/modules/civicrm/CRM/core/BOA/CustomGroup.php

And now I am seeing custom fields in views.

[Donald Lobo]

can someone test this patch (which is a bit more accurate and performant) and see if it works:

Code: [Select]

Index: CustomGroup.php
===================================================================
--- CustomGroup.php     (revision 42232)
+++ CustomGroup.php     (working copy)
@@ -407,7 +407,9 @@
     // lets see if we can retrieve the groupTree from cache
     $cacheString = $queryString;
     if (!empty($params)) {
-      $cacheString .= array_keys($params) . array_values($params);
+      $cacheString .=
+        implode( ',', array_keys($params)) .
+        implode( ',', array_values($params));
     }
     $cacheKey = "CRM_Core_DAO_CustomGroup_Query " . md5($cacheString);

thanx

lobo

[mostou]

I have upgraded again and tested.

@Lobo: the patch is unfortunately not working for me. I have tried to clear all caches (CiviCRM, Drupal and Drupal Views)

However the $groupTree = ''; workaround is working for me.

[Donald Lobo]

unfortunately that workaround is not very good for us since it basically kills the caching scheme

lobo

[co-operatives uk]

Afraid that patch doesn't do it for me either.