Posted by miraclegr on November 26, 2008 at 4:21pm
| Project: | Protected node |
| Version: | 6.x-1.5 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | AlexisWilke |
| Status: | closed (fixed) |
Issue Summary
Is there any posibility to have two more extra functions available for protected nodes?
One to check if the user has "unlocked" a node (i.e. has entered the password) and another to "unlock" a node (ie simulate the password form) by code.
This would be very handy when working with rules or other modules that interact with protected nodes.
Comments
#1
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.
#2
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;
}
}
#3
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!
#4
Thank you for your help. I really appreciate it.
Here is the patch file with the changes mentioned above.
#5
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.
#6
The patch should indeed use diff -du. 8-)
Now, the tests are nice but only apply to the current user. Maybe that's intended, but it looks somewhat wrong to me.
Also, I suppose you have another file that plugs in Rules to get the whole thing to actually work. Where is it?
Thank you.
Alexis Wilke
#7
This is done. See the Rules extension, especially.
Thank you.
Alexis
#8
Automatically closed -- issue fixed for 2 weeks with no activity.