Last modified: 2009-06-04 17:06:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20042, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18042 - Spam not being deleted from OTRS system
Spam not being deleted from OTRS system
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
OTRS (Other open bugs)
unspecified
All All
: Normal trivial (vote)
: ---
Assigned To: Fred Vassard
https://ticket.wikimedia.org/otrs/ind...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-18 21:57 UTC by Ryan (Rjd0060)
Modified: 2009-06-04 17:06 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ryan (Rjd0060) 2009-03-18 21:57:18 UTC
The junk queue is continuing to build up (currently holding 198,382 messages).
Comment 1 Mike.lifeguard 2009-03-21 21:27:33 UTC
I'm told this also means the spam filters aren't getting trained as that's done at the same time as the deleting. Shouldn't it be possible to train the filter as messages come in even they're not being deleted?
Comment 2 Para 2009-04-03 12:08:43 UTC
If storage is not a problem and the growing queue doesn't make OTRS slower, I don't think there's a need to delete them (unless there's some training silliness). False positives do happen, and in case of queries mentioning previous messages or other uncertainty about reception[1], it's useful to be able to see if any have been junked.

[1] http://lists.wikimedia.org/pipermail/foundation-l/2007-November/034529.html
Comment 3 Ryan (Rjd0060) 2009-04-04 00:11:58 UTC
(In reply to comment #2)
> If storage is not a problem and the growing queue doesn't make OTRS slower, I
> don't think there's a need to delete them (unless there's some training
> silliness). False positives do happen, and in case of queries mentioning
> previous messages or other uncertainty about reception[1], it's useful to be
> able to see if any have been junked.
> 
> [1] http://lists.wikimedia.org/pipermail/foundation-l/2007-November/034529.html
> 

We don't need all junk tickets forever.  There is just no reason to store it.  People regularly look in the junk queue to make sure nothing is there that shouldn't be however, when there are hundreds of thousands of messages there (currently there are 280,135 messages), people will not even bother to look.  So really, it is more helpful to keep it reduced in size and continue to check regularly for misplaced tickets, as we were doing before.
Comment 4 Ryan (Rjd0060) 2009-05-01 14:29:32 UTC
Still growing and currently at 408,676.  I mention it again because it seems to have negative effects on the speed of the system.  Over the last month or so, all page loads on OTRS are taking longer.  As the number of junk tickets goes up, the load time goes up as well.  Is this a coincidence or not?  If not, I'll open a separate bug.  If the amount of messages in the junk queue is playing a role, I'd hope that we can get to this soon.
Comment 5 Fred Vassard 2009-06-04 17:06:11 UTC
The DELETE option has been re-enabled while the Junk queue is getting purged. 
Cary is in the process of purging the queue itself. Hopefully this will improve the situation.


Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links