Maintaining permissions sanity when node access is updated

I haven't tried it but maybe something like this would be safer, instead of those changes, I would just change the foreach loop here:

FROM THIS:

<?php

          foreach ($node->$field['field_name'] as $userreference) {
            $grants[] = array(
              'realm' => 'nodeaccess_userreference',
              'gid' => $userreference['uid'],
              'grant_view' => variable_get($var_name, 0),
              'grant_update' => variable_get($update_name, 0),
              'grant_delete' => variable_get($delete_name, 0),
              'priority' => 0,
            );
          }

?>

TO THIS:

<?php

          $grant_view = variable_get($var_name, 0);
          $grant_update = variable_get($update_name, 0);
          $grant_delete = variable_get($delete_name, 0);
          foreach ($node->$field['field_name'] as $userreference) {
            $grant = array(
              'realm' => 'nodeaccess_userreference',
              'gid' => $userreference['uid'],
              'priority' => 0,
            );
            if ($grant_view) {
              $grant['grant_view'] = 1;
            }
            if ($grant_update) {
              $grant['grant_update'] = 1;
            }
            if ($grant_delete) {
              $grant['grant_delete'] = 1;
            }
            $grants[] = $grant;
          }

?>

maybe

I can't comment on this directly, but when I used this module, I noticed a lot of non-intuitive behaviors (which I mostly solved using Rules). The behavior in this issue is view privileges being taken when edit privileges are added.

@danielb: Does this seem like a course of action that is worth committing? I'm not sure if directly granting all users view access is the best way to keep permissions sane when the desired behavior could be set in configuration tables; but if this satisfies bandrew's use case, then maybe it's a necessary option.

It seems like more options are necessary to make this module behave as expected.

I have made this change in the latest version.

I apologize for my php illiteracy, but I want to ask before this issue gets closed: How well does this update solve the "non-intuitive behaviors?"

In theory it should remove all those behaviours, let me know if you observe any more that this doesn't fix.

I'm still experiencing this issue with 6.x-1.4

If I set permissions for the user reference user to be able to edit the node then none of my anonymous users can view the node. If i disable this module then it goes back to normal opperation, but I need this module.

Artis

I figured out that by manually inserting a row in the node_access table just above the row that this module places with gid=0 and realm=all and grant_view=1 then it works.

Now we just need to figure out a way to do this automatically instead of manually.

artis

How about something like this?

after this line:
if (($grant_view || $grant_update || $grant_delete) && is_array($node->$field['field_name'])) {
add this:

          $grants[] = array(
                'realm' => 'all',
                'gid' => 0,
                'grant_view' => 1,
          );

I've tested - it's works for me!

First off, thanks MUCH for this module. Its intended purpose addresses what I need exactly.

With that out of the way :) ...has there been any more progress here? I am having issues with the latest release. What I did:

- I created a fresh Drupal 6.9 install with only two add-on modules - this one and CCK.
- I created a simple custom type with a couple of text fields and a user reference field
- I configured the user ref field to allow view and edit access to a user if they do not already have it
- I created an instance of this type as admin and associated it with a user

What I saw:

- The user had the reverse link on their profile
- Clicking it gets to a page that is the node, but without any fields...and no edit link
- Logged in as a different user (who is not referenced) gets the same behavior

To get things to work, I had to edit that content (as admin) and make an arbitrary change and save it. Then the referenced user could see all the fields and edit them (except their user ref field of course). The other (unreferenced non-admin user) now started seeing an "access denied" message when trying to access that node.

Beyond this issue, this thread also seems to imply that there are fixes for other issues that have not yet found their way into the latest stable release. Is there a release planned soon...or, if not, are any of the development snapshots fairly stable?

Thanks again!

Pretty sure the fix from #9 is all you need, I'll get around to patching it in soon, there is no snapshot with the fix.

Subscribing, this patch is vital to my project:)

The code from #9 has been added to the new release. You should not lose view access now.

Excellent! Thanks!

I'm starting to doubt the reliability of the fix i added from #9. It could override access from other modules.

Sorry guys I've had to undo this change and leave the module as is.
You will need to use another module to grant view access to the node - this is how it was designed to work.

In fact im using view_own module to grant view permisson to node owners and it works!!

I've brought up a subset of this issue at #1011126: Allow node author to see their nodes in case anyone here is still interested in seeing the author get view rights to their own nodes.