Approaches to Managing Access to Content via Relationship

[Eileen]

We have a requirement from a client that contacts with a particular relationship have access to edit specific content. In this case the contact B of the contact doesn't matter much. There are a couple of approaches so far muted

1) Enhance the Existing Group to Role Sync module so that it will sync smart groups to roles rather than just normal groups
2) Enhance Rules module so that it's possible to add or remove a role when a relationship is created, updated or deleted
3) Write a drupal based content access module that includes CiviCRM data in the content access query
4) Write a stand alone CiviModule for this (much like #2 but without the UI that rules offers - or the complexity)

Thoughts

#1 Use smart groups & existing module

• This intuitively seems like a 'heavy' approach to me. Using a smart group to get to a relationship status feels like a bit much. The relevant smart group cache would need to be recalculated each time we do the sync - perhaps by 4.2 this is not so bad.
• Presumably the update would need to be on log in rather than when the relationship is updated to keep the load down - which means that you wouldn't be able to check they have the role until they log in but is not a show-stopper
• As of 4.2 the search for relationships on advanced search uses an OR clause that makes the search slow & resource intensive due to indexing issues around OR clauses on joins  (I find several relationship based . I think this is embedded in the query object so we'd need to fix the search here to use a temp table which isn't something we have an existing pattern for).
• Timing would be a problem. ie. if I wanted to work on fixing the relationship join now we probably can't put it into 4.3 but 4.4 isn't forked off yet. I find that if you work on something & can't get it into core when you are working on it for the customer then it's generally better to choose an approach that doesn't involve Core (ie. a custom code based approach).

Enhancing rules module

• An advantage of this approach is that the customer already has an interest in using the Events OG work on rules module  so getting it going would be a good thing
• The rules module doesn't seem to have any way to store the mappings between objects, except in the rule set-up (though the UI). This may be less of an issue here (than in the event integration for example) as there is no intention to create roles based
• I'd need to enable some new conditions & actions
• I'd probably need to dig a bit to find the possible pitfalls of this approach
  

Write a drupal based content access module

• I don't know too much about this but it seems that it must be a fairly well-trodden path to hook your own criteria into the content access query
• Given that I'd be learning how to do this I'd probably wind up with a fairly hard-coded solution

Write a one-off custom module

• This is basically like the rules approach without handing over control to UI users the way the rules approach does (or having to build my own custom forms to do so). In this case the customer is pretty savvy so would probably want to be able to reconfigure things
• This approach is likely to have the least pitfalls (but to be the most 'fixed')

[xavier]

I'd go the relationship->role road too so 2 or 4.

(another reason of avoiding the smar tgroup is that they aren't always well exposed in the hooks and apis)

The rule approach seems to be more flexible. I wonder if it's possible to have the pre(or post) hook that calls the rule module directly, with the entity and action and let the rule triggers only if entity=relationship and action=create or update.

The rule flexibility might be a problem too. It depends on who is going to be guilty and have to fix it when random admin on the client side alters the rules and makes some content wide open.

X+

[Eileen]

I've been tinkering with rules today - I don't think anyone actually got it working in drupal 7 from what I see (probably parts of it work but not all).

What I think I'm seeing is that to really work with rules in drupal 7 you should define civicrm data type/s as an entity (either multiple entities like civicrm_event, civicrm_participant or 1 called civicrm_entity - not sure yet.) This seems to potentially have other advantages - ie. probably would open the way to drupal integrations such as views bulk operations & drupal search module. But it seems a bit green fields too.

One possibly block could be that it might be necessary to declare the schema & drupal doesn't support the date fields CiviCRM uses.

[Donald Lobo]

I'm working on some apache solr search integration for attachments (nyss project), and also had to create an entity for this integration. To make progress i created a real simple 'civiFile' entity and got things working.

looks like many integrations with drupal modules in the 7+ and 8 will require civi tables to be represented as entities. so we might want to start thinking about doing this in a nice unified manner, maybe making it part of gencode (the entity_info hook)

lobo

[Eileen]

Lobo - where is the code you did?

[Donald Lobo]

https://github.com/dlobo/apachesolr_civiAttachments

Note that most of the code is from apachesolr_attachments

the entity code was as minimal as possible to meet my needs for that project

lobo

[chiebert]

Timely! I was just searching the forums to see if anyone had considered going the (drupal) entity route for Civi integration, and here's the thread. Like Eileen, it was Rules (non)integration that prompted me to look (namely, token chaining), but as I read up on Drupal entities, it appears one does (potentially) get a lot more benefits along the way: (Drupal) tokens, views (including views relationships), rules, entityreference, etc.

What scared me off was hook_schema - it appeared to me that one needed to implement this in order to get (semi-automatic) table relationships going, but at the same time, doesn't Drupal use hook_schema to to things like create/delete tables when modules are enabled/disabled? Is there a way to declare the schema but stipulate it's read-only as far as Drupal is concerned?

I'm willing to work on parts of this because it would make some of my own work easier - but certainly don't have the chops to go it alone.

[Eileen]

Hey,

I am still having a go at the entity approach  - I have got to the point where I can do a data compare on rules - repo is here - but I haven't committed yet as pretty early days

https://github.com/eileenmcnaughton/civicrm_entity

but I'll push it up now anyway

[Eileen]

OK,

I've made some progress on this. I learnt quite a bit & had pretty good success exposing entities for Rules & some success with other entity-related functionality.

The nice thing about this variant of Rules compared to D6 is you can use the very-flexible data comparison function on pretty much any field so there is almost no need to define conditions. You can chain entities - although I have only enabled this for fields which refer to a civicrm_contact (have an FK)

I've written notes in the README https://github.com/eileenmcnaughton/civicrm_entity/blob/master/README.md

I included features for 2 workflows (just the most basic version of them)

1) Adding someone to a drupal role when they have a particular relationship type added / made active
2) Creating an OG for an event & subscribing participants to it

Things I hit in particular
1) The schema_hook expects your tables to be in the same database & threatens to put them there on install. I eventually decided that using hook_schema_alter probably gets you around the second of these - I only implemented for relationship_type which now semi-works as an entity_reference field (it saves but doesn't display)

2) The CiviCRM views implementation uses hook_views_data which seems to clash with the entity api usage approach. I think it would not clash if hook_views_data_alter were used.

[chiebert]

This sounds fantastic, Eileen - your test/example features, in fact, illustrate exactly what I'm facing over the coming weeks (granting roles based on relationships, adding event participants as members of OG groups for those events). I'm finishing some documentation for a client today, but I'll play with your code starting (hopefully) tonight.

Re. hook_schema: that's what I was afraid of, but hadn't wrapped my head around what the hook_schema_alter does.

Re. hook_views_data: Ultimately, if this Entity API implementation works as hoped, wouldn't it eventually replace the current CiviCRM Views, Rules, Contact Reference integration modules, incorporating various plugins/formatters/etc. along the way?

[Eileen]

Hi,

I think a cut down version of the views hook will probably still be required - although I would probably be reviewed over time. Basically all the special behaviours link special handlers would need to be declared in the hook - but not the normal fields.

I'm not sure the implications of changing the hook in the views module to being an alter hook.

Also, oddly in 4.3 I couldn't disable civicrm views integration. This seemed odd since views potentially  allows people on the drupal side to  access information on the Civi side they might not have access to? Perhaps this is completely covered off but It would be hard to be 100% about. If Civi entities start to get exposed to bulk operations & such like it would need some thought

Re the schema & lobo's point earlier about generating the schema hook from GenCode I've thought about that & am somewhat against it. The reason being that the schema hook is called during flush caches not regularly so I don't think any performance gains outweigh the rigidity of that approach (having to use a CiviCRM-version specific version of civicrm_entity integration or having to declare drupal schema in Civi Core & not be easily able to include extension tables). I am more inclined to use a function within civicrm_entity to query the various $dao->fields or api->getfields.

A last thing is that drupal would like a 'label' for each entity to be defined - either as a field or a function. I think it might be worth adding this to the CiviCRM xml table specification. I imagine the table spec might result in a  $dao->label function which would be over-ridable by a $bao function. So, for something like 'event' the $dao function might look like

function label(){return $this->title} and not be over-ridden

whereas for relationship type it might be overridden by a bao function that does something sensible about the 2 labels.

[Donald Lobo]

we need to be careful and not commit anything to trunk that potentially breaks the views integration

Once the entity stuff is in a more solid state and the views integration has migrated to use the entities (which also means views integration will have a maintainer), then we can do the switch

lobo

[Eileen]

The only thing I'm interested in committing to trunk is changing views so that the views data is defined via

hook_views_data_alter

rather than

hook_views_data

And making it so you can disable views integration.

It would be useful for the purpose of building up an entity approach if you could turn views integration off for some tables (so that it doesn't clobber things managed through the entity approach) At the moment I am only investigating the entity approach for a table not defined in views. However, the fact that it exposes the entity as an entity reference is interesting & makes it super tempting to do the same for the civicrm_event table.

[sonicthoughts]

This is very exciting!  Really opens up Drupal/Civicrm integration!

[sonicthoughts]

Also - this might be helpful: http://codekarate.com/daily-dose-of-drupal/drupal-7-entity-construction-kit