Published
2013-11-19 13:43
I love CiviCRM, but sometimes visualising and 'reporting' on data can be a complicated process and personally I think the Drupal Views module is a perfect way of easily generating listings and reports that can be filtered, sorted and manipulated on the fly by non-technical users.
Currently, Views intergration is pretty good but there's more work to do and I'm taking over the views maintenance of CiviCRM, to not only fix bugs, but also add enhahncements and features.
Let me know what you're looking for either in the comments or by creating an issue and tagging it 'views3' and we'll see what we can all accomplish.
Comments
Hi Chris:
As a System builder, it's great to have views access to civicrm rather than having to write and maintain code. It can be a bit painful to integrate with civicrm but I've found views and civicrm_entity (and civicrm_webform) to be very helpful. A great example of a use case is here: https://civicrm.org/blogs/jackrabbithanna/drupalcivicrm-integration-civicrm-entity-and-webform-civicrm. Unfortunately, views and entity are not well integrated. I also find civicrm_rules to be helpful and the entity module has rules, but again, not well integrated (an earlier version had conflicts that may have been resolved.)
It looks like the apporach to rules, views and entities has some overlap and the goals are also similar. I'd incourage you to coordinate with eileen and coleman to avoid duplicated efforts and ensure compatability where appropriate.
From my limited perspective, improving drupal entitiy support could dramatically reduce the need for writing and maintaining custom integration code and allow civicrm to take more advantage of all the drupal entity based modules.
Thanks for all your efforts,
S.
I don't know how much you like deleting code (personally I love it) but you've probably noticed that views code is way bigger than it needs to be. The biggest chunk of it is just reproducing CiviCRM's schema. That could be eliminated with clever use of civicrm.api.getfields. The 2nd biggest chunk is for fetching option lists and resolving pseudoconstants. We also now have an api for that (civicrm.api.getoptions). I'm not sure how easy the 1st would be, but the 2nd is straightforward and pretty fun I can tell you - In Webform-CiviCRM 4 I was able to delete a couple hundred lines of code for fetching option lists and replace them with a single call to civicrm.api.getoptions. Wohoo!
It builds the civicrm entities as drupal entities - which makes them available to views. Currently it sets up entities for views (if installed) & civicrm_views alters them - which is why you will have a few more fields & possibly an extra table if you have civicrm_entity installed.
If I were starting from scratch now I would enhance civicrm_entity to have the extra tables & handlers that it doesn't have & not write the views module at all. However, since the views module exists it's hard to know the way forwards. I had envisioned that eventually civicrm_entity would replace civicrm_views integration - but am not actively pursuing that.
Assuming you can convince Chris to take over civicrm_entity instead of civicrm_view (a big if), what would be the inconvenient of not doing it?
ie. can you do everything civicrm_view does with civicrm_entitiy?
CiviCRM Entity could take over all or much of what the views integration does but it's not it's primary purpose. It exposes civicrm entities as drupal entities allowing use of other drupal modules
- solr integration
- rules integration (e.g when someone registers for an event create them a user account & give that account role y)
- views bulk operations (e.g we are using it to assign & unassign activities)
- entity reference fields (e.g link CiviCRM events to nodes - we do this when creating an organic group for participants of a group)
- we haven't gone done this path yet but others have exposed civicrm entities with drupal fields attached to them.
Note that if I were looking at steps down this path I would suggest making civicrm_views require civicrm_entity & then remove declarations from civicrm_views that are done successful in a schema-based way in civicrm_entity
hi chris - thanks for taking on this - it is something that we seem to have never stepped up to do even though between Torrance, Eileen and Chris there have been numerous contributions in the Views and general Drupal integration area.
And much of this I don't get around to blog about which I should, such as the overhaul of Views/Civi Relationships which means we can now, for example, start with Contact A - go up to Household X - and bring back data about the other household members etc.
Let me know if/how Fuzion can step in to work alongside you on this.
OK… I may start small with a few bits of low hanging fruit before emabrking on entity references, but I will keep you all posted :)
Chris
NB - I just found out that with civicrm_entity installed it is possible to delete items from a view (using the drupal built-in VBO 'delete item')
just flagging we have started work on this - though looks like the custom field side of the views integration needs a major overhaul - but that is beyond us at present
I'm making a slow start on things… Turn out a lot of my grievances were with our Drupal 6 instalations, most of which were gone in the D7 version :/
As I review this thread you probably feel like you walked on a landmine as there is a lot of pentup demand to refactor views and various code overlaps. Thanks for keeping folks posted and please let us know what kind of scopre (if any) you are considering.
I see over 100 unresolved issues in views and most are slated for 4.5 or 4.6+. Was wondering if you have thought at all about some of the refactoring and are able to weigh in. CMS integration is probably important to a lot of folks - since you have been closely involved with views it would be great to hear your thoughts.