Would you consider a patch for inheriting node protections?
| Project: | Protected node |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Frank Steiner |
| Status: | needs review |
Hi,
this is just an idea so far and before I start implementing this I would like to ask if this had chance to make it into the module.
We sometimes want to protect a complete subtree with the same password, e.g. for groups of students which we don't want to give a login just to download materials. Say we have a menu tree
Group 1 -> Node 1
|-- Material -> Node 2
|-- Excercises -> Node 3
and Node 1 is a protected node with a password. Then when creating Node 2 and Node 3 and giving their menu entries "Group1" as parent menu, they should become protected nodes and inherit the password from Node 1 automatically. That's because our research assistants expect sth. similar to .htaccess where they could easily protect a whole subdirectory with just one password. With protected node as is, they tend to protect Node 1 but forget to protect Node 2 and Node 3...
I could add a "inherit from parent" checkbox in the edit form for the protected node settings (plus a global option if this should be on or off by default), and if that's checked, I would hook into nodeapis 'presave' (or insert/update) to test if
- the node has a menu entry
- that menu entry has a parent
- the node of that parent menu is a protected node
If that is all true, copy the password from that parent node to the current node.
Shouldn't be very difficult. Do you think this would make sense and might go in?
#1
I very much like the idea! Several weeks ago I promised a general solution will be implemented to solve the multi-node same-password problem along with many special cases discussed in feature requests of this module.
Currently I have no solid idea how to solve this general problem so your idea could come to rescue. If you're willing to implement this feature and send in a patch I will definitely merge it.
Thank you again!
#2
Hi,
here's the first try. Sorry in advance for the long post :-) The patch is quite large because of the many and sometimes complicated case distinctions.
The central changes are all in the nodeapi hook which has to distinguish a lot of cases, especially when updating or deleting a node. The rest of the changes are mainly helper functions to fetch or store information from/to the database or to handle menu trees.
Tolmi, my editor (xemacs) has a very different setting for text indents from yours, so all parts that I added or changed don't match your indent settings anymore. I re-indented the whole nodeapi and form_alter hooks because I chanced so much in them. I'm sorry for that but I couldn't work without indents :-(
The details are all explained in the nodeapi hook etc. Here I'll try to explain the genereal idea and the design decision that I had to take.
MA -> A
\- MB -> B
This allows to protect a complete menu subtree with the same password and is my best try to imitate the htpasswd/.htaccess functionality for directories. Nodes that are all below the same menu item, are similar to html pages in a common directory (especially when using pathauto it looks like this).
If I'm talking about "children of a node" in the following I mean that in the sense of B being a "child" of A in this picture.
When saving a node which inherits, it will try to fetch its parents password and store it for itself. If the nodes menu entry has children, it will pass the password to the children so that those which inherit from the node, can update their settings, too.
Thus, changing a password for a node can spread the new password through the whole subtree.
But of course, you can give any node in the tree its own password by unchecking the inherit checkbox and using a different password for this node.
When editing a node, the inheritance checkbox will be set to the global default if no record has been stored yet. You can chose to have inheritance checked by default to make sure you don't forget to protect a new node that you insert into your protected tree.
Thus, if you delete a menu entry for a node that inherits it will become unprotected, too, because it can't inherit a password anymore. You would have to uncheck the inherit box before deleting the menu item or moving the node below an unprotected menu parent to keep the inherited password for the node.
If we kept the values for the inheritance flags, things would get inconsistend if we changed some password or protection states and then turned inheritance on again. Then nodes would have their inheritance flag "on" while their parents could have different password. The only safe way is to turn off all flags when inheritance is disabled in the global settings.
But if you try to protect a subtree where some nodes have "inherit off" stored in the db (because the default was off at some time, or the nodes had a password before), it would be a lot of work to consider and changed all the nodes in the tree.
Therefore I added a "Activate inheritance for menu descendants once." option to the node edit form. If checked, it will activate inheritance for all the nodes children and save the nodes password for them. Thus, you can enter a password for a node and check this option and whole subtree will immediately inherit this password, no matter if they had own password or didn't inherit before.
If you uncheck "Node is protected" (or inherit from a non-protected parent) and activate the menu descendants options, the whole subtree will become unprotected.
I didn't implement bottom-up-inheritance for this because usually you cannot see the children of a protected node in the menu tree before entering the password for this node, so it shouldn't happen very often tyhat you view a protected child before the protected parent node.
Missing features:
I didn't try to hook into the menu editing page and I'm not sure if this can be done at all. If someone ever did sth. like that, let me know.
#3
Hmm, no one willing to test this and give me some feedback? :'-(
#4
Sorry but somehow I did not get any notification on this issue through my issue view so I completely missed that you posted a patch. I'll look into it as soon as possible. Thank you for your patience!
[If I don't reply in the future, just drop me a line through my contact page]
#5
Allright, thanks :-)
#6
Still on it, its just a huge patch :)
#7
Yes, sorry, I know it must be a hassle to test this :-( Testing took me longer than writing :-)
#8
Tolmi, can you let me know what your further plans are about this patch? I won't be able to rewrite this for every future release of the module for myself, so I will have to look for an alternative if there is no chance to get this patch included. I just need to know :-)
Thanks!
#9
Currently I can't promise anything as bug reports are in the queue and I intend to fix those first. After I've done with them I get back to your patch. Sorry for delaying this for so long but unfortunately I also have things to attend to besides developing modules for free. ;)
#10
Ok :-)