When a user is given update permissions to a node through a user relationship. That user can edit the node.
The only problem is when the user does edit the node, it looks like the node_access is rebuild because after updating the first time, the update permission is gone.

When I look into the node_access table I can see that the permissions from user relationship is gone.

I used version RC2 and DEV version...

Members fund testing for the Drupal project. Drupal Association Learn more


buzzman’s picture

any updates for this? ... bump

Related problem here too. I believe this could belong here, but do advise if it needs to be a separate issue:

Only "view" node_access that is granted by the user is respected by the system. if "update" and/or "delete" is also selected, they don't work - as in I still get "access denied" on the node edit page. I'm using version RC2. has this issue been encountered by anyone and if so, plz reply with which version of UR is this resolved?

I need to get this resolved at the earliest with someone's help.

Thanks for reading.

buzzman’s picture

I corrected my problem of the "system not respecting update/delete node_access set via UR". There was an issue with the permissions with different user roles on the site. Fixed. But I did hit the original bug-report above. So yes I can confirm that after a user updates node to which s/he has been granted permission, on redirect from form submit action, the edit link disappears. I'm using UR vs. RC2.

Plz help sort this issue as it's keeping me from using the UR node_access module (within UR).


alex.k’s picture

Status: Active » Fixed

Committed a fix http://drupal.org/cvs?commit=309334. Thanks for the report. Please test once the -dev release is updated and post your results.

buzzman’s picture

is it possible to have a patch for the RC2 version?
I have done some experimental code changes which will b lost if I switch to dev version.

thanks in any case Alex. much appreciated.

alex.k’s picture

Status: Fixed » Closed (fixed)

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

Rob_Feature’s picture

Title: Node access » Node Access Data Lost When Editing
Status: Closed (fixed) » Active

Reopening this issue. I'm seeing this behavior in the July 11 6.x-1.0-dev version (or something similar). When a node is saved with ur_node_access data, the permissions are added to the node. However, if that node is edited by someone not the node author (I'm editing with user 1), there is no longer a "post to social network" box anywhere on the node edit screen. So, if the node is then saved (when no box is present) then the permissions are removed.

Somehow, ur_node_access info isn't loading into the node when someone other than the author is editing.

mrf’s picture

Component: Code » Node Access
Issue tags: +6.x-1.1
mrf’s picture

Title: Node Access Data Lost When Editing » Node Access Data Lost When Edited by Different User
mrf’s picture

Confirmed this one. Got the following notice on submit with a user that didn't have anything but edit permission for the node type:

Notice: Undefined property: stdClass::$user_relationship_node_access in user_relationship_node_access_nodeapi() (line 254 of /Sites/drupal6/sites/all/modules/user_relationships/user_relationship_node_access/user_relationship_node_access.module).

And then this notice when the original user went back in to try and edit:

Notice: Undefined variable: object_type in user_relationship_node_access_form_alter() (line 158 of /Sites/drupal6/sites/all/modules/user_relationships/user_relationship_node_access/user_relationship_node_access.module).
mrf’s picture

Diff of the previous commit mentioned on this thread:

diff --git a/user_relationship_node_access/user_relationship_node_access.module b/user_relationship_node_access/user_relationship_node_access.module
index 148180c..0a5757d 100644
--- a/user_relationship_node_access/user_relationship_node_access.module
+++ b/user_relationship_node_access/user_relationship_node_access.module
@@ -276,10 +276,7 @@ function user_relationship_node_access_nodeapi(&$node, $op, $a3 = NULL, $a4 = NU
   case 'load':
-    $node->user_relationship_node_access = unserialize(db_result(db_query(
-      "SELECT permissions FROM {user_relationship_node_access} WHERE nid = %d",
-      $node->nid
-    )));
+    $node->user_relationship_node_access = _user_relationship_node_access_load_node_perms($node->nid);
   case 'delete':
@@ -328,6 +325,11 @@ function user_relationship_node_access_node_access_records($node) {
   $grants = array();
+  //#629774 ensure that node access data is loaded in the node, need this when node is edited by user other than node author
+  if (!isset($node->user_relationship_node_access)) {
+    $node->user_relationship_node_access = _user_relationship_node_access_load_node_perms($node->nid);
+  }
   if (isset($node->user_relationship_node_access) && is_array($node->user_relationship_node_access)) {
     foreach ($node->user_relationship_node_access as $rtid => $permissions) {
@@ -355,6 +357,20 @@ function user_relationship_node_access_node_access_records($node) {
+ * Load UR-NA permissions for a node
+ * @param $nid node ID
+ * @return array {access key based on rtid} => {array of allowed actions on a node}
+ */
+function _user_relationship_node_access_load_node_perms($nid = NULL) {
+  if (!$nid) {
+    return NULL;
+  }
+  return unserialize(db_result(
+    db_query('SELECT permissions FROM {user_relationship_node_access} WHERE nid = %d', $nid)
+  ));
mrf’s picture

Closed #897040: How do you save UR-node_access using node_save() as a duplicate of this issue, but need to make sure to test node_save as well as a different user to make sure both cases are solved.

Xenza’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev

in the version for drupal 7 dev

I appear to have fixed it by editing the user_relationship_node_access.module

edited function user_relationship_node_access_update_node($node)

function user_relationship_node_access_update_node($node) {
    global $user;
    // If user is not allowed to effect perms, do not change access settings
    $allowed_grants = _user_relationship_node_access_get_allowed_grants($user);
    if (!count($allowed_grants)) {
    // If no content type isn't included, do not change access settings
    if (!_user_relationship_node_access_node_eligible($node)) {

    $user_relationship_node_access = array();
    if (!empty($node->user_relationship_node_access) && count($node->user_relationship_node_access)) {
        // Reformat the array and optimize.
        foreach ($node->user_relationship_node_access as $action => $permissions) {
            // @todo: The new set_default button results in a warning. Find a better way to avoid a
            // notice.
            if (!is_array($permissions)) {

           //if the grants actions is not set return
            if (!isset($allowed_grants[$action])) {

            foreach ($permissions as $key => $permission) {
                // Make sure user is allowed to set this permission
                if ($allowed_grants[$action] && $permission) {
                    $user_relationship_node_access[$key][$action] = TRUE;

        // Clear old settings, this will actually clear even ones that user is not
        // allowed to set.
                ->condition('nid', $node->nid)

        // Save permissions if any are set.
                    'nid' => $node->nid,
                    'permissions' => serialize($user_relationship_node_access),
    $node->user_relationship_node_access = $user_relationship_node_access;

Sorry but i don't know how to make patch or etc....

hope that this helps anyone experiencing this issue

auraell’s picture

Thanks for the info! It fixed my issues.

mrf’s picture

Status: Active » Needs review
1.66 KB

Patch with the fix provided by Xenza above.

Status: Needs review » Needs work

The last submitted patch, user_relationships-node-access-data-loss-15.patch, failed testing.

Berdir’s picture

Status: Needs work » Needs review

Looks like the test fails are unrelated.

Berdir’s picture

Status: Needs review » Fixed

Thanks for the patch, commited to 7.x-1.x.

Status: Fixed » Closed (fixed)
Issue tags: -6.x-1.1

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