It's many times I come across this type of behavior, and I don't have the right to unpublish or delete the book pages.
But I can change their parent! so how about a hidden book page named 'to delete' or something similar which could be used in that case to get these useless pages out of the main drupal.org flow, until someone with the proper rights come and delete them.
PS: hidden book page means it would not be advertised on drupal.org, but just available in the parent drop down list when you edit the page.
Only who has the rule of site maintainer (or higher) is able to delete the content created by another user.
Rather than moving a book page (which still needs to be deleted), to report the spam in the Drupal.org webmasters queue is the only solution possible.
I am changing back the metadata of this report because the user has not been blocked.
» Add an "invisible" to move the spam book pages in
Component:
Spam
» Redesign
Category:
task
» feature
I blocked the user, who has not created any posts, so far.
I changed the title to reflect what the feature request is.
As I already reported, I don't think it's a good idea to create such a book. This could create more confusion, and it would not simplify the site maintainers' tasks.
Users who are not able to move book pages would report the spam content in this issue queue, and that would be done also when the content type used to create spam content is not a book page, or when the spam is in a comment. At this point, site maintainers should check the content of the "invisible" book, and still check their issue queue for any spam reports.
There are issues created dealing with "flagging" spam content - I'm not sure if anything is being done about that for the redesign. But that would be a better way to handle the spam problem.
I am setting this report as "won't fix".
The way the spam is handled will be probably changed, but the feature requested here doesn't help with the spam (and it will not be adopted).
Comments
Comment #1
bertboerland commentedhandbook page deleted, user (http://drupal.org/user/212631) not blocked yet...
thanks for reporting
Comment #2
scor commentedIt's many times I come across this type of behavior, and I don't have the right to unpublish or delete the book pages.
But I can change their parent! so how about a hidden book page named 'to delete' or something similar which could be used in that case to get these useless pages out of the main drupal.org flow, until someone with the proper rights come and delete them.
PS: hidden book page means it would not be advertised on drupal.org, but just available in the parent drop down list when you edit the page.
Comment #3
vm commentedQueue cleanup:
moving to redesign for consideration.
Comment #4
avpadernoOnly who has the rule of site maintainer (or higher) is able to delete the content created by another user.
Rather than moving a book page (which still needs to be deleted), to report the spam in the Drupal.org webmasters queue is the only solution possible.
I am changing back the metadata of this report because the user has not been blocked.
Comment #5
avpadernoI blocked the user, who has not created any posts, so far.
I changed the title to reflect what the feature request is.
As I already reported, I don't think it's a good idea to create such a book. This could create more confusion, and it would not simplify the site maintainers' tasks.
Users who are not able to move book pages would report the spam content in this issue queue, and that would be done also when the content type used to create spam content is not a book page, or when the spam is in a comment. At this point, site maintainers should check the content of the "invisible" book, and still check their issue queue for any spam reports.
Comment #6
avpadernoI am fixing the issue title.
Comment #7
silverwing commentedThere are issues created dealing with "flagging" spam content - I'm not sure if anything is being done about that for the redesign. But that would be a better way to handle the spam problem.
Comment #8
avpadernoI am setting this report as "won't fix".
The way the spam is handled will be probably changed, but the feature requested here doesn't help with the spam (and it will not be adopted).