| Project: | Spam |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
admin/content/spam is useful, because it allows the user to see both node and comment spam in one page. it could do with some improvements though.
#1 - allow delete from admin/content/comments/list/spam
It would be good to allow the user to delete spam nodes and comments directly from this page. Obviously this would be somewhat redundant, as the functionality is already provided by admin/content/comments/list/spam and admin/content/node, however bringing them all together would make the workflow much quicker, and less confusing for new users.
#2 - provide link to spam
admin/content/spam currently provides a link to the comment edit form via the title of the comment (ie. comment/edit/15138). The link on the title of the comment should instead re-direct to the actual comment (ie. path/to/node#comment-15138), and a separate link should be provided to edit the comment, probably in the same was as it's done on admin/content/comments/list/spam - with a column called "operations", and a link called "edit".
Obviously neither of these are critical, and I might have a crack at it some time in the future, depending on how much time I have.
Comments
#1
#1 -- that's already available. It's not in admin/content/spam, though -- maybe that's what you meant? I thought it'd be useful to have it there too; I think the reason that it's not is due to the potential difference in deleting different kinds of content. Really, when I think of it in those terms, I almost think the admin/content/spam page shouldn't exist, and instead spam administration should happen in each individual content type. Not sure what the usefulness is of seeing ex. comment and profile spam in the same place. But I'll probably leave it as-is unless my worries actually start being realized.
#2 -- agreed. Not a massively high priority, but a link to the comment makes more sense. That will get changed at some point. Should be a one-liner, as soon as I get a chance to look at it.
#2
#1 - yes, that's what I meant. I agree this is a bit convoluted. The other problem is the lack of consistencey between comment spam (which has it's own tab), and content spam (which doesn't). Removing the admin/content/spam page would make it difficult to place the feedback tab anywhere though.
I think the best solution would probably be to move ALL spam related admin pages to admin/content/spam, and have separate tabs for content and comments. Also move the admin/settings/spam page there too*, so you end up with 5 tabs:
* there are a number of other modules that are doing this, and it make far more sense. No point cluttering the admin page, and the admin/settings/spam page still relates to content really...
#2 - And then generally try to make the node spam and comment spam tables have similar features to the admin/content/(comment|content) tables, plus the relevant spam stuff..
#3
There'd have to be a tab for user profile spam as well. And what happens when somebody uses the API to write another content module? Seems like that menu would get pretty cluttered itself.
I think I'd prefer:
* perhaps an Akismet-style overview page; I don't know how useful that would be, so I'd think for UI purposes that would be better used as a "statistics" page that is farther down the menu list
* a "Spam" page, with all types of content marked a spam, and a clearly exposed filter to allow you to just see ex. comment spam if you wish
* "Feedback"
* and on whatever the front page of these would be, a link to the spam settings page in Settings. I have never liked combining the "action" and "settings" pages -- when I'm looking for module configuration, I like the ability to click on "site configuration" and look for the module. That's more intuitive to me. But a link to the Settings page would remedy that for those for whom it isn't.
This will probably all wait a while -- I want to leave the 6.x-1.x version untouched for a little bit (save new issues) and put a beta release out if it's as stable as I'm hoping it proves to be.
#4
A combined spam page as well as per-content-type spam pages was requested based on user feedback in earlier iterations of this module, if I remember correctly. I suppose getting rid of the per-content-type pages isn't a big deal if it's possible to filter the overview page on a per-content-type basis. Less redundancy, and in the end probably more powerful.
The location of the Settings page is one of those things that never seems to be right. Wherever you put it, it works for some and not for others. That said, it really isn't important to me where it ends up, so move it if you like.
#5
subscribe
#6
Hrm, I'm just having a poke around trying to get the delete function in there. This is what I have so far, not sure if it's the best way to go about it (and it doesn't actually work yet):
diff -u spam/spam.module /var/www/drupal/sites/all/modules/spam/spam.module--- spam/spam.module 2009-08-10 13:03:11.000000000 +1000
+++ /var/www/drupal/sites/all/modules/spam/spam.module 2009-11-17 15:43:27.000000000 +1100
@@ -1337,7 +1337,7 @@
'#suffix' => '</div>',
);
// Set desired callbacks as a subset of spam_spam_operations().
- $options = array('markasnotspam'=>array(), 'publish'=>array(), 'unpublish'=>array());
+ $options = array('markasnotspam'=>array(), 'publish'=>array(), 'unpublish'=>array(), 'delete'=>array());
$alloptions = module_invoke_all('spam_operations');
foreach ($options as $operation => $array) {
$options[$operation] = $alloptions[$operation]['label'];
@@ -1488,6 +1488,11 @@
'callback' => 'spam_operations_callback',
'callback arguments' => array('unpublish'),
),
+ 'delete' => array(
+ 'label' => t('Delete'),
+ 'callback' => 'spam_operations_callback',
+ 'callback arguments' => array('delete'),
+ ),
);
return $operations;
}
@@ -2108,3 +2113,14 @@
cache_clear_all();
spam_update_statistics(t('publish @type', array('@type' => $type)));
}
+
+/**
+ * Invoke delete action for given content type.
+ * TODO: Integrate with the Actions module.
+ */
+function spam_delete($type, $id, $extra = array()) {
+ spam_log(SPAM_VERBOSE, 'node_delete', t('deleted'), $type, $id);
+ spam_invoke_module($type, 'delete', $id, $extra);
+ cache_clear_all();
+ spam_update_statistics(t('delete @type', array('@type' => $type)));
+}
#7
Might be better to start with some actual planning, now that I think of it.
These are the major changes that I'd like to see on :
Anything else?
#8
Regarding your "150 characters of the node/comment" -- from which field? What if it's a CCK content type?
In general, I like everything you're proposing. However, I wonder if it makes more sense to make each their own issue, to avoid this from turning into such a big issue we never can close it?
#9
150 characters: true, I was obviously thinking body, which should be fine for comments (which is probably where it's most useful anyway). It also won't work for users. For Nodes, I would say body, since it looks to me like the body can't be removed?. I dunno.
I think only the last two would be worth breaking out, since the others are small - the user blocking one is here #704194: "block author" or "mark author as spam", and someone else can do the IP one, since I don't use it (maybe it's not that big anyway?)
#10
#11
From #984698: spam operations, on the current method of hard-coding the actions available in the spam admin page but pulling the op definitions themselves from the submodules:
...while the current code (which pulls the op definitions from the modules) is useful, it seems odd to pull the op definitions from the modules but hard code which ones we want. Maybe that should be provided too, in a nodeapi sort of way.
Thing is, our UI/UX isn't well-defined enough for us to be doing that yet...
But I agree -- I can see where it seems like contributed submodules should be able to "hook into" the options box to provide more options somehow. ...should they, though? Or should they, instead, contribute different filters (e.g. spam measurement metrics) and content types, but should the actions provided by spam itself be static?
#12
IMO: ideally we should use Ajax to provide the proper controls depending on which types of content are being displayed... if all types are displayed, only display options that are compatible with all types of content. If only comments are displayed, display all options that are compatible with comments. Etc.
#13
Seems rather heavy, I think -- especially considering that most pages don't filter based on content, but show a specific content type (or all types) statically. We'd be implementing AJAX solely for the drop-down box, and it'd fire once, on page load, since the content type can't change.
Is there any example of it being done like this anywhere else?
#14
Ah, good point. It wouldn't need an Ajax call at all. Regardless, as we're trying to support all types of content I think it makes sense to filter the options based on what types of content are being displayed.
It's potentially confusing either way: 1) if we display all possible actions for all possible content types, it's not clear what actions work for which content types and thus performing some actions will simply be ignored, 2) admins may not realize that they first have to filter to a given content type and then perform an action...
So, to do this right, I think we'd need to:
1) Provide inline documentation explaining how it works using hook_help()
2) Cleanup the callback processing so we can find a lowest common denominator of available operations defined for all content types, versus callbacks only available for a specific content type, displaying the appropriate when appropriate
#15
Again, though, most of those pages aren't "filtered" on the user side. They're "pre-filtered," I guess you could say, by their SQL to pull only their content type. They're not going to change. They don't even have a front-end filter available for content types (including the poorly-named "Content" page, which actually presents only nodes).
The only exception to that is the main Spam content list page. And for that page -- yes, it could get confusing when you have potential actions that don't work with certain content types.
And for that, I'd point to point #1 in comment #1 in this thread :) that we discussed long, long ago. I think in general, spam is best *administered* in the specific content areas. We can still *list* all spam if we want, as a sort of log -- but we should probably call it that, so it's clear that (other than perhaps deletions) this is not the place to really manage your spam submissions.
Personally, I've rarely found a time when I wanted to manage my spam independent of its content type, except for when I wanted to bulk-delete old spam all at once -- and frankly, the all-spam list page is poor for that too, since it paginates them all so I can only delete 20 or whatever at a time. So I don't think there's really a lot of good use for that page as it stands now.
#16
+1 for delete, link to spam, and probably more
I think admin/content/spam/list is a great place for this stuff. On a site with thousands of nodes and comments its hard to administer from the other pages. If its not in admin/content/spam, then admin/content/node needs a way to filter by marked as spam.
#17
Here's a quick fix to link to view the spam, instead of edit it.