Closed (won't fix)
Project:
Node access user reference
Version:
6.x-1.2
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Jan 2009 at 20:34 UTC
Updated:
28 Feb 2009 at 13:56 UTC
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
Comment #1
mitchell commentedThis feature would also allow views of node_access tables. :)
Comment #2
danielb commentedSo 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.
Comment #3
danielb commentedAlso 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.
Comment #4
mitchell commentedWhat about using ACL? I'm not sure this is necessary, but I updated #351761: Inclusion into Workflow module to discuss this.
(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 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.
CCK display fields options. Views would be ideal to display any or all of the associated users.
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.
Comment #5
danielb commentedI'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.
I meant deleted from the user reference field, not deleted as being a user. How do you update grants from other modules?
But they will reassert their original records. I don't know of how to revoke access that some other module is providing.
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.
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.
Comment #6
danielb commentedI 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.