Inheritance as a permanent setting
| Project: | Nodeaccess |
| Version: | 6.x-1.2 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | mantyla |
| Status: | active |
Jump to:
Hi,
maybe this is already possible and I just don't understand how ;-)
I have some roles with their default settings. Then I revoke view permissions for a certain page "A" for all but one role "R", because I only want this single role to be able to view the page (actually the whole subtree, but I think you are planning this kind of inheritation in 2.0, right?).
Now, when I add a new role some time and give it a "view all" default setting, I don't want the new role to be able to view "A" because I intended a "no one but role R" view setting for "A". So far, the new role will have its defaults applied to all node which don't have a entry for the new role. To avoid this, one would need a field for specifying settings for "future roles" when editing a node.
Then I could remove the "view" settings for "future roles" and thus no new role could view page "A".
Otherwise I would have to go through all node where I ever changed access settings and make sure the new role gets the right permissions.
I guess this should not be too hard conceptually: adding a database entry for "future role", filling it for every node that gets its setting changed from the defaults and when editing a node with non-default access settings, use the settings from "future role" for every role that does not yet exist in the database entry for this node.
Do you think this could be implemented for the 2.0 release? Together with inheritance, this would allow to e.g. make a "intern" section with many nodes that would all be accessible to just one role ever.
cu,
Frank
#1
I think the feature you ask for is in fact the default behaviour. In 1.2, every node has either manual (per-node) or default grants. Unless you look at the contents of the nodeaccess table, there is nothing to indicate which nodes have manual however, which does get confusing and will be fixed in 2.0.
The way everything should work is that once the grants of an individual node have been edited, the defaults cease to apply to it completely. Changing the defaults will have no effect on it, and adding a new role with defaults will also have no effect: grants for the new role will become editable (if the role is allowed), but all values will default to not allowed when the node already has manual grants.
The only exception to the above is author grants. All nodes will always use the default author grants for their type.
If you have nodes with manually edited grants, and when you create a new role and give it defaults, and these defaults are applied to manually edited nodes, then that is a bug that needs to be fixed. I guess I'll have to test this myself and see if I can confirm this, either way.
By the way, the way I implemented inheritance in 2.0 isn't quite as useful as you envisioned it. I included an option that makes new nodes inherit the grants of their menu parent, but this only works when the node is created - afterwards the grants function like regular manual grants. But your suggestion of making the inheritance status permanent, so that you can edit the grants of an entire menu tree at once, does have merit. I'll have to think about adding it in a future version.
#2
Hi mantyla,
sorry that was my fault, I re-checked now and saw that I confused node-privacy-by-role and nodeaccess :-) node-privacy-by-role set the values for new roles to the defaults even for nodes that were manually edited. Sorry for the false alarm and thanks for your help!
About the inheritence I'm currently implementing this feature for the protected node module (patch will be published at http://drupal.org/node/286028). I'm using the menu tree for this too, but moving nodes around in the menu or changing a nodes password or inheritance status will always go through possible children and adjust their settings. Their are many situations to be considered like moving a node out of the menu which means that the former children of this node will have to inherit possibly different values from the nodes former parent etc. Inheritance can be turned on or off on a per-node base and this will also affect the nodes subtree.
Maybe you can use this patch to see which cases must be considered, or maybe we can try together to port this for nodeaccess.
#3
Actually, the more I thought about this idea, the better it seemed. It is a powerful function with a strong use case speaking for it. And so, I decided to delay v2.0 to implement this first.
I've already started and finished the required changes to the admin interface. And there are plenty of things to consider: not only the logic of how everything works, but also the permissions. I want to be able to clearly restrict things like who can set a node to use inherited grants.
And the real important stuff I came up with was that a node can have any combination of the three grant types: manual, default or inherited. When inheriting grants from a parent, a node receives a combination of them all, so that you can add new grants manually on each menu tree level. Until now, a node could have only one type of grants at a time, manual or default.
It'll take me some time to finish, but I'm getting there.
#4
This is great news! I just hope that no one will blame me for delaying the 2.0 release ;-)
#5
subscribing