I'm working on a project that involves group ownership and editing of nodes. The rules that determine the visibility and editability of nodes are complicated, such that I'm having to roll my own node access code (that is, I couldn't find a module that would provide the kinds of control I need).
The following scenario is causing me some grief:
- Alice and Bob are part of a group, and are working on node 123. Node access entries exist that allow Alice and Bob to both edit the node under "normal" circumstances.
- Alice edits node 123, and so becomes the "owner" of the node, in the sense that the uid field of the database entry for node 123 points to her.
- Bob now edits node 123; he becomes the owner.
- Alice, who has some degree of admin privileges in the group, takes the node private: She should be able to edit it, but Bob shouldn't. "Taking the node private" means setting up some node access entries that are meant to deny access to the node to everyone but her.
- However, since Bob is the most recent person to have edited the node, he's still the "owner of record", and node/123/edit is available to him, as a result of the standard node access rules regarding node ownership. (This is how I'm thinking about it, anyway.)
Any ideas for how I can get around this, and keep Bob blocked from editing the node? I've thought about:
node_updatehooks that would force the uid of the node to always point to Alice; the node access entries would allow Bob to edit the node when he's supposed to be able to. Might work, but this seems questionable/risky/horrifically hackish at best.
Maybe there's a hook that would reach down into the access system and let me test whether a request for
node/123/editshould be permitted based on the current user and system state?
Any other possibilities out there? Thanks!