I have a structure of organisations and centres, where each organisation has a number of centres. I use this module for the organisations, so an you can assign permissions to edit for a user via a user reference field. I would like it so that someone who can edit an organisation automatically has access to edit the centres that relate to the organisation (via a node reference field) - so basically i want to permissions to come from a user reference in a related node rather than the actual node. A feature like this would be extremely handy, and if not as a feature some help / pointers on how to implement this myself would be most appreciated (I code php, but am unfamiliar with some of the drupal structures).

Comments

exobuzz’s picture

exobuzz commented

I've hacked some code in the module to implement this for my site (hardcoded fieldnames etc just to test)

      if ($field['type'] == 'nodereference') {

        foreach ($node->field_organisation as $nodereference) {
          
          $refnode = node_load($nodereference);
          foreach ($refnode->field_user as $userreference) {
            if ($userreference['uid']) {
              $uid = &$userreference['uid'];
              if (!isset($grants[$uid])) {
                $grants[$uid] = array(
                  'realm' => 'nodeaccess_userreference',
                  'gid' => $uid,
                  'priority' => $priority,
                  'grant_update' => 1,
                  'grant_delete' => 1,
                  'grant_view' => 1
                );
              }
            }
          }
          
        }
      }

Having this as a proper feature with configuration would be great.

danielb’s picture

danielb commented

this gives me a brilliant idea
'node access node reference' gives access based on whether the user has access to the referenced nodes
then it wouldn't depend on the user reference method, but would still work for it...

exobuzz’s picture

exobuzz commented

That would be excellent, and I would be very interested in such a module!

Another thing I thought about but don't know if it would be possible, would be if the referenced node with the user reference had another user added, it could rebuild the permissions for the nodes that referenced it. Otherwise a complete permissions rebuild has to be done.

danielb’s picture

danielb commented
Status: Closed (fixed) » Active

the grant ids would be the referenced nids, not the users... that would be too mind boggling

edit: nope I'm wrong about that

exobuzz’s picture

exobuzz commented

so if a new user was given access to the referenced node, a permissions rebuild would be required before any nodes referencing it also gained the permissions ?

danielb’s picture

danielb commented

Yeah. We could also write some code to only rebuild the nodes that reference the updated node.

exobuzz’s picture

exobuzz commented

i guess that would need to cascade down, i mean you could create a node reference to a a node with a node reference to another node etc. (and it would have to make sure it doesn't get into an infinite loop in case someone made a loop with references)

danielb’s picture

danielb commented

I'm going to pretend you didn't bring that to my attention...

exobuzz’s picture

exobuzz commented

I shall remain silent :) Please let me know if you want me to do any testing of your new module.

danielb’s picture

danielb commented

I am almost finished writing the new module - might take me some time to get around to testing it out since it seems like a big job to test it.
The way it works is that it only checks one level of nodereference for access. It might work to chain them if the referenced nodes are always older than the nodes doing the referencing. But a circular reference won't work to give access because one of these nodes must be referencing a newer node.

So basically this module will work best if SOME OTHER nodeaccess module is giving access to the referenced node. Such as nodeaccess_userreference or node_access.

chipt4’s picture

chipt4 commented

Subscribing - I have a 'Contact' node type that can reference a user. I'd like to use this to select my contact node type, rather than the user directly.

kenorb’s picture

kenorb commented

subscribing

Crell’s picture

Crell commented

This seems like a very flexible way around the "OG is too heavy and nothing else works" access problem. I may have to look into it for an internal project we're working on. Do you have an ETA for this issue, or a pointer to the new module you mention?

danielb’s picture

danielb commented

http://drupal.org/project/nodeaccess_nodereference

Sorry I've been a bit busy and haven't got to really test it out, just had to get my idea down on paper so to speak. As you'll see the design of that module requires it do a lot more work than a typical node access module. The problem comes from the fact that during a node access rebuild, there are no records in the node_access table to use (because the first step of a rebuild is to wipe the table). So nodeaccess_nodereference has to make a copy of this table when it realises that a rebuild is needed.
I imagine there are a few situations I haven't thought of that will need to be patched, even once that main functionality is working.

kenorb’s picture

kenorb commented

Thanks Daniel,
I'll try it.

danielb’s picture

danielb commented
Status: Active » Fixed

OK I'm gonna mark this as fixed. Let's continue this in the nodeaccess_nodereference project.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kenorb’s picture

kenorb commented

I've done something similar to nodeaccess_nodereference but from scratch
http://drupal.org/project/nodeaccess_autoreference
and it's working differently.
It's scanning for referenced nodes by recurrence and it's checking for permission on nodeapi level.
Hopefully you don't mind Daniel for similar name?

UPDATE:
Can you update your Package category to:
package = Node Access
? in .info file?
I think it's a good name for module category, simple access using this as well.

Status: Active » Closed (fixed)

Correcting issue status, see #2125263: Issue status not taken from last comment during D7 migration.