User login

Disable delete for regular users

Searched words: 
drupal prevent from deleting wiki drupal wiki pages delete drupal delete access

Conclusion: Because Drupal 6 finally introduces delete permissions separate from edit permissions, Agaric's motivation for providing truly proper behavior went the way of "why do today what's been done for you tomorrow?"

Instead, we present a dirty hack.

A tweak to Agaric's form tweak module that:

  • switches off delete capability for non-"administer nodes" users for all content types.
  • uses only form_alter, the swiss army knife of Drupal hooks (nodeapi is the duct tape). Security of preventing deletes by a registered user injecting form information has not been tested, but I think Form API prevents anything like that from succeeding. Using only form_alter is still obviously a hacky approach.
  • has no user interface
  • to be honest all it does is remove the delete button on nodes and the whole form at node/*/delete

Download the form_tweak no-delete edition zip file here
[Post edited with corrected links.]

You may be better off with this dirty hack, in a way, because I'm not sure you you run the upgrade script for Drupal 6 if you were to use the patch made for Drupal 5 (in my opinion, this should have been included in 5.3, but then, I didn't even know to vote.)

Note that because form_tweak wants to work on all node forms in uses $form['#id'] in a switch statement rather than the customary $form_id argument.

Report back:

Which modules do I need for a basic Wiki behaviour?
http://drupal.org/node/163157

Allow edit but disable delete?
http://drupal.org/node/19475

(That person needed "an easy way to allow a user to edit a node, but not delete it" and ended up hacking Drupal core to tweak "the page module's page_access function so there was a seperate permission for edit and delete pages." This is back in 2005.)

Users with 'maintain books' or 'edit own book pages' permission cannot delete book pages
http://drupal.org/node/21559

(Above is a long, old thread but with a patch, never committed, to allow users to delete their own book pages. Apparently book.module does something special to take away the delete button. I'm going to go out on a limb here and guess that the way it does it is not best practice, given the complete mess - lack - of edit versus delete permissions everywhere else.)

I think I heard that "delete" permission will be separated out from "edit" in

The Drupal form help is useless:

http://api.drupal.org/api/function/drupal_get_form/5

Or more particularly the good stuff I'm sure is somewhere but impossible to find:

Drupal's Broken Links problem

Look how many links are broken here
http://webdevgeeks.com/drupal-forms-api

maybe should all point to:

Forms API
http://drupal.org/node/37775

drupal

8:44pm] ben-agaric: hello Drupal world... I'm about to make a small simple (I hope) module that allows admins to disable delete capability for users who have editing rights, per node type
[8:45pm] Xabstract left the chat room. ("Ex-Chat")
[8:46pm] ben-agaric: I've done my due diligence and this is a last check to see if anyone knows of a 'do not delete wiki pages' module
[8:46pm] ben-agaric: Furthermore I plan on doing this with form_alter, because it's the only hook I know how to use
[8:47pm] ben-agaric: Speak now or forever hold your peace. Thank you.

drupal-dojo, the friendliest room on all of IRC

ben-agaric: it's the Token error that threw me
[8:20pm] ben-agaric: Delete permissions. That's my question-- has anyone ever made an actual module to take away the ability to delete, but leave the ability to edit, for certain content types? (Think wiki.)
[8:20pm] ben-agaric: It's a hook_perm and a hook_form_alter and maybe a settings page, but has anyone done it yet?
[8:21pm] Senpai: ben-agaric: I don't think i've ever seen that.
[8:21pm] Senpai: would it be content-type agnostic?
[8:21pm] Senpai: or would it be a mod to an existing module?
[8:21pm] Senpai: sorta like patching CCK to turn on or off that 'feature' ?
[8:22pm] ben-agaric: Yeah, I'm thinking I'd spend the extra 10 minutes to make it so you could turn it on and off for any content type
[8:22pm] Senpai: ben-agaric: hmm, bad. You'd have to know the name of each content type before making a hook_perm for it?
[8:23pm] Senpai: That could go on for pages!
[8:23pm] ben-agaric: I wouldn't want to just add a 'delete foo' permission to the node listing in admin/user/access because that's already a nightmare
[8:24pm] ben-agaric: plus its a negative permission-- take away the right to delete from people who can edit
[8:24pm] Senpai: I wonder if you can even catch that on a form_alter...
[8:24pm] ben-agaric: So I was thinking you would enable it per content type, and that would make the (anti) permission appear on admin/user/access
[8:24pm] Senpai: It'd be like adding a locked door to a page AFTER the user was already inside?
[8:25pm] Senpai: or perhaps its not that bad
[8:25pm] Senpai: maybe you'd just need to make a hook_perm for each generic content type
[8:26pm] Senpai: and then allow the admins to enable the ability to prevent deletion of nodes
[8:26pm] Senpai: that sounded weird.
[8:26pm] Senpai: Turn on delete-blocking.
[8:26pm] Senpai: I don't even know how to describe that!
[8:26pm] fireangel left the chat room.
[8:27pm] ben-agaric: Yeah, it hurt my brain too.
[8:27pm] ben-agaric: But you can't have a wiki if anyone can delete it.
[8:28pm] ben-agaric: Since that takes all the revisions with it.
[8:28pm] Senpai: Have a look at wiki modules, and patch one?
[8:28pm] Senpai: actually, OG might already have this worked out
[8:28pm] ben-agaric: It's a pretty simple standalone. I would think it were in some, but I haven't found it.
[8:29pm] ben-agaric: Well groups.drupal.org has at any rate I think.
[8:29pm] Senpai: the groups.drupal site allows users to create a wiki-like posting, but not everyone can delete the content
[8:29pm] Senpai: but I'd guess that its built in to the OG module
[8:29pm] Senpai: and has nothing to do with a stand-alone wiki module of any sort
[8:29pm] Senpai: not a very lightweight solution for a small site, methinks
[8:29pm] ben-agaric: Uh, actually--
[8:30pm] ben-agaric: could you test? It's telling me I can delete content, at a place where I don't think I have any special permissions.
[8:30pm] Senpai: gimme a linky
[8:30pm] ben-agaric: "Are you sure you want to delete GMap API.txt 5.x rewrite?
[8:30pm] ben-agaric: This action cannot be undone.
[8:30pm] ben-agaric: Cancel"
[8:31pm] ben-agaric: http://groups.drupal.org/node/6949/edit
[8:31pm] Druplicon: http://groups.drupal.org/node/6949 => GMap API.txt 5.x rewrite => 2 IRC mentions
[8:31pm] Senpai: i'm a site admin, so I'll use a non logged in browser
[8:31pm] Bdragon: hmm?
[8:31pm] ben-agaric: Then you won't be able to edit.
[8:31pm] Senpai: ok, anon peoples can't do anything
[8:31pm] Senpai: figures
[8:32pm] Senpai: well, i have delete perms for that node, but then again, I'm supposed to
[8:32pm] Senpai: we need someone's account
[8:32pm] • Senpai hacks Bdragon's username for a sec
[8:32pm] jt_jones joined the chat room.
[8:32pm] Senpai: Bdragon: are you a site admin for g.d.o?
[8:32pm] Bdragon: Nopers
[8:33pm] Senpai: cool. Would you test something?
[8:33pm] Bdragon: Sure
[8:33pm] Senpai: Go to one of your groups, and read a wiki post
[8:33pm] Senpai: Then see if you can edit it
[8:33pm] Senpai: and you should not have a delete button
[8:33pm] Senpai: I rather suspect that if it's your own post, you'll be able to delete it
[8:33pm] Senpai: but if it's someone else's, you won't.
[8:35pm] Bdragon: I have a delete button on http://groups.drupal.org/node/6063/edit
[8:35pm] Druplicon: http://groups.drupal.org/node/6063 => Using Teamspeak to Teach a Lesson => 2 IRC mentions
[8:35pm] Senpai: ben-agaric: Well, there you go!
[8:35pm] Senpai: A fix is in order!
[8:36pm] ben-agaric: All right, I'm on it. In the meantime guys
[8:36pm] Senpai: I still think you'll need to know the name of the content-type in advance tho.
[8:36pm] ben-agaric: keep this quiet, we don't want the mad hordes deleting every wiki page on drupal.org ;-?
[8:37pm] ben-agaric: When is hook_perm called? Only on module initiation or something?
[8:37pm] ben-agaric: CCK creates new permissions somehow.
[8:37pm] Senpai: You might wanna query for all content-type strings in the node table, and build a select menu out of them for the admin page?
[8:37pm] Senpai: "Choose a content type to affect"
[8:37pm] Bdragon: when you go to the permissions page, IIRC
[8:37pm] Senpai: THEN
[8:37pm] ben-agaric: yup
[8:38pm] Senpai: "Turn off delete permissions for the chosen content"
[8:38pm] Senpai: ben-agaric: I believe that hook_perm gets hit up every time that module's content is accessed
[8:38pm] Senpai: or is that hook_access....
[8:39pm] Senpai: wiat, I remember.
[8:39pm] • ben-agaric runs to get my Pro Drupal Development book
[8:39pm] Bdragon: hook_perm is only needed to figure out what permissions there are
[8:39pm] Bdragon: Otherwise, the system is completely passive...
[8:39pm] Senpai: perm is what makes the checkboxes on the admin/access page
[8:39pm] Bdragon: Were you thinking of hook_access?
[8:39pm] nomad411_away joined the chat room.
[8:40pm] Senpai: hook-access lets you check to see if the current user is allowed to get this content, based upon the chosen boxes on the admin/access page
[8:40pm] Senpai: that's the one.
[8:41pm] ben-agaric: hook_perm sets permissions (page 90, heh)
[8:41pm] ben-agaric: and then I'm going to use user_access() in a form_alter
[8:42pm] ben-agaric: Or would this be terribly wrong?
[8:44pm] Senpai: ben-agaric: hook_access can't really be used in a form_alter
[8:44pm] nomad411_away left the chat room. ("Leaving")
[8:44pm] Bdragon: You can add a #validate handler...
[8:44pm] Senpai: The module just needs to know if the currently loggen-in user has permission to delete those nodes
[8:45pm] Senpai: what if you just hid the delete button?
[8:45pm] ben-agaric: if I take out the delete button entirely, no one can use it, right?
[8:45pm] Senpai: it's not terribly secure, by any means
[8:45pm] ben-agaric: unset()
[8:45pm] ben-agaric: I'm pretty sure it is secure that way
[8:46pm] Senpai: well, you've have to check for a valid user who was allowed to delete content, and if not, form_alter the delete button away
[8:46pm] Senpai: cause if you don't go about it like that, I'm pretty sure you won't be able to override another module's hook_access settings with your own module
[8:47pm] Senpai: So then youre back to patching someone else's mod
[8:47pm] nomad411 left the chat room. (Read error: 110 (Connection timed out))
[8:47pm] Senpai: and that's actually not a bad idea
[8:47pm] Senpai: since it'd keep Y.A. contrib mod out of the pot
[8:47pm] Senpai: and lend some great functionality to an existing thing
[8:48pm] Senpai: That;s the whole goal of a community, isn't it?
[8:48pm] ben-agaric: I can't think of the right place to put this
[8:48pm] ben-agaric: Because an angel stayed my hand before I committed my form_tweak module
[8:48pm] Senpai: there's a form_tweak?
[8:49pm] ben-agaric: and the wiki functionality is pretty fragmented right now, and semi-incompatible
[8:49pm] Senpai: form_tweak?
[8:49pm] Senpai: Is there an actual wiki.module?
[8:49pm] ben-agaric: no, there's not. Really, I almost did, but was stopped.
[8:49pm] Senpai: http://drupal.org/search/node/wiki+category%3A14
[8:49pm] ben-agaric: All form_tweak does is get rid of preview buttons.
[8:50pm] Senpai: ahhhh!
[8:50pm] Senpai: Nice one!
[8:50pm] ben-agaric: Maybe I should commit it and add this.
[8:50pm] Senpai: But did you know that most modules already respect the admin settings for 'disable preview button'?
[8:50pm] ben-agaric: ... and add the check that keeps you from disabling your ability to submit forms, if you fail to make them optional first.
[8:50pm] ben-agaric: Where are the admin settings for disable preview button???
[8:52pm] • Senpai looks
[8:53pm] ben-agaric: 'cause the only sensible spot is where you make preview optional -- and form_tweak just takes away the option
[8:54pm] Senpai: ben, look in admin/content/node-settings
[8:54pm] Senpai: oh darn
[8:54pm] Senpai: that was a 4.7 thing
[8:54pm] Senpai: That feature is actually a good idea to subit to the Utility module
[8:55pm] Senpai: utility?
[8:55pm] Druplicon: Utility is the most awesome module ever. Download it from http://drupal.org/project/util
[8:56pm] ben-agaric: Hmm, has it resolved its admin page conflict with module_weight yet? Oh wait, I was supposed to do that.
[8:56pm] • ben-agaric kicks self.
[8:56pm] jt_jones left the chat room.
[8:59pm] • ben-agaric turned both modules off and stopped thinking about it. OK, I'll post these things to the feature queue and try to get a co-maintainership
[9:02pm] Senpai: Util has a conflict?
[9:02pm] Senpai: I'd never noticed
[9:03pm] ben-agaric: actually, if memory serves, it's module_weight's fault-- it adds the weight select box to each module in a way that breaks the collapse fields

[9:36pm] Michelle: Reading up a bit... I had someone ask me how to make it so a user couldn't delete their nodeprofile node. Didn't have an answer for them. I'd like to have a separate delete permissionm
[9:36pm] Senpai: If there was a Deleteness.module that could look up all available custom content types, sort them alphabetically into a select dropdown and present it on the admin pages, the module could then form_alter that specific content type to add an '#access" => 'false' to each node in the user didn't have the 'delete this content' role.
[9:44pm] Michelle: That would be cool

Resolution

http://data.agaric.com/sites/default/files/form_tweak-no-delete-alpha.zip

Comments

Found a link that works

Post new comment

The content of this field is kept private and will not be shown publicly.
  • You may post code using <code>...</code> (generic) or <?php ... ?> (highlighted PHP) tags.
  • You can use Markdown syntax to format and style the text. Also see Markdown Extra for tables, footnotes, and more.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img> <blockquote> <small> <h2> <h3> <h4> <h5> <h6> <sub> <sup> <p> <br> <strike> <table> <tr> <td> <thead> <th> <tbody> <tt> <output>
  • Syntax highlight code surrounded by the {syntaxhighlighter SPEC}...{/syntaxhighlighter} tags, where SPEC is a Syntaxhighlighter options string or "class="OPTIONS" title="the title".
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.