Details
-
Type:
Patch
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.2.6
-
Fix Version/s: 4.3.0
-
Component/s: Drupal Integration Modules
-
Labels:
Description
In order to get views relationships working for civicrm_contact_ref, Drupal's hook_field_views_data() needs to implemented, specifically the property that defines the relationship to another base table - in this case,
{civicrm_contact}. This enables one to add views relationship (to a node-based view) on that civicrm_contact_ref field and then to add fields to the view that come from the related contact.
But there's more: while just making this change gets the basic views query working, adding further views relationships to CiviCRM Relationships (via the new Contact relationship) doesn't work. This is because (in the scenario above), the views handler defined in civicrm_handler_relationship.inc fails to 'swap' the contact_id_a and contact_id_b, or vice versa, when the CiviCRM Relationships relationship is second in the chain. That's because the relevant if-statement assumes a particular naming convention for the $this->view->query->table_queue array keys (namely, 'civicrm_relationship'), but when this relationship is second or later in a chain, this key actually gets the 'table_alias' value, which is longer and more dynamic. The additional patch for views/civicrm/civicrm_handler_relationship.inc changes the condition on this if-statement to take into account this sort of chaining.
Perhaps I should explain about the civicrm_handler_relationship.inc patch a tiny bit more:
1. The change is made to the condition of an if-statement that is intended to make sure the join is to the opposite field of a civicrm relationship (contact_id_a for contact_id_b, or vice versa).
2. However, the test is made against $this->view->query->table_queue['civicrm_relationship']['join']
>field. The problem here is that five lines earlier this table_queue entry is created using $this>query->add_table($this->table, $this->relationship); - and this method creates an alias for the newly-queued table. If this views relationship is chained onto an earlier relationship (as in the scenario using a civicrm_contact_ref field), then this alias is more complex than simply 'civicrm_relationship'. As a result, the join fields don't get swapped and one doesn't get the results one expects.3. Therefore, I added a condition that $this->table == 'civicrm_relationship' and changed the table_queue array key to be $this->table_alias, since that's the result of the assignment operation five lines earlier, as mentioned in point 2.
Clear as mud? It's working for me now for a content (i..e, node) view that has (first) a relationship to CiviCRM Contact through the civicrm_contact_ref field, and (second) a relationship to a CiviCRM Relationship: Contact B joined on the referenced Contact. I haven't yet chained deeper, or tested whether this single-line change breaks other relationship handlers, but it doesn't look like it should.