[rt-users] queue change still triggers old queue's scrips

[Sebastian Juenemann]

Hi List,

ok, I came finally up with the solution myself and just want to share this.

The problem was the scrip execution order together with the wrong or misleading solution provided here:

https://rt-wiki.bestpractical.com/wiki/SpamFiltering (1b)

The queue change needs to be done already in the action preparation code (and not in the commit code). This is because 
all other scrips which meet the transaction condition (in this case "Crate") will be executed no matter what if their 
preparation code returns a true. For all those auto-notifications on new tickets this is always the case. So when their 
preparation code is executed the queue must have been changed already, so that their assemblage of all email recipients 
are based on the new SPAM queue (which has no watchers). Even if so, overwriting all global templates in the SPAM queue 
with empty local ones would result in empty emails (and this is based again on the queue, so the queue needs to be 
changed already).

Here is my solution for everyone interested. The commit action is in essence this one: 
https://rt-wiki.bestpractical.com/wiki/SpamScore2Priority but I found it more convenient to do this all in one scrip.

On Create Check spamassassin score and move to SPAM queue when exceeding threshold

custom condition:

return 0 unless $self->TransactionObj->Type eq "Create";
return 0 if $self->TicketObj->QueueObj->Name eq "SPAM";
return 1;

Custom action preparation code:

  # Match ***** level spam. You might want to set this higher/lower if needed
  my $match = '\*\*\*\*\*';
  my $inMessage = $self->TransactionObj->Attachments->First;
  return 0 if (!$inMessage);  # if no message attachment - assume web UI
  return 0 if (!$inMessage->GetHeader('Received'));  # exit if not email message

  my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
  my $spam = ( $spamLevel !~ /$match/i ) ? 0 : 1;

  my $stat = undef;
  if ($spam) {

    # set owner to nobody
    $self->TicketObj->SetOwner( $RT::Nobody->id );

    # In any case remove any watchers to this ticket, just to be sure
    $self->TicketObj->DeleteWatcher( Type => 'Requestor');
    $self->TicketObj->DeleteWatcher( Type => 'Cc');
    $self->TicketObj->DeleteWatcher( Type => 'AdminCC');
    $self->TicketObj->DeleteWatcher( Type => 'Owner');

    my $newqueue = 'SPAM';

    my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
    $stat = $status ? 1 : 0;

    # set ticket to stalled
    $self->TicketObj->SetStatus( "stalled" );
    $self->TransactionObj->SetType("Create");
  }

  return $stat;

Custom action commit code:

#convert the spam score to negative priority
my $score = $self->TransactionObj->Attachments->First->GetHeader('X-Spam-Score');
unless( $score ){
    my $t = $self->TransactionObj->Attachments->First->GetHeader('X-Spam-Status');
    $t =~ /score=(-?\d+(|:.\d+)?)/ && ($score = $1);
}
$self->TicketObj->SetPriority( -int($score) ) if $score;

return 1;

- Sebastian


On 01/13/2017 03:34 PM, Sebastian Juenemann wrote:
> Hi List,
>
> I hope you can help me on this topic since the online documentation won't me bring any further.
>
> So in order to deal with our spam I've done the following:
>
> 1) added a new spam queue
> 2) created a new global scrip (according to the spamfilter 1b solution provided here:
> https://rt-wiki.bestpractical.com/wiki/SpamFiltering)
> 3) set the order of the scrips so that this new scrip is executed first
> 4) overwritten all global templates with empty ones in the spam queue (so that in any case a global scrip still triggers
> here now mail is actually send out)
>
> What happens is that the spam scrip successfully re-queues all spam to the spam queue _but_ after that still an email is
> sent to all of our AdminCC's according to a global scrip which enforces this: The scrip order is the following
>
>      24     0 On Creat Check Spamassasin score and move to SPAM queue when exceeding threshold     User Defined User
> Defined Blank     Enabled
> ...
>      8     On Create Notify Owner and AdminCcs     On Create     Notify Owner and AdminCcs     Transaction in HTML Enabled
>     9     On Create Notify Ccs     On Create     Notify Ccs     Correspondence in HTML     Enabled
>     10     On Create Notify Other Recipients     On Create     Notify Other Recipients     Correspondence in HTML Enabled
>
> ...
>
> I don't quite understand this. I thought that the scrips are executed in the order I define. But it seems like all
> scrips that meet the condition on the Transaction type (in this case "Create") are marked for execution and then
> processed in the given order. This would mean that there are only two ways I can prevent further scrips from
> triggering/doing their job after the detection of spam by a) either modifying all global scrips or b) achieve that after
> the queue change the ticket/transaction itself if invalid somehow (so that consecutive scrips won't be able to do
> anything meaningful anymore).
>
> As I don't want to alter our global scrips (they are global and and easy for some reason) I would like to know how I can
> achieve solution b? It should be able that after the queue change to the SPAM queue any "on create" triggering scrip
> "fails" - but I don't know how.
>
> Many thanks in advance,
>
> - Sebastian


-- 
Sebastian Jünemann
CeBiTec - Center for Biotechnology
Bielefeld University, D-33594 Bielefeld, Germany
Office: V6-147 -- Phone: +49-(0)521-106-4827	
eMail: jueneman at CeBiTec.Uni-Bielefeld.de