Password fields should be mandatory

It is supposed to be.

However, the system doesn't check whether the global password was defined, and therefore allows you to save without a password if a global password is allowed.

This means, if your global settings say something else than "Per node password", then that's the expected behavior.

This being said, you should not be able to set something else than "Per node password" without also entering a global password. So I would imagine that you good on that one.

Oh! Note that an empty text field for password is to be expected, whether or not you defined a password already. In other words, if you entered a global password at any one time, it is there. The form just doesn't show you that it is defined... This is the same behavior as when you edit a user account. The password is just empty.

Anyway, the validation is done in protected_node_nodeapi() (.module) and uses a flag $missing_password to know whether the password is missing. If so, it checks whether the global password is authorized. If not, it generates an error.

      if ($missing_password) {
        switch (variable_get('protected_node_use_global_password', PROTECTED_NODE_PER_NODE_PASSWORD)) {
        case PROTECTED_NODE_PER_NODE_PASSWORD:
          // $arg is the form in this case
          form_error($arg['protected_node']['protected_node_passwd'], t('To protect this page, please enter a password.'));
          break;

        }
      }

Thank you.
Alexis Wilke

eL,

Okay! Fixed. The permission test was using the variable $form which is not defined in this function. Instead, I simply use the $node->type.

Thank you.
Alexis

See: http://drupalcode.org/project/protected_node.git/commit/92df7f2

Okay, I checked in a fix for anonymous users. That should force anonymous users to enter a password, always.

The other problem I'll check later, but yes, the author should always be able to edit and the problem was most certainly introduced in beta2.

Thank you.
Alexis

Author editing prevented... I think beta2 introduced that problem by offering the option to force protected nodes to default to "protected."

Do you think we should assign a random password in this case? (assuming that no Global password is available) Since otherwise it is an invalid node!

The password won't be necessary for the author anyway (except if the author is the Anonymous user.)

Thank you.
Alexis

eL,

Hmmm... Just had something occurred to me...

The "Edit page password" is whether you can edit the password in a page.

You actually need to have the "Edit page content" permission or Drupal Core won't allow you to edit anything anyway.

The function that checks to know whether you have the right to edit is this one:

function protected_node_is_locked($nid, $op = 'access');

The $nid will be the node you're trying to edit and $op is set to 'edit'. The first test makes sure that the node is protected. If not, you can edit without password. The second test checks whether the user is logged in. If not, you enter the Anonymous user case. Right now, we'll consider the other case... and we find the third test as shown here:

if ($node->uid === $user->uid) ...

This test checks whether the node was created by the user currently logged in. If that is true, the function returns immediately with FALSE meaning that the node is "not protected" (at least for the current user and mode selected.)

Because it returns FALSE, the calling function (protected_node_init() hook) does not redirect you to ask you for the password.

Have you verified that the node was saved with the right author? (just in case that got messed up somehow...)

Thank you.
Alexis Wilke

eL,

Two questions:

(1) Could the users you are talking about be given the permission: "bypass password protection"? That way they would be able to edit the node they created. The problem is that the bypass is for all the nodes... yet it won't give them rights to edit if they don't have "edit any content type".

(2) If you cannot/don't want to give them that permission, could you create another type that logged in users would use instead of the one defined for anonymous users?

All in all, what you are asking is a quite complex case it seems, which I think will easily be solved by making use of Drupal in a larger extend. Having two node types, one for registered users and one for anonymous users seems to be the easiest approach. Then anywhere you need to handle those nodes, you just have to remember to manage both types. Shouldn't be a big deal...

Thank you.
Alexis

eL,

Cool. That makes sense, but using the "bypass password protection" is "dangerous" in case you'd like to later give those users the ability to protect some of their nodes.

Therefore, creating a different node type is probably wiser.

Can we mark this issue as fixed now? 8-)

Thank you.
Alexis Wilke