I think I've discovered something broken with CiviVolunteer's views integration, which was only laid bare in the past two civi 4.6 releases (.17 and .18, related to the custom group work).

The symptom is that the views interface now returns "The website encountered an unexpected error. Please try again later." and in the watchdog, I can see this: "CRM_Core_Exception: Invalid Entity Filter for Activity in CRM_Core_BAO_CustomGroup::validateSubTypeByEntity() (line 645 of [...]CRM/Core/BAO/CustomGroup.php)."

Actually, I updated the exception code to include 'Activity'. That part of the code shouldn't be executing except for contact entity types.

Tracing back to how this might have happened - it appears that civivolunteer creates the custom field group that this is breaking on, and it includes a number in the "extends_entity_column_value" of civicrm_custom_group, which I suspect is why this code is executing.

I haven't tried removing this column data, in case it's used in a way I don't understand, but I'm guessing this is the easy solution.

Anyone else have this experience and/or can give me an opinion on my diagnosis?

2 Answers 2


Whether or not civivolunteer is misbehaving, I've got a pending patch to the views integration that fixes the issue, here: https://issues.civicrm.org/jira/browse/CRM-18776


Adding this an answer rather than a comment so I take advantage of formatting, like, ya know, paragraphs:

I'm not clear what your question is, so I'll try to answer a few questions you might be asking :-)

If your question is "Is CiviVolunteer misbehaving with regard to its declaration of custom fields?" the answer is no.

To the best of my knowledge, the extension manages custom fields the same way as if you were to create them via point-and-click. I'm not sure exactly where you're encountering the error, as the extension defines several custom field groups:

One is for the contact subtype Volunteer. The corresponding entry in civicrm_custom_group (name=Volunteer_Information) has a string in the extends_entity_column_value. If you manually create a custom field group for the student subtype that ships with some builds, you'll see it follows the same pattern.

For what I assume are legacy reasons, if the custom field group extends an Activity, the column in question takes an integer instead of a string. The integer represents the value of the activity subtype in the option group named activity_type.

If the question is "How can I get more CiviVolunteer data into Views?" see below.

CiviVolunteer doesn't have any Views integration beyond what it inherits from Core. Since Core already exposes the Activity entity which CiviVolunteer makes use of, some CiviVolunteer data is exposed. However, entities originated by CiviVolunteer (e.g., civicrm_volunteer_project) are not exposed. I haven't had any serious requests for this functionality, so I haven't pursued it.

I haven't worked with the Views integration code since versioning was managed in SVN (!), so it's unclear to me what it would take to expose Volunteer-specific entities. I suspect the integration code would need to be updated to invoke hook_civicrm_entityTypes(), but I haven't dug around to see how much other information Views needs.

To be more helpful I think I need more information. What are you trying to do? What steps can I take to reproduce the error? Does the View have to be of a certain type? Maybe it would be easier to export your View so I can test it on a copy on my end.

  • I think the key piece is your paragraph about Activities. The error is occurring with views involving Activities with custom fields provided by CiviVolunteer. Specifically - those values in the extends_entity_column_value field break the civicrm_views_custom_data_cache call, for which I'm providing a patch. Looking at the history of that code, it appears that it's a bug that's been lurking for a while but only revealed itself due to some recent security patches. If Civivolunteer doesn't have any views with activities defined, then try just creating an activities-based view and see what happens
    – Alan Dixon
    Commented Jun 10, 2016 at 20:05
  • Turns out the issue was in some version of civivolunteer that created the civicrm_custom_group entry with the name CiviVolunteer, which extends Activity and ended up with what looks like an empty array in extends_entity_column_value. See my comment here for details: issues.civicrm.org/jira/browse/CRM-19545#comment-100714
    – Alan Dixon
    Commented Mar 6, 2017 at 18:04
  • I'm not sure if I should be replying here or on the JIRA ticket, but I've not seen any instance where extends_entity_column_value for the custom group named CiviVolunteer has anything but an integer in it. This integer should match the value property of the optionValue named Volunteer in the group activity_type. Anyway, if you see that again let me know and perhaps we can figure out how it got corrupted. Sorry for whatever headaches it's caused you! Commented Mar 6, 2017 at 23:47
  • I'm assuming you're not directly writing to those fields, but using the api, so my best guess is that the bad entries were caused by CiviCRM core. In any case, it seems likely that it can and should be fixed by core, and probably is in 4.7.
    – Alan Dixon
    Commented Mar 7, 2017 at 16:51
  • Yes, that's right -- API all the way. Commented Mar 7, 2017 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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