Answers.Body: <p>Whether or not civivolunteer is misbehaving, I've got a pending patch to the views integration that fixes the issue, here: <a href="https://issues.civicrm.org/jira/browse/CRM-18776" rel="nofollow">https://issues.civicrm.org/jira/browse/CRM-18776</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-07T19:18:58.380Z
Answers.LastActivityDate: 2016-06-07T19:18:58.380Z
Answers.UserDisplayName: Alan Dixon
Answers.Body: <p>Adding this an answer rather than a comment so I take advantage of formatting, like, ya know, paragraphs:</p>
  
  <p>I'm not clear what your question is, so I'll try to answer a few questions you might be asking :-)</p>
  
  <h1>If your question is "Is CiviVolunteer misbehaving with regard to its declaration of custom fields?" the answer is no.</h1>
  
  <p>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:</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <h1>If the question is "How can I get more CiviVolunteer data into Views?" see below.</h1>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-10T20:05:13.200Z
Answers.Text: 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
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-06T18:04:57.227Z
Answers.Text: 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:
  https://issues.civicrm.org/jira/browse/CRM-19545#comment-100714
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-06T23:47:18.373Z
Answers.Text: 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!
Answers.UserDisplayName: universalhandle
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-07T16:51:55.807Z
Answers.Text: 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.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-07T20:21:35.903Z
Answers.Text: Yes, that's right -- API all the way.
Answers.UserDisplayName: universalhandle
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-06-10T00:07:26.060Z
Answers.LastActivityDate: 2016-06-10T00:07:26.060Z
Answers.UserDisplayName: universalhandle
Body: <p>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).</p>
  
  <p>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)."</p>
  
  <p>Actually, I updated the exception code to include 'Activity'. That part of the code shouldn't be executing except for contact entity types.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Anyone else have this experience and/or can give me an opinion on my diagnosis?</p>
  
Tags: <drupal-views><civivolunteer>
Title: Views integration and CiviVolunteer
ThreadText: # Views integration and CiviVolunteer
  
  (Asked by: username_0 on 2016-06-07)
  
  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?
  
  **Tags:** drupal-views, civivolunteer
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2016-06-07. Score: 3
  
  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>
  
  
  ---
  
  ### Answer by username_1 on 2016-06-10. Score: 0
  
  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.
  
  > **Comments:**
  > **username_0**: 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  
  > **username_0**: 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: https://issues.civicrm.org/jira/browse/CRM-19545#comment-100714  
  > **username_1**: 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!  
  > **username_0**: 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.  
  > **username_1**: Yes, that's right -- API all the way.  
  
  ---
  
  