6.x-1.4 breaks the functionality of the module
nonsie - October 16, 2008 - 17:01
| Project: | Protected node |
| Version: | 6.x-1.4 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
In 6.x-1.4 release there are no longer node types available on admin/settings/protected_node and viewing a protected node returns access denied instead of the password field.

#1
Yes, there is a regression in place, that's true. This is by intent. Placing node type selection for protection candidates and access control group regulations were duplicate functionalities.
The 6.x-1.4 drops the admin/settings/protected_node node type selection in favor for access control. Somehow indeed, the README.txt didn't made it into the package nor I wrote a note on the project page. I am terribly sorry and fix these immediately!
#2
There should be a setting that causes all nodes of a certain type to require a password.
Use-case: You want all nodes of type "private telegram" that are created to have a password by default. If the user does not enter one, it should throw an error.
#3
Also, what if you want regular users to be able to put passwords on _certain_ content, but not other content, and you want, say, an admin or editor to be able to password protect additional types of content?
#4
@Coyote: Either I not understand your specific use-cases very well or the functionality to do this is already in place.
You can set which groups can password protect which node types, right? So why don't you set the broadest possible access rights for your editors and they can choose which specific nodes they protect by checking the checkbox on the node editing page?
Or did I misunderstood something?
#5
Think this is abandoned.