The permissions I set as an administrator on a node (from the View/Edit Permissions section of the node) get overwritten and completely lost when a user with less privileges updates that same node.

i.e.:
1) As an admin I create a node and give role "ABC" rights to edit and view (from the View/Edit Persmissions section of the node)
2) Then log on with a user who is only in role "ABC", go to edit that node and save.
3) On the save, all the node permissions I set in step 1 are lost and the user can't access the node anymore.

I figure this has probably been reported as it's not a trivial problem. If you want a step by step procedure on how I replicate, let me know and I"ll post it.

Comments

dldege’s picture

I can confirm this behavior.

jondoesdrupal’s picture

Assigned: Unassigned » jondoesdrupal

Yep, I've replicated the issue too.

I've not been able to track down the issue but have some ideas which I'll take a look into next week. I think possibly this issue was there before and that the change from updates to delete / insert on the nodeapi update hook it wasn't so obvious.

Cheers,

Jon

dldege’s picture

I looked into this and for some reason between nodeapi 'prepare' and nodeapi 'update' the $node->node_privacy_byrole array becomes NULL. Since 'update' first deletes all records for the node the end result is a complete wipe of with no update.

A temporary workaround is to add a check for

if ($node->node_privacy_byrole) {
}

around the 'insert' code in the node_privacy_byrole_nodeapi to prevent this.

dldege’s picture

make that the 'update' case of nodeapi... for previous post not 'insert'

jondoesdrupal’s picture

If it's still available in the prepare phase, then probably a (slightly hacky) solution would be to copy it to another variable then use that in the update.

As for the correct solution, at a guess it could be that $node's probably meant to be passed to hook_nodeapi by reference and not by value as it's coded at the moment. Will investigate that possibility on monday.....

Cheers,

Jon

dldege’s picture

You might need to do your permission array loading in nodeapi "load" not "prepare" - I think this is the problem.

shift31’s picture

I'm experiencing this when creating new nodes (of any type). If I don't give a role the ability to edit permissions, no default permissions are set for the node.

smitcher’s picture

Hi,

We had been stuggling with this for several days until I simply added a node_privacy_byrole_nodeapi_prepare($node); to the update code BEFORE the DELETE so that the array is repopulated.

case 'update':
// As a new role might have been added since creation of the node, we cannot simply "update" and so delete and reinsert
node_privacy_byrole_nodeapi_prepare($node); // *** ADDED BY JJS ON 25/09/07 ***
db_query('DELETE FROM {node_privacy_byrole} WHERE nid = %d AND realm = "node_privacy_byrole_role"', $node->nid);
foreach ($roles as $rid) {
db_query('INSERT INTO {node_privacy_byrole} (nid, gid, realm, grant_view, grant_update, grant_delete)
VALUES (%d, %d, "%s", %d, %d, %d)', $node->nid, $rid, "node_privacy_byrole_role", $node->node_privacy_byrole['roles'][$rid]['view'],
$node->node_privacy_byrole['roles'][$rid]['edit'], $node->node_privacy_byrole['roles'][$rid]['delete']);
}
// Record for owner exists for sure, so we can simply update it
db_query('UPDATE {node_privacy_byrole} SET grant_view = %d, grant_update = %d, grant_delete = %d
WHERE nid = %d AND gid = %d AND realm = "node_privacy_byrole_user"', 1, 0, 0, $node->nid, $node->uid);
break;

It' seems to work for me but is there any reason why this shouldn't be done????

This function is also performed at the begining of the "prepare" block.

I haven't tested it extensively but it seems to maintain the permissions when someone with no ability to alter the permissions alters content of the node.

Regards,

John
Glasgow Caledonian University

deekayen’s picture

Assigned: jondoesdrupal » deekayen
Status: Active » Fixed

#8 committed

Anonymous’s picture

Status: Fixed » Closed (fixed)

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