Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#1554 closed new feature (fixed)

spam report not working

Reported by: globetrotter_tt Owned by: coroa
Priority: blocker Milestone: 0.5.5 - bugfixing
Component: BW Admin Keywords: spam report
Cc: jeanyves, coroa@…

Description

The "mark as spam" button in bewelcome.org/messages does not work. The safety team don't get any notification when a user marks a message as spam.

Change History (20)

comment:1 Changed 7 years ago by coroa

  • Cc coroa@… added
  • Milestone changed from unassigned to 0.5.5 - bugfixing
  • Owner set to coroa
  • Status changed from new to accepted

i'll look into it

comment:2 Changed 7 years ago by planetcruiser

coroa: any news? milestone is due in 7 days ;)

comment:3 Changed 7 years ago by coroa

  • Type changed from bug to new feature

the functionality was never available in the messages app. it stopped working when we switched messaging from /bw/mymessages.php to the messages app. the necessary - now unused - data structures are still in the db (marking spam via /bw/mymessages.php is picked up by /bw/admin/adminchecker.php).

thus we have to decide now what to do:

  1. port the way spam is marked by mymessages to the app
  1. write a new adminchecker app which allows to administrate the marked spam
  1. install some other rules, automatic message limits/blocks after a specific number of mails marked as spam

i didn't code anything so far, and unfortunately don't have much time before next weekend.

comment:4 Changed 7 years ago by planetcruiser

wow, sounds like a chunk of work. considering that we are in maintenance mode with rox, shall we simplify like this?

  1. user marks as spam
  2. feedback mail is sent to abuse volunteer
  3. abuse volunteer manually takes action against spammers (don't know how this is dealt with at the moment, disabling account?)

then again, i don't know how many spam messages per day we are talking about. if it is 1 or 2 this procedure would work, if it is 10 or 20 it won't work

in bw-drupal we then can do it properly, it's likely extensions for spam marking exist there

comment:5 follow-up: Changed 7 years ago by globetrotter_tt

What would be the fastest and easiest way? First, i would be interested how many messages were marked as spam. Would it be much work to activate the counter again?

comment:6 in reply to: ↑ 5 Changed 7 years ago by planetcruiser

Replying to globetrotter_tt:

What would be the fastest and easiest way?

i think an email to feedback is the quickest solution. however, it's not the best of course. this depends on the time that coroa wants to invest in this

First, i would be interested how many messages were marked as spam. Would it be much work to activate the counter again?

from what i understand it needs to be reimplemented for PT, so it's probably a bit of work. but emails to feedback could function as an easy and quick way to find out how much the spam button is used. combined with a filter in the gmail feedback account it should work fine for now

comment:7 follow-up: Changed 7 years ago by coroa

actually after looking through the code for a while, i am tempted to say, that probably all we would have to do is adjust the SpamInfo? column of the message to SpamSayMember? for it to show up in the bw/admin/adminchecker tool. if that assumption turns out to be correct, we would have to add a new function to the messages model (with about a line of code) and call it from the controller to have a somewhat working no 1. only newly marked spam is picked up by that way.

i should be able to try this on wednesday.

number of spam messages would be good as well, but the code really just counts where SpamSayMember? is set. And the current code, doesn't touch this. It just moves the message by setting the InFolder? column to 'Spam'. Something like SELECT COUNT(*) FROM members WHERE InFolder?='Spam' would count all of these. but i don't know if i'd also be picking up something else, f.ex. deleted stuff, every mail two times?, so this would only give an upper bound.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 7 years ago by planetcruiser

Replying to coroa:

i should be able to try this on wednesday.

any luck? :)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 7 years ago by coroa

Replying to planetcruiser:

any luck? :)

as a matter of fact, i don't know, for sure. i just now pushed commit af922c2, which should make the "(un)?mark as spam" buttons of the messages app behave as they used to in mymessages.php.

messages newly marked as spam show up in adminchecker.php, but i'm not sure if adminchecker.php is working consistently, as i don't see how you would use it normally. Please someone more familiar with the tool do a test on his local machine first. there is new db-code in this commit, probably harmless, but still db.

comment:10 in reply to: ↑ 9 ; follow-up: Changed 7 years ago by planetcruiser

Replying to coroa:

messages newly marked as spam show up in adminchecker.php, but i'm not sure if adminchecker.php is working consistently, as i don't see how you would use it normally. Please someone more familiar with the tool do a test on his local machine first.

@globetrotter_tt or @jeanyves: do you know how adminchecker works?

there is new db-code in this commit, probably harmless, but still db.

does the database need to be altered or will this work with the current live db?

comment:11 in reply to: ↑ 10 Changed 7 years ago by coroa

does the database need to be altered or will this work with the current live db?

all it does is updating the column SpamInfo? which was used by the old bw stuff, which should still be there, as adminchecker.php would throw errors otherwise.

comment:12 Changed 7 years ago by coroa

sorry. i guess, this can be understood ambigously. So: no, db does not need to be altered.

comment:13 Changed 7 years ago by planetcruiser

got it. will check it locally first and then deploy to alpha later today

comment:14 Changed 7 years ago by planetcruiser

ok, tested your patch locally and it does the following:

  1. user marks message as spam
  2. message moves to Spam folder of user
  3. message shows up in AdminChecker's Spam Reported sub page (/bw/admin/adminchecker.php?action=viewSpamSayMember)

so, at least reported spam will be noticed now, if someone keeps an eye on the Spam Reported queue. as far as i can see no notifications are sent to anyone.

however, marked spam can't be processed, because both check boxes in the Actions column (Mark Spam, I have processed it) have no effect. what shall we do about this? @globetrotter_tt? shall we fix it, or is this not the right place to process spam?

just wondering, how was spam dealt with in the last year or so?

comment:15 Changed 7 years ago by globetrotter_tt

Well, if you can fix it, then fix it;-) I also noticed that the counter for "Adminspam" is always the same as for "Admingroups".

Notification are not that important. If should be enough if the counter works properly. I think only JY can explain how this tool is suposed to work.

comment:16 Changed 7 years ago by coroa

  • follow_up changed from none to release

ok for some reason it even works better on alpha:

  • globetrotter sent me mails, which i marked as spam
  • they showed up in the AdminSpam? tool
  • processing one removed it from the queue, but it was still accessible by the small "view all from matthias button" under one of the messages
  • i removed the spam mark
  • they no longer were shown in the report

so at least for this test everything worked as hoped.

the incorrect counter globetrotter mentioned is fixed by my commit 122238d.

Last edited 7 years ago by coroa (previous) (diff)

comment:17 follow-up: Changed 7 years ago by planetcruiser

this is deployed to alpha now, you may test again. do you have an admin account for the live db? i don't actually.. ;)

comment:18 in reply to: ↑ 17 Changed 7 years ago by coroa

Replying to planetcruiser:

do you have an admin account for the live db? i don't actually.. ;)

was promoted to have the adminchecker right today. unfortunately that's not good enough for the counters as it only shows up when you have adminchecker as well as admingroup rights.

@globetrotter: can you confirm, that the counter is fine now?

comment:19 Changed 7 years ago by globetrotter_tt

  • Resolution set to fixed
  • Status changed from accepted to closed

yes, the counter looks good to me now.

comment:20 Changed 7 years ago by planetcruiser

Note: See TracTickets for help on using tickets.