Hello, I have a module where I define a new node type (created with the usual hooks, hook_node_info(), etc.). The nodes of this type are created and updated when importing data from a remote server. In drupal, $user->uid == 1 has all the rights. I would like to prevent this user #1 from creating / updating such nodes. All users may view the nodes. What is the best way to accomplish this? Returning FALSE on hook_access() when $op != "view" doesn't work for user #1. thanks, augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
Augustin (Beginner) wrote:
Hello,
I have a module where I define a new node type (created with the usual hooks, hook_node_info(), etc.). The nodes of this type are created and updated when importing data from a remote server.
In drupal, $user->uid == 1 has all the rights. I would like to prevent this user #1 from creating / updating such nodes. All users may view the nodes.
What is the best way to accomplish this?
Returning FALSE on hook_access() when $op != "view" doesn't work for user #1.
A brute force method is to unset the form and redirect elsewhere in hook_form_alter if you are processing your node form and uid == 1. Cheers, Gerhard
On Wednesday 13 September 2006 08:24 pm, Gerhard Killesreiter wrote:
A brute force method is to unset the form and redirect elsewhere in hook_form_alter if you are processing your node form and uid == 1.
thanks Gerhard, I'll try that. Blessings, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
Augustin (Beginner) wrote:
On Wednesday 13 September 2006 08:24 pm, Gerhard Killesreiter wrote:
A brute force method is to unset the form and redirect elsewhere in hook_form_alter if you are processing your node form and uid == 1.
thanks Gerhard, I'll try that.
You'll also need to exit() after the redirect or the form would still be generated, IIRC. Cheers, Gerhard
On Wednesday 13 September 2006 08:53 pm, Gerhard Killesreiter wrote:
Augustin (Beginner) wrote:
On Wednesday 13 September 2006 08:24 pm, Gerhard Killesreiter wrote:
A brute force method is to unset the form and redirect elsewhere in hook_form_alter if you are processing your node form and uid == 1.
thanks Gerhard, I'll try that.
You'll also need to exit() after the redirect or the form would still be generated, IIRC.
Apparently, it's not necessary. I did the quick test below, and die() doesn't get executed, but if I add a drupal_set_message() to the redirect, then I have something that is good enough for my purposes. function demexp_form_alter($form_id, &$form) { if ($form_id == 'demexp_question_node_form') { drupal_goto('<front>'); die('forbidden'); } } thanks, A. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
I've learned that one should never call die/exit, since some functions will not be executed then (e.g. footer functions etc). 2006/9/13, Augustin (Beginner) <drupal.beginner@wechange.org>:
On Wednesday 13 September 2006 08:53 pm, Gerhard Killesreiter wrote:
Augustin (Beginner) wrote:
On Wednesday 13 September 2006 08:24 pm, Gerhard Killesreiter wrote:
A brute force method is to unset the form and redirect elsewhere in hook_form_alter if you are processing your node form and uid == 1.
thanks Gerhard, I'll try that.
You'll also need to exit() after the redirect or the form would still be generated, IIRC.
Apparently, it's not necessary. I did the quick test below, and die() doesn't get executed, but if I add a drupal_set_message() to the redirect, then I have something that is good enough for my purposes.
function demexp_form_alter($form_id, &$form) { if ($form_id == 'demexp_question_node_form') { drupal_goto('<front>'); die('forbidden'); } }
thanks,
A.
-- http://www.wechange.org/ Because we and the world need to change.
http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
On Wednesday 13 September 2006 10:44 pm, Johan Forngren wrote:
I've learned that one should never call die/exit, since some functions will not be executed then (e.g. footer functions etc).
you're right, but this was a quick test, and die() never got executed anyway. Anyway, the code below still does not work, because it also prevent user #1 to run cron.php which is needed to import the nodes. I'll add another check to see the requested URI to allow cron to do its job. function demexp_form_alter($form_id, &$form) { global $user; if ($form_id == 'demexp_question_node_form' AND $user->uid == 1) { echo $user->uid; drupal_set_message( t('You may not create or modify a demexp_question node'), 'error'); drupal_goto('<front>'); } It's not that urgent, so I still have time to look for the best solution. thanks, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
i'm looking at the node_access function, and I see that it'll return true regardless of your hook_access if your user has the 'administer nodes' permission, so your form alter will need to be user id independent (i.e., lose that uid = 1). another approach might be to intercept it earlier. Since the list of nodes that you can't edit are fixed after the import, in your hook_menu of the module you could add something like: foreach($imported_node_ids as $nid) { $items[] = array('path' => 'node/'. $nid .'/edit', 'title' => t('edit'), 'callback' => 'node_page_edit', 'callback arguments' => array($node), 'access' => FALSE, 'weight' => 1, 'type' => MENU_LOCAL_TASK); } } But i'm not sure if that would work, or if it should be in the cached or non-cached section (how does drupal negotiate conflicting menu definitions? yes, i should rtfm or at least the code...). - Alan On 9/13/06, Augustin (Beginner) <drupal.beginner@wechange.org> wrote:
On Wednesday 13 September 2006 10:44 pm, Johan Forngren wrote:
I've learned that one should never call die/exit, since some functions will not be executed then (e.g. footer functions etc).
you're right, but this was a quick test, and die() never got executed anyway.
Anyway, the code below still does not work, because it also prevent user #1 to run cron.php which is needed to import the nodes. I'll add another check to see the requested URI to allow cron to do its job.
function demexp_form_alter($form_id, &$form) { global $user; if ($form_id == 'demexp_question_node_form' AND $user->uid == 1) { echo $user->uid; drupal_set_message( t('You may not create or modify a demexp_question node'), 'error'); drupal_goto('<front>'); }
It's not that urgent, so I still have time to look for the best solution.
thanks,
Augustin.
-- http://www.wechange.org/ Because we and the world need to change.
http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
okay, i read the code and it says that menu item paths should be unique, so this solution isn't good. I think if your module's name started with a letter after n, this might work if you put it in the non-cached section. But another option would be to create a simple page that says 'you're not allowed to edit this item', and generate a bunch of aliases that point all the node/nid/edit paths to it. I've used this technique before (overriding module defined paths with an alias to change their behaviour) and it worked, though I've never heard of anyone else recommending it. Any opinions on this technique? On 9/13/06, Alan Dixon <alan.g.dixon@gmail.com> wrote:
another approach might be to intercept it earlier. Since the list of nodes that you can't edit are fixed after the import, in your hook_menu of the module you could add something like:
foreach($imported_node_ids as $nid) { $items[] = array('path' => 'node/'. $nid .'/edit', 'title' => t('edit'), 'callback' => 'node_page_edit', 'callback arguments' => array($node), 'access' => FALSE, 'weight' => 1, 'type' => MENU_LOCAL_TASK); } }
But i'm not sure if that would work, or if it should be in the cached or non-cached section (how does drupal negotiate conflicting menu definitions? yes, i should rtfm or at least the code...).
-- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/
participants (4)
-
Alan Dixon -
Augustin (Beginner) -
Gerhard Killesreiter -
Johan Forngren