This module could integrate much better with other acl solutions if it displayed the users currently in the node access tables, not just users previously entered in the user reference field. So a new description may read:

Allows you to configure a CCK user reference field so that the user whom is referenced in a node is granted access to view the node. Users with view, edit, and/or delete access will be displayed automatically in the field, no matter how permission was assigned.

Comments

mitchell’s picture

This feature would also allow views of node_access tables. :)

danielb’s picture

So how would you do this? It is not simply a matter of querying the table because the data is meaningless without the code from the module that created it. So you would have to call a certain function in each node access module for each user in the system for a particular node to determine who has access. This could be an expensive process. I'm not saying this is impossible but it might be too much of a task unto itself to include into this module as a feature.

danielb’s picture

Also what would you do if someone deletes the existing user that was given a permission through a grant along with a group of users for several nodes? How can you ever tell the original node access module not to restore a grant when it is asked for it? What if someone doesn't want the default users to be shown? Surely other modules should provide their own way of displaying who they give access to if needed, or another module could be made for this purpose.

mitchell’s picture

The data is meaningless without the code from the module that created it.

What about using ACL? I'm not sure this is necessary, but I updated #351761: Inclusion into Workflow module to discuss this.

Also what would you do if someone deletes the existing user that was given a permission through a grant along with a group of users for several nodes?

(initial response) If a user is deleted and the node that references the uid isn't updated at the same time, then the user should be removed from the user reference field next time it loads. (after some research) ACL can handle hook_user('delete') and remove orphaned {acl_user} records.

How can you ever tell the original node access module not to restore a grant when it is asked for it?

I don't think this communication is necessary. If the node_access modules were working together and had a common node_access tables, then a module reasserting its own records would be counterproductive.

What if someone doesn't want the default users to be shown?

CCK display fields options. Views would be ideal to display any or all of the associated users.

Surely other modules should provide their own way of displaying who they give access to if needed, or another module could be made for this purpose.

I disagree with both points :) This module currently moves half of node_access (the configuration) into the node form; with this feature, it would move configuration and display into the node form, and it would fulfill its name.

danielb’s picture

What about using ACL? I'm not sure this is necessary, but I updated #351761: Compatability with other node_access modules to discuss this.

I'm not sure the slightly increased compatibility is really worth it considering it would really require a rewrite of this module, and introduce an unnecessary dependency for the bulk of the functionality.

(initial response) If a user is deleted and the node that references the uid isn't updated at the same time, then the user should be removed from the user reference field next time it loads. (after some research) ACL can handle hook_user('delete') and remove orphaned {acl_user} records.

I meant deleted from the user reference field, not deleted as being a user. How do you update grants from other modules?

I don't think this communication is necessary. If the node_access modules were working together and had a common node_access tables, then a module reasserting its own records would be counterproductive.

But they will reassert their original records. I don't know of how to revoke access that some other module is providing.

CCK display fields options. Views would be ideal to display any or all of the associated users.

I meant on the 'add' and 'edit' pages of the node. It could be confusing to authors to show users granted access by other means. I often have several node access modules working together to provide access for different sorts of users by different means.

I disagree with both points :) This module currently moves half of node_access (the configuration) into the node form; with this feature, it would move configuration and display into the node form, and it would fulfill its name.

The UI in the node form is nothing to write home about. The guts of what you're talking about is in discovering the data that you need to prefill that form - and then being able to manipulate access given by other modules. This is a lot different to what this module does.

danielb’s picture

Status: Active » Closed (won't fix)

I haven't found any way to solve this problem without using ACL, which is not a perfect solution since not every module people use will be using that, or without calling node_access() for every user and op, which is very inefficient and won't work on sites with many users.
I really think if you wanna go down such a tough route, you could do it in another module and you'd be able to also hook in and change the forms and access created by this module.