The Protected Node module adds a field set to the Node Type form that you edit under:
Administer » Content management » Content types
These additions are explained in detail below.
The main reason for adding this feature is to avoid seeing the field set on all the node edit forms. With this feature you can hide the form on all the node types that you will never protect with a password.
This option let you choose how this node type handles the Protected Node capability.
This means this node type is never protected by Protected Node. This doesn't mean other modules cannot protect the node in some other way, of course.
The protection, if any, of existing nodes is ignored, but not removed. In other words, reverting to the default selection restores the initial protection status.
Use this with caution if you already have protected nodes (you can find out which are protected by creating a view.)
This is the default selection for all your node types.
This means, if unchanged, nodes are marked not protected when created. Authors with permissions can protect the node if they want to do so.
This setting is similar to the previous one, except that any new node is created protected by default (instead of unprotected.)
This is quite handy if you have a node type that in most cases requires protection.
This is the opposite of Never protected. Such nodes will be protected, no matter what. This means the password field becomes required if no global password applies.
Also, when going to the node, whether it has a valid password or not, one will be queried for. So in effect, such nodes without a password are only accessible by the author and administrators.
It is possible to setup this node type with a global password. This means any one node without its own password will make use of this node type global password, when defined.
This means you can now define one global password per node type, plus one master password (global to the entire website) in the global settings of the Protected Node module.
Because this feature requires an extra database access, the system really checks the password in this order:
That way we avoid a database access if the password is the node specific password or the global settings password. There should be no reason for this order to affect the results of this test.
The settings make use of the JavaScript password check so the administrator is told if the password is not strong.
When editing a node and you have the right to change the protected node settings, the module inserts a field set with the "Protected Node" flag, a password field, and a title checkbox. It may also include a text field to enter email addresses used to email the password to other users.
That field set can be shown closed or opened depending on this selection:
Always open and Always closed are self explanatory.
The default, Smart mode, behaves in the same way the Menu field set behaves when editing a node. That means it is generally closed by default and if the node is protected by the user, the next edits show the field set opened to clearly show that it is already protected.
Note that Smart mode is similar to Always open when the node type is always protected.
It is also possible that the field set is not even shown. This happens when the user does not have permission to change the password and/or when the node type uses Never Protected.