Moodle Community Sites
  1. Moodle Community Sites
  2. MDLSITE-1619

Enable spam to be deleted at the click of a button

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Component/s: moodle.org
    • Labels:
      None
    • Rank:
      33595

      Description

      Following on from Martin's comment in MDL-29067, it would be great if we could have a block on each user profile page containing a 'Delete all content from this user' button which when clicked would check

      1. Whether the first access date/account creation date is less than 1 month ago
      2. The number of forum posts, comments and personal messages sent by the user

      Re. 1. we'd assume that spammers have a newly created account, so checking the first access date would be a way of safeguarding accidental deletion of content.

      If the first access date was more than a month ago, the following message could be displayed:

      'The first access date of this account is more than 1 month ago and so the content from this user cannot be deleted.'

      If the first access date was less than a month ago, the following message could be displayed:

      'You are about to delete

      x forum posts
      y comments
      z personal messages

      and block the account of Sidney Spammer.'

      with a continue button.

      Clicking on the continue button would delete the content, set the account authentication method to 'No login' and add 'Spammer - account blocked' with a date stamp to the description field.

      Re. deleting forum posts, an alternative would be to blank them and insert the phrase 'Content removed by a moderator' with a date stamp. This would avoid the problem of orphaned posts (when users have replied to spammers).

        Issue Links

          Activity

          Hide
          Helen Foster added a comment -

          In addition to setting the account authentication method, it would be good if the user picture was deleted and any interests, optional and other fields blanked.

          Show
          Helen Foster added a comment - In addition to setting the account authentication method, it would be good if the user picture was deleted and any interests, optional and other fields blanked.
          Hide
          Martin Dougiamas added a comment -

          +1 for all this.

          To be specific about the deletions for user X:

          Comments: Anything by user X can be deleted from the table
          Messages: Anything FROM (not TO) user X can be deleted from both the message tables
          Forum posts: Any post by user X should have the text updated to "Content removed by moderator at 12:30pm 14th December 2011"
          Glossary entries: Any entry by user X can be deleted

          Show
          Martin Dougiamas added a comment - +1 for all this. To be specific about the deletions for user X: Comments: Anything by user X can be deleted from the table Messages: Anything FROM (not TO) user X can be deleted from both the message tables Forum posts: Any post by user X should have the text updated to "Content removed by moderator at 12:30pm 14th December 2011" Glossary entries: Any entry by user X can be deleted
          Hide
          Helen Foster added a comment -

          From chat with Raj, we agreed that the block should be called 'Spam deletion' and the description field string 'Spammer - spam deleted and account blocked Thursday 15th December 8:30 AM'.

          Show
          Helen Foster added a comment - From chat with Raj, we agreed that the block should be called 'Spam deletion' and the description field string 'Spammer - spam deleted and account blocked Thursday 15th December 8:30 AM'.
          Hide
          Rajesh Taneja added a comment -

          Getting Back to this issue today

          Show
          Rajesh Taneja added a comment - Getting Back to this issue today
          Hide
          Rajesh Taneja added a comment - - edited

          Block is ready for peer-review

          Steps to show block:

          1. Block should be placed on site front page, and then edited to be visible on all pages.
          2. Go to user profile and edit block to be visible on this page only.
            Note: User should have block/spam_deletion:spamdelete capability to see this block.

          After hitting spammer button

          1. All messages sent by the user will be deleted
          2. All user comments will be deleted
          3. Forum post and blog subject and summary/message will be replaced with Content removed by moderator at Wednesday 1st February 5:35 PM

          Working:

          1. If the first access date was more than a month ago or user has never accessed account, then you can't delete that user
          2. If user is suspended or deleted then you can't delete user
          3. By default user data stats will be visible
          4. You can search for spam by string or using default keywords and stats will be visible.
          Show
          Rajesh Taneja added a comment - - edited Block is ready for peer-review Steps to show block: Block should be placed on site front page, and then edited to be visible on all pages. Go to user profile and edit block to be visible on this page only. Note: User should have block/spam_deletion:spamdelete capability to see this block. After hitting spammer button All messages sent by the user will be deleted All user comments will be deleted Forum post and blog subject and summary/message will be replaced with Content removed by moderator at Wednesday 1st February 5:35 PM Working: If the first access date was more than a month ago or user has never accessed account, then you can't delete that user If user is suspended or deleted then you can't delete user By default user data stats will be visible You can search for spam by string or using default keywords and stats will be visible.
          Hide
          Martin Dougiamas added a comment -

          Dan can you review this and help get it onto moodle.org?

          Show
          Martin Dougiamas added a comment - Dan can you review this and help get it onto moodle.org?
          Hide
          Dan Poltawski added a comment -

          Some comments on this - I can pick these up if you want:

          • We have 'search' functionality for bad content, this duplicates the other tool which does this searching and I think we should keep this block simple and leave it out.
          • I think we should default to not giving the capability to any archetype as we'll create a custom role allowing access to the block
          • I'm don't think the way you are working out the user from the page url params will be robust enough (at least I saw problems with it) and warnings about undefined index id on line 102.
          • It doesn't allow you to delete users who have never logged in
          • There are a few places where you set the content->footer to an error message, this should be content->text to be displayed, and also we should return after setting the error message to avoid any potential bugs where access checks are skipped.
          • The spammer class could use instance variables to avoid doing as many db queries and simplify the code
          Show
          Dan Poltawski added a comment - Some comments on this - I can pick these up if you want: We have 'search' functionality for bad content, this duplicates the other tool which does this searching and I think we should keep this block simple and leave it out. I think we should default to not giving the capability to any archetype as we'll create a custom role allowing access to the block I'm don't think the way you are working out the user from the page url params will be robust enough (at least I saw problems with it) and warnings about undefined index id on line 102. It doesn't allow you to delete users who have never logged in There are a few places where you set the content->footer to an error message, this should be content->text to be displayed, and also we should return after setting the error message to avoid any potential bugs where access checks are skipped. The spammer class could use instance variables to avoid doing as many db queries and simplify the code
          Hide
          Rajesh Taneja added a comment -

          Thanks for the inputs Dan,

          1. We have 'search' functionality for bad content, this duplicates the other tool which does this searching and I think we should keep this block simple and leave it out.
            • Difference here is, it search for bad words entered by the current user. The spamcleaner tool (existing tool), searches for all users. This was added, to let admin do search for the user and don't have to go to other place in site.
          2. I think we should default to not giving the capability to any archetype as we'll create a custom role allowing access to the block
            • Will remove the default capabilty
          3. I'm don't think the way you are working out the user from the page url params will be robust enough (at least I saw problems with it) and warnings about undefined index id on line 102.
            • I couldn't find any other way to get user_id. It will be helpful, if you can suggest the way.
          4. It doesn't allow you to delete users who have never logged in
            • If user has not logged in then he cannot enter bad words, hence should not be deleted by spam clearer. So was done intentionally.
          5. There are a few places where you set the content->footer to an error message, this should be content->text to be displayed, and also we should return after setting the error message to avoid any potential bugs where access checks are skipped.
            • Will update the content->footer.
          6. The spammer class could use instance variables to avoid doing as many db queries and simplify the code
            • I just tried to keep code simple, It will be nice, if we can discuss this and I will update the code accordingly.
          Show
          Rajesh Taneja added a comment - Thanks for the inputs Dan, We have 'search' functionality for bad content, this duplicates the other tool which does this searching and I think we should keep this block simple and leave it out. Difference here is, it search for bad words entered by the current user. The spamcleaner tool (existing tool), searches for all users. This was added, to let admin do search for the user and don't have to go to other place in site. I think we should default to not giving the capability to any archetype as we'll create a custom role allowing access to the block Will remove the default capabilty I'm don't think the way you are working out the user from the page url params will be robust enough (at least I saw problems with it) and warnings about undefined index id on line 102. I couldn't find any other way to get user_id. It will be helpful, if you can suggest the way. It doesn't allow you to delete users who have never logged in If user has not logged in then he cannot enter bad words, hence should not be deleted by spam clearer. So was done intentionally. There are a few places where you set the content->footer to an error message, this should be content->text to be displayed, and also we should return after setting the error message to avoid any potential bugs where access checks are skipped. Will update the content->footer. The spammer class could use instance variables to avoid doing as many db queries and simplify the code I just tried to keep code simple, It will be nice, if we can discuss this and I will update the code accordingly.
          Hide
          Helen Foster added a comment -

          I agree with Dan that we should leave out search functionality, as the spammer will already have been identified before using this spam deletion block.

          Raj, thanks a lot for your work - this feature is going to be soooo useful on moodle.org

          Show
          Helen Foster added a comment - I agree with Dan that we should leave out search functionality, as the spammer will already have been identified before using this spam deletion block. Raj, thanks a lot for your work - this feature is going to be soooo useful on moodle.org
          Hide
          Rajesh Taneja added a comment -

          Thanks Dan and Helen,

          I have updated the branch with following changes:

          1. Removed search functionality.
          2. Removed default capability
          3. Updated $content->footer to $content->text
          4. optimized spammer class

          Only thing left is point 3. Not sure, if there is any better way to get user id. Although, enough checks are in place to make sure unknown id is not deleted.

          @Dan: Can you please review the patch again.

          Show
          Rajesh Taneja added a comment - Thanks Dan and Helen, I have updated the branch with following changes: Removed search functionality. Removed default capability Updated $content->footer to $content->text optimized spammer class Only thing left is point 3. Not sure, if there is any better way to get user id. Although, enough checks are in place to make sure unknown id is not deleted. @Dan: Can you please review the patch again.
          Hide
          Dan Poltawski added a comment -

          Hi Raj,

          Apologies because I am saying some things here I didn't write in my original comment and should have as I didn't look closely enough:

          1/ I think it would be safer to introduce an 'action script' e.g. blocks/spam_deletion/deleteuser.php?id=1 where we present a confirmation for the user to be deleted and then delete. �The approach of using a single_button with confirmation is good, but if JS is disabled the user will be deleted without prompt and more importantly it avoids collision wither other action params which could occur where the spammer block is enabled. Doing it in a separate script makes it clearer where the action is happening.

          2/ confirmdelete should not be PARAM_RAW, it should be PARAM_BOOL
          3/ You left $keywords / $autodetect from the existing code
          4/ class single_button has a add_confirm_action() function which would mean you could simplify that single button part a bit. (Though moving to an 'action script' would probably render that uncessary)
          5/ I don't think it was necessary to implement the html_attibutes method as block_base provides a unique class for you? (Don't worry about changing that)

          Show
          Dan Poltawski added a comment - Hi Raj, Apologies because I am saying some things here I didn't write in my original comment and should have as I didn't look closely enough: 1/ I think it would be safer to introduce an 'action script' e.g. blocks/spam_deletion/deleteuser.php?id=1 where we present a confirmation for the user to be deleted and then delete. �The approach of using a single_button with confirmation is good, but if JS is disabled the user will be deleted without prompt and more importantly it avoids collision wither other action params which could occur where the spammer block is enabled. Doing it in a separate script makes it clearer where the action is happening. 2/ confirmdelete should not be PARAM_RAW, it should be PARAM_BOOL 3/ You left $keywords / $autodetect from the existing code 4/ class single_button has a add_confirm_action() function which would mean you could simplify that single button part a bit. (Though moving to an 'action script' would probably render that uncessary) 5/ I don't think it was necessary to implement the html_attibutes method as block_base provides a unique class for you? (Don't worry about changing that)
          Hide
          Rajesh Taneja added a comment -

          Hello Dan,

          As suggested, I have replaced JS confirmation with a confirmation page, which will do the required action on confirmation.
          Thanks for explaining the corns of doing action on the same page.

          Show
          Rajesh Taneja added a comment - Hello Dan, As suggested, I have replaced JS confirmation with a confirmation page, which will do the required action on confirmation. Thanks for explaining the corns of doing action on the same page.
          Hide
          Dan Poltawski added a comment -

          Hi Raj,

          You are passing the username as a GET parameter (I assume to avoid a database query) but this is not safe - it is better to do the database query on that page so that the confirmation dialogue is accurate (has been generated by the server). Imagine for example I craft a url with: blocks/spam_deletion/confirmdelete.php?id=1&username=joe_spammer - The confirmation will say 'Are you sure you wish to delete 'joe_spammer', yet the userid = 1 which is Martin, so I would be inadvertently deleting martin. [This would also be prevented by other mechanisms, but the point I am making is that its better to display these confirmation dialogues with information generated from the server].

          I don't think you need both a confirm a param and a confirm delete param - if there is no confirm param passed then it is assumed that the user is being prompted to confirm if they wish to delete the user - then once confirmed the delete action takes place.

          Thanks and sorry for all these suggested changes being slowly commented on to you.

          Show
          Dan Poltawski added a comment - Hi Raj, You are passing the username as a GET parameter (I assume to avoid a database query) but this is not safe - it is better to do the database query on that page so that the confirmation dialogue is accurate (has been generated by the server). Imagine for example I craft a url with: blocks/spam_deletion/confirmdelete.php?id=1&username=joe_spammer - The confirmation will say 'Are you sure you wish to delete 'joe_spammer', yet the userid = 1 which is Martin, so I would be inadvertently deleting martin. [This would also be prevented by other mechanisms, but the point I am making is that its better to display these confirmation dialogues with information generated from the server] . I don't think you need both a confirm a param and a confirm delete param - if there is no confirm param passed then it is assumed that the user is being prompted to confirm if they wish to delete the user - then once confirmed the delete action takes place. Thanks and sorry for all these suggested changes being slowly commented on to you.
          Hide
          Rajesh Taneja added a comment -

          grrrr...
          Thanks for pointing that Dan.
          All fixed.

          Show
          Rajesh Taneja added a comment - grrrr... Thanks for pointing that Dan. All fixed.
          Hide
          Dan Poltawski added a comment -

          Hi Raj,

          Thanks a lot for doing all those changes, it looks great. I've got some more feedback as i've done a detailed review again and come up with some more detailed comments:

          • The spammer constructor should probably throw an exception if spammerid is empty since the object isn't useful without it.
          • show_data_count() could be a spammer method which returns the html and then you could also display that information on the confirmation page to provide more info.
          • There are a few places where the whitespace is wrong around your array params, e.g. array('userid'=>$userid) should be array('userid' => $userid)
          • It might be useful to add comment explaining what the id param of confirmdelete.php is (I would even think of naming it $userid to make it more obvious, often you get these id params around moodle and its not always obvious what the id is)
          • On confirmdelete.php you set the context to that of the user, I actually think this should be system context - in practice this doesn't matter for anything I don't think
          • $formcontinue and $formcancel would be better named as $continuebutton and $cancelbutton since they are not forms.
          • A minor style point.. when testing empty values - it is much more readable if you depend on phps boolean truth where it makes sense. This is Moodle style and as long as you do not need strict type checking its perfectly OK and nicer to write this way.

          For example, rather than:

          if (!empty($confirmdelete) ) {
          

          You could do:

          if ($confirmdelete) {
          

          Its simpler if you say it in english "If $confirmdelete then.." Rather than "If not empty $confirmdelete then"

          Another example:

          if (!is_null($spamlib)) {
          

          I would do:

          if ($spamlib) {
          

          cheers,
          dan

          Show
          Dan Poltawski added a comment - Hi Raj, Thanks a lot for doing all those changes, it looks great. I've got some more feedback as i've done a detailed review again and come up with some more detailed comments: The spammer constructor should probably throw an exception if spammerid is empty since the object isn't useful without it. show_data_count() could be a spammer method which returns the html and then you could also display that information on the confirmation page to provide more info. There are a few places where the whitespace is wrong around your array params, e.g. array('userid'=>$userid) should be array('userid' => $userid) It might be useful to add comment explaining what the id param of confirmdelete.php is (I would even think of naming it $userid to make it more obvious, often you get these id params around moodle and its not always obvious what the id is) On confirmdelete.php you set the context to that of the user, I actually think this should be system context - in practice this doesn't matter for anything I don't think $formcontinue and $formcancel would be better named as $continuebutton and $cancelbutton since they are not forms. A minor style point.. when testing empty values - it is much more readable if you depend on phps boolean truth where it makes sense. This is Moodle style and as long as you do not need strict type checking its perfectly OK and nicer to write this way. For example, rather than: if (!empty($confirmdelete) ) { You could do: if ($confirmdelete) { Its simpler if you say it in english "If $confirmdelete then.." Rather than "If not empty $confirmdelete then" Another example: if (!is_null($spamlib)) { I would do: if ($spamlib) { cheers, dan
          Hide
          Rajesh Taneja added a comment -

          All done Dan,

          In addition to your comments, I have added another check for guest and admin accounts. User should not be able to mark admin or guest account as spammer.

          Show
          Rajesh Taneja added a comment - All done Dan, In addition to your comments, I have added another check for guest and admin accounts. User should not be able to mark admin or guest account as spammer.
          Hide
          Martin Dougiamas added a comment -

          I really want to see this on moodle.org! Can you confirm that it's safe to install there?

          Show
          Martin Dougiamas added a comment - I really want to see this on moodle.org! Can you confirm that it's safe to install there?
          Hide
          Ankit Agarwal added a comment -

          Hi guys,
          This is looking good. I only issue I found was :-

          1. data_show_count() should count messages both from message table and message_read table, as we are deleting messages from both these fields
          2. We need to make sure external blog fetching is stopped (doesnt matter for moodle.org I guess since we have blogs disabled)
          3. User can misuse there existing session, if they are suspended, while still logged in.

          Everything else went smoothly during the testing and looks great.
          Thanks

          Show
          Ankit Agarwal added a comment - Hi guys, This is looking good. I only issue I found was :- data_show_count() should count messages both from message table and message_read table, as we are deleting messages from both these fields We need to make sure external blog fetching is stopped (doesnt matter for moodle.org I guess since we have blogs disabled) User can misuse there existing session, if they are suspended, while still logged in. Everything else went smoothly during the testing and looks great. Thanks
          Hide
          Rajesh Taneja added a comment -

          Thanks Ankit,

          I have added message_read in message count and deleting user session as well. Also, added another commit to delete external blog.

          Can you please check this again.

          Show
          Rajesh Taneja added a comment - Thanks Ankit, I have added message_read in message count and deleting user session as well. Also, added another commit to delete external blog. Can you please check this again.
          Hide
          Ankit Agarwal added a comment -

          Thanks Raj,
          Looks good to me.

          cheers

          Show
          Ankit Agarwal added a comment - Thanks Raj, Looks good to me. cheers
          Hide
          Helen Foster added a comment -

          Raj, thanks a lot for your work on this, and thanks Ankit for reviewing it.

          Please could the block be installed on the newly set up http://clone.moodle.org for further testing. (I guess Dan had the rights to do so?)

          Show
          Helen Foster added a comment - Raj, thanks a lot for your work on this, and thanks Ankit for reviewing it. Please could the block be installed on the newly set up http://clone.moodle.org for further testing. (I guess Dan had the rights to do so?)
          Hide
          Dan Poltawski added a comment -

          (Sorry that this was waiting on me Raj)

          Show
          Dan Poltawski added a comment - (Sorry that this was waiting on me Raj)
          Hide
          Rajesh Taneja added a comment -

          NP Dan,

          Can you please take it forward from here.

          Show
          Rajesh Taneja added a comment - NP Dan, Can you please take it forward from here.
          Hide
          Dan Poltawski added a comment -
          1. I've created a moodlehq repository for just the block (https://github.com/moodlehq/block-spam_deletion) - this is the best way to deploy it rather than as a branch off the stable branches
          2. I've installed it on the clone.
          3. But its currently blocked by lack of user profile blocks - MDLSITE-1922
          Show
          Dan Poltawski added a comment - I've created a moodlehq repository for just the block ( https://github.com/moodlehq/block-spam_deletion ) - this is the best way to deploy it rather than as a branch off the stable branches I've installed it on the clone. But its currently blocked by lack of user profile blocks - MDLSITE-1922
          Hide
          Dan Poltawski added a comment -

          You can get to the block if you go to the 'site profile' page, e.g.:
          http://clone.moodle.org/user/profile.php?id=1109345

          Show
          Dan Poltawski added a comment - You can get to the block if you go to the 'site profile' page, e.g.: http://clone.moodle.org/user/profile.php?id=1109345
          Hide
          Helen Foster added a comment -

          Thanks Dan, I had a play at being a spammer on the clone site and then tried to delete the spam. Here's what I found:

          Working fine:

          • If the first access date was more than a month ago, it is not possible to delete spam/suspend the account
          • Comments in the plugins directory and Buzz (database activity) were deleted
          • An unread message was deleted (note to self: still need to test read messages)
          • Spammer's account is suspended and the profile description is replaced by 'Spammer - spam deleted and account blocked Monday 24th September 7:39 PM'
          • block/spam_deletion:spamdelete capability not set for any role, so only admins can see the block (BTW just curious where you added the block Dan, as I can't see it on the site front page?)

          I really liked it that after deleting the spam/suspending the account you were returned to the spammer's profile page. (Normally when suspending an account, you are returned to the list of users admin/user.php and I'm always left wondering "Did I really suspend that account?")

          Not tested:

          • Blog post deletion, as blogs are not enabled on moodle.org

          Minor problems:

          • Incorrect timestamp in inserted text (probably not important at all though)
          • When deleting a spammer who had a profile picture, description, interests and other profile fields, the account was suspended and the description amended, but all other data remained e.g. http://clone.moodle.org/user/profile.php?id=1483338

          Spammers frequently use their profiles for links and interests (tags), so it would be really useful if the spam cleaner could get rid of all this data too.

          Big problems:

          • The deletion process took a long time - more than 30 seconds - so would time out on moodle.org due to cloudflare restrictions
          • In addition to a spammer's forum posts being replaced with the text 'Content removed by moderator at Monday 24th September 7:37 PM', lots more forum posts were similarly blanked e.g. all posts in a thread http://clone.moodle.org/mod/forum/discuss.php?d=164622#p915981, all recent front page news posts http://clone.moodle.org/news/ also titles of forum posts

          Although I wrote in the description of this issue about blanking forum posts and inserting a phrase, on further reflection I think it's perhaps best just to delete the forum posts as people generally don't reply to spam, so orphaned posts would be relatively rare.

          Thanks again Raj, for developing this feature, and Dan and Ankit for reviewing it. Please let me know if any of you have further ideas of what to test for before we decide it's safe to install on moodle.org.

          Show
          Helen Foster added a comment - Thanks Dan, I had a play at being a spammer on the clone site and then tried to delete the spam. Here's what I found: Working fine: If the first access date was more than a month ago, it is not possible to delete spam/suspend the account Comments in the plugins directory and Buzz (database activity) were deleted An unread message was deleted (note to self: still need to test read messages) Spammer's account is suspended and the profile description is replaced by 'Spammer - spam deleted and account blocked Monday 24th September 7:39 PM' block/spam_deletion:spamdelete capability not set for any role, so only admins can see the block (BTW just curious where you added the block Dan, as I can't see it on the site front page?) I really liked it that after deleting the spam/suspending the account you were returned to the spammer's profile page. (Normally when suspending an account, you are returned to the list of users admin/user.php and I'm always left wondering "Did I really suspend that account?") Not tested: Blog post deletion, as blogs are not enabled on moodle.org Minor problems: Incorrect timestamp in inserted text (probably not important at all though) When deleting a spammer who had a profile picture, description, interests and other profile fields, the account was suspended and the description amended, but all other data remained e.g. http://clone.moodle.org/user/profile.php?id=1483338 Spammers frequently use their profiles for links and interests (tags), so it would be really useful if the spam cleaner could get rid of all this data too. Big problems: The deletion process took a long time - more than 30 seconds - so would time out on moodle.org due to cloudflare restrictions In addition to a spammer's forum posts being replaced with the text 'Content removed by moderator at Monday 24th September 7:37 PM', lots more forum posts were similarly blanked e.g. all posts in a thread http://clone.moodle.org/mod/forum/discuss.php?d=164622#p915981 , all recent front page news posts http://clone.moodle.org/news/ also titles of forum posts Although I wrote in the description of this issue about blanking forum posts and inserting a phrase, on further reflection I think it's perhaps best just to delete the forum posts as people generally don't reply to spam, so orphaned posts would be relatively rare. Thanks again Raj, for developing this feature, and Dan and Ankit for reviewing it. Please let me know if any of you have further ideas of what to test for before we decide it's safe to install on moodle.org.
          Hide
          Dan Poltawski added a comment -

          Hi Helen,

          I have spent this morning fixing up the spam deletion block, all the problems you reported should be fixed apart from the time being wrong - this is using the time of the server (which is Perth time atm) there isn't really a good solution to it, since we are just adding a timestamp to the description.

          So, ready to be re-tested!

          thanks,
          Dan

          Show
          Dan Poltawski added a comment - Hi Helen, I have spent this morning fixing up the spam deletion block, all the problems you reported should be fixed apart from the time being wrong - this is using the time of the server (which is Perth time atm) there isn't really a good solution to it, since we are just adding a timestamp to the description. So, ready to be re-tested! thanks, Dan
          Hide
          Helen Foster added a comment -

          Hi Dan,

          Thanks a lot for fixing up the spam deletion block. I've had a lot of fun deleting spam and suspending spammer accounts at the click of a button!

          I re-tested everything mentioned in my previous comment and found things fine, apart from the following:

          • Forum post content was blanked, rather than the posts being deleted. As mentioned previously, I think it's best just to delete the forum posts as people don't reply to spam, otherwise we'll end up with posts such as these http://clone.moodle.org/mod/forum/user.php?id=1534032
          • When an account is suspended, although the profile description is amended, other profile data remains - picture description, My Moodle, Jabber ID, Twitter ID and interests (tags). I think ALL profile fields should be blanked.

          Also

          • I tested whether read messages were deleted and found they were not, but I don't think this really matters.
          • I created a spam deleter role and assigned it as a system role to Sam Test user and found that they could also use the spam deletion block - perfect for our documentation fairy!
          • Is it possible to log a spammer out after suspending their account, as otherwise they can continue depositing spam which the spam deletion block then no longer detects? (There may be a tracker issue for this, as it has been discussed in the forums.)

          Minor stuff:

          • The block could say 'Unread messages' rather than 'Messages' and not say anything about blog posts (since they're not enabled on moodle.org and the functionality has not been tested).
          • Tags count was unreliable, or perhaps it was recording unique tags?

          Thanks again for your work. This block is going to be great!

          Show
          Helen Foster added a comment - Hi Dan, Thanks a lot for fixing up the spam deletion block. I've had a lot of fun deleting spam and suspending spammer accounts at the click of a button! I re-tested everything mentioned in my previous comment and found things fine, apart from the following: Forum post content was blanked, rather than the posts being deleted. As mentioned previously, I think it's best just to delete the forum posts as people don't reply to spam, otherwise we'll end up with posts such as these http://clone.moodle.org/mod/forum/user.php?id=1534032 When an account is suspended, although the profile description is amended, other profile data remains - picture description, My Moodle, Jabber ID, Twitter ID and interests (tags). I think ALL profile fields should be blanked. Also I tested whether read messages were deleted and found they were not, but I don't think this really matters. I created a spam deleter role and assigned it as a system role to Sam Test user and found that they could also use the spam deletion block - perfect for our documentation fairy! Is it possible to log a spammer out after suspending their account, as otherwise they can continue depositing spam which the spam deletion block then no longer detects? (There may be a tracker issue for this, as it has been discussed in the forums.) Minor stuff: The block could say 'Unread messages' rather than 'Messages' and not say anything about blog posts (since they're not enabled on moodle.org and the functionality has not been tested). Tags count was unreliable, or perhaps it was recording unique tags? Thanks again for your work. This block is going to be great!
          Hide
          Mary Cooch added a comment -

          My ears were burning I think this all sounds really helpful and thankyou Dan. Does this mean I get to be a spam fairy?

          Show
          Mary Cooch added a comment - My ears were burning I think this all sounds really helpful and thankyou Dan. Does this mean I get to be a spam fairy?
          Hide
          Helen Foster added a comment -

          Mary, I've just assigned you the role of spam deleter on http://clone.moodle.org if you'd like to check it out. You should be able to go to anybody's profile page and if their account creation date is less than 1 month ago you can delete their stuff and suspend their account.

          Show
          Helen Foster added a comment - Mary, I've just assigned you the role of spam deleter on http://clone.moodle.org if you'd like to check it out. You should be able to go to anybody's profile page and if their account creation date is less than 1 month ago you can delete their stuff and suspend their account.
          Hide
          Helen Foster added a comment -

          Dan, another reason for deleting spam forum posts is that then they disappear from the list http://clone.moodle.org/blocks/spam_deletion/viewvotes.php

          Show
          Helen Foster added a comment - Dan, another reason for deleting spam forum posts is that then they disappear from the list http://clone.moodle.org/blocks/spam_deletion/viewvotes.php
          Hide
          Dan Poltawski added a comment -

          Hi Helen,

          Forum post content was blanked, rather than the posts being deleted. As mentioned previously, I think it's best just to delete the forum posts as people don't reply to spam, otherwise we'll end up with posts such as these http://clone.moodle.org/mod/forum/user.php?id=1534032

          Fixed, sorry I missed this in your original comment.

          When an account is suspended, although the profile description is amended, other profile data remains - picture description, My Moodle, Jabber ID, Twitter ID and interests (tags). I think ALL profile fields should be blanked.

          I had done this, but seemingly not done tags properly, missed custom fields and the picture description. Should be fixed now.

          I tested whether read messages were deleted and found they were not, but I don't think this really matters.

          They should be, could you test again?

          Is it possible to log a spammer out after suspending their account, as otherwise they can continue depositing spam which the spam deletion block then no longer detects? (There may be a tracker issue for this, as it has been discussed in the forums.)

          Yes, i've fixed this.

          The block could say 'Unread messages' rather than 'Messages' and not say anything about blog posts (since they're not enabled on moodle.org and the functionality has not been tested).
          Tags count was unreliable, or perhaps it was recording unique tags?

          Improved the strings for both of those to make it clearer.

          Show
          Dan Poltawski added a comment - Hi Helen, Forum post content was blanked, rather than the posts being deleted. As mentioned previously, I think it's best just to delete the forum posts as people don't reply to spam, otherwise we'll end up with posts such as these http://clone.moodle.org/mod/forum/user.php?id=1534032 Fixed, sorry I missed this in your original comment. When an account is suspended, although the profile description is amended, other profile data remains - picture description, My Moodle, Jabber ID, Twitter ID and interests (tags). I think ALL profile fields should be blanked. I had done this, but seemingly not done tags properly, missed custom fields and the picture description. Should be fixed now. I tested whether read messages were deleted and found they were not, but I don't think this really matters. They should be, could you test again? Is it possible to log a spammer out after suspending their account, as otherwise they can continue depositing spam which the spam deletion block then no longer detects? (There may be a tracker issue for this, as it has been discussed in the forums.) Yes, i've fixed this. The block could say 'Unread messages' rather than 'Messages' and not say anything about blog posts (since they're not enabled on moodle.org and the functionality has not been tested). Tags count was unreliable, or perhaps it was recording unique tags? Improved the strings for both of those to make it clearer.
          Hide
          Helen Foster added a comment -

          Wow, it's really great now, especially the spammer being instantly logged out!

          I tested and found forum posts (both replies and discussion starters), all profile fields and read messages were deleted. I think it's ready to be added to our production site! Does it need adding at the same time as the 'report as spam' feature and should we mention it in the moodle community sites forum first?

          Show
          Helen Foster added a comment - Wow, it's really great now, especially the spammer being instantly logged out! I tested and found forum posts (both replies and discussion starters), all profile fields and read messages were deleted. I think it's ready to be added to our production site! Does it need adding at the same time as the 'report as spam' feature and should we mention it in the moodle community sites forum first?
          Hide
          Dan Poltawski added a comment -

          Hi Helen,

          Yes it would be easiest to deploy the two features together at the same time as i've tied the two features together a bit closely in the block now (they make sense together though).

          However, we don't need to enable the 'report a spam' link at the same time as adding the block (unless you want to). I think it'd be good to post on the forum about it

          Show
          Dan Poltawski added a comment - Hi Helen, Yes it would be easiest to deploy the two features together at the same time as i've tied the two features together a bit closely in the block now (they make sense together though). However, we don't need to enable the 'report a spam' link at the same time as adding the block (unless you want to). I think it'd be good to post on the forum about it
          Hide
          Helen Foster added a comment -

          Thanks Dan, I've posted in the forum https://moodle.org/mod/forum/discuss.php?d=218297 so please feel free to deploy both new features.

          PS Attaching a screen shot of the spam deletion block for interest.

          Show
          Helen Foster added a comment - Thanks Dan, I've posted in the forum https://moodle.org/mod/forum/discuss.php?d=218297 so please feel free to deploy both new features. PS Attaching a screen shot of the spam deletion block for interest.
          Hide
          Dan Poltawski added a comment -

          Done.

          Show
          Dan Poltawski added a comment - Done.
          Hide
          Dan Poltawski added a comment -

          I'm resolving this issue - there is still work to be done in MDLSITE-1620, but I think this issue is resolved.

          Show
          Dan Poltawski added a comment - I'm resolving this issue - there is still work to be done in MDLSITE-1620 , but I think this issue is resolved.
          Hide
          Helen Foster added a comment -

          Just noticed the spam deletion block for https://moodle.org/user/profile.php?id=1536882 reports 178 read messages yet the user's activity log has no record of any messages sent.

          Show
          Helen Foster added a comment - Just noticed the spam deletion block for https://moodle.org/user/profile.php?id=1536882 reports 178 read messages yet the user's activity log has no record of any messages sent.
          Hide
          Dan Poltawski added a comment - - edited

          Hi Helen,

          Just had a quick look, and they are forum post messages from this post:
          https://moodle.org/mod/forum/discuss.php?d=216692&parent=950582

          (One of the results of the way messages are all a bit weird is that they create message records when sending forum posts).

          Show
          Dan Poltawski added a comment - - edited Hi Helen, Just had a quick look, and they are forum post messages from this post: https://moodle.org/mod/forum/discuss.php?d=216692&parent=950582 (One of the results of the way messages are all a bit weird is that they create message records when sending forum posts).
          Hide
          Helen Foster added a comment -

          Hi Dan,

          Thanks for explaining about the read messages count and for cleaning up spam on moodle.org this weekend.

          I've just tried clicking the delete spammer button and got an error message 'Can not find data record in database table forum.' After deleting the spam forum post I and tried clicking the delete spam button again and this time it worked fine.

          Show
          Helen Foster added a comment - Hi Dan, Thanks for explaining about the read messages count and for cleaning up spam on moodle.org this weekend. I've just tried clicking the delete spammer button and got an error message 'Can not find data record in database table forum.' After deleting the spam forum post I and tried clicking the delete spam button again and this time it worked fine.
          Hide
          Dan Poltawski added a comment -

          Hi Helen,

          I've just tried clicking the delete spammer button and got an error message 'Can not find data record in database table forum.' After deleting the spam forum post I and tried clicking the delete spam button again and this time it worked fine.

          I've found the bug causing that problem and deployed a fix to it.

          Show
          Dan Poltawski added a comment - Hi Helen, I've just tried clicking the delete spammer button and got an error message 'Can not find data record in database table forum.' After deleting the spam forum post I and tried clicking the delete spam button again and this time it worked fine. I've found the bug causing that problem and deployed a fix to it.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development