Closed (fixed)
Project:
Freelinking
Version:
5.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
19 Feb 2007 at 10:58 UTC
Updated:
5 Nov 2008 at 23:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
stevryn commentedYeah I thought that was kind of odd that you cant delete a freelink from the table. It seems like this wouldn't be too difficult to add to that overview page.
Comment #2
awgrover commentedAlso, if you make a typo, you get an entry that haunts you forever.
To automatically clean up the list (delete freelinks that aren't _from_ somewhere), we'd have to search all content. Is that even doable? We'd have to look inside CCK, new node-types, etc. Yech.
Comment #3
eafarris commentedThe only purpose the freelinking table serves is to display that list, so it's safe to just delete all content from that table ("DELETE FROM freelinking") from time to time. The page will get re-populated as freelinks are followed.
It would be difficult to keep that table up to date as content changes, without some serious restructuring of the module (which I'm not opposed to).
However, a simple delete function to remove one record from the table should be a pretty easy patch.
Comment #4
zeroyon commentedI agree I think its pretty silly that you can't "As an Admin" selectively delete items from the freelink table.. You would think that during the course of design this would have be a "No brainer".. If a revision could be made that let's you select terms from the freelink table and push delete, without having to run queries on the database that would be good...
Comment #5
spidermanJust ran across this issue recently, and have rolled the following patch this morning. I've basically stolen the technique used on the admin/content/node page, found in node.module in the function node_admin_nodes and friends. I've added in a pager and tablesort feature (see #192263) as a bonus.
NB: There is probably a security issue in the way I've done the _submit hook for the new freelinking_page_form, since it doesn't doublecheck permissions at this point. Presumably someone could post the form through some other means (bypassing the security around the form rendering code) and sneak delete operations in nefariously, yes? Would a simple user_access("administer freelinking") check surrounding the entire submit hook suffice? Would we also need this in the freelinking_multiple_delete_confirm_submit hook?
Comment #6
spidermanI noticed that the tableselect checkbox only selects the currently visible links, so I've added a "delete-all" operation which allows the admin to remove ALL freelink entries.
Comment #7
spidermana fresh version with a fix of the 'suffic' typo in the options fieldset form element.
Comment #8
spidermanAlso just noticed that I'd lied about the tablesort feature above, so rolled that in, too :)
Comment #9
spiffyd commented@#8 this patch is against which module version? it'll also be nice if u can attach the attached mod directory in a zip :)
and this is for 5.x correct? won't work for 6.x?
Comment #10
spidermansorry, i should've rolled the patch against a CVS checkout, but yes, it's for DRUPAL-5 (latest -dev tarball or 5.x-1.3-beta2 should be fine) and won't work against 6.x (tho porting it is probably relatively straightforward, i don't have time or inclination, atm)
Comment #11
eafarris commentedImplemented as part of freelinking-5.x-1.4. Thanks for the excellent patch, spiderman! Very well done.
Comment #12
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.