I'd like to change the ownership of a node before it loads on the edit page to essentially transfer ownership of a node from one person to another. My goal is to give multiple users access to a single node.

I was looking through the Node API hooks and I was hoping that I could use either hook_load or hook_node_load and alter the $node->uid but both say this in the description:

This hook should be used to add information that is not in the node or node revisions table, not to replace information that is in these tables (which could interfere with the entity cache).

So unfortunately I can't use those hooks.

I noticed that hook_node_prepare allows you to "act on a node about to be shown on the add/edit form", however, it looks like the node access hook already runs before that hook does, because I run into an "access denied" message.

My goal was to avoid having to control access to the node, and instead, just transfer ownership so that it can defer access control to the currently installed node access module (Taxonomy Access) and the "Edit Own Content" permission. I didn't want to add more custom logic or additional node access modules on top of our existing access modules because it's already complex as it is and not recommended.

Is this the right approach or should I just cave and use hook_node_access (or some other access hook)? I'm worried about the implications of adding another layer of node access to our already complex system, but if it's the best way to do it, I will.

1 Answer 1


One possible solution might be to add a User Reference field to the node and add the Users you want to grant access to. Then in hook_node_access, check for that field, and return the proper access for view/edit/delete. Don't forget the value of the author field too, to preserve the original functionality. Basically, if the current UID is in the list of referenced users, return TRUE.

I feel like I have done this in the past in 7, but can't locate any code examples at the moment.

  • Thanks. I'm currently doing a POC very similar to your suggestion, except I don't want to have to maintain a list of users on each node. In my implementation each group of users will have an organization ID which I can use to determine who has access to each node.
    – Keven
    Jun 5, 2018 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.