Extend API functionalities with lock/unlock

Extending the API with these is a good idea, I agree. Why don't you roll a patch and we can review your ideas more closely. Let me know if you need anything to proceed.

I'd love to.

I'm a newbie in drupal. Don't expect me to have it right from the beggining.
I assumed that $_SESSION['_protected_node']['passwords'][$nid] contains the right info. Is that correct?

Here is a first draft. Things are still missing.

/**
* This method checks if the user has entered the password for the given node id.
* Works only on protected nodes.
*
* @param int $nid The node id you wish to check for.
* @return boolean TRUE if the node identified by the nid you provided is unlocked by the user, FALSE otherwise.
*/
function protected_node_is_locked($nid) {
if (!protected_node_isset_protected( $nid )) {
return FALSE;
}
else {
// just check the stored session variable to see if a node has been unlocked
return !isset( $_SESSION['_protected_node']['passwords'][$nid] );
}
}

/**
* This method removes the password that was previously given by the user, thus requiring the password again.
* Works only on protected nodes.
*
* @param int $nid The node id you wish to lock.
* @return boolean TRUE if the lock was successful, FALSE otherwise.
*/
function protected_node_lock($nid) {
if (!protected_node_isset_protected( $nid )) {
return FALSE;
}
else {
if ( isset( $_SESSION['_protected_node']['passwords'][$nid] ) ) {
unset( $_SESSION['_protected_node']['passwords'][$nid] );
return TRUE;
}
else {
return FALSE;
}
}
}

/**
* This method unlocks the node by simulating the password submittion by the user.
* Works only on protected nodes.
*
* @param int $nid The node id you wish to unlock.
* @return boolean TRUE if the node identified by the nid you provided is unlocked, FALSE otherwise.
*/
function protected_node_unlock($nid, $password) {
if (!protected_node_isset_protected( $nid )) {
return FALSE;
}
else {
// MUST CHECK THE PASSWORD BEFORE SETTING THE SESSION VARIABLE
$_SESSION['_protected_node']['passwords'][$nid] = TRUE;
return TRUE;
}
}

Seems good for the first sight but let me help you a bit to streamline the process and better integrate you with the community. Here are my advices:

Name issues according to the problem/function they detail. I modified the title to better describe this feature. Also modifying the name of the issues is not advised except if the modified name better qualifies the intent of the issue. I think you didn't notice that the reply title (Issue title) for all comments on issues modifies the issue title, not the comment title. :) So no problem afterall, just clarifying this.

Also try to post patches and not inline code because it is a huge burden to copy over your code into the module code, check for any modified lines and if finished with the test remove your patch by hand. There is a tool for this tedious work which is called diff/patch on UNIX/Mac but equivalents exist on Windows too. So I suggest you use diff to create a patch from your modification and attach that patch to a reply to this issue. Let me show you an example: A comment with a patch. Also setting the Status of the issue to "patch (code needs review)" helps people (and me) to identify patches which need a review and/or test. This way more people can look at your work confirm and help you with suggestions.

Here are the relevant documents you need to read:
Drupal coding standards - You must adhere to the coding standards detailed in this document. This way we can all better undersand your intent and seamlessly work together. Also take a look at the Coder module which helps programmatically identify problems and coding standard deviations. It is a fantastic tool, no patch/module developer could live without it!

Creating a patch and Several Windows diff alternatives helps you create your patches. When finished, just attach the resulting .patch file to a reply and set the status as I suggested.

Also I want to mention that sometimes people seem harsh when they judge your patch, don't take it personally. Never ever. They just busy people trying to help. :)

Let me know if you need anything else and thank you for your contribution!

Thank you for your help. I really appreciate it.

Here is the patch file with the changes mentioned above.

Looks almost perfect except you need to use unified diff format. use the big U switch on the diff command or find the equivalent on your diff implementation.