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

2017-01-25 Thread 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 

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

2017-01-13 Thread Sebastian Juenemann

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


Re: [rt-users] scrip condition on transaction custom field

2016-02-17 Thread Sebastian Juenemann

Hi everyone,

OK - meanwhile i got this issue solved but still have some questions, 
especially about some strange behavior of RT.


The following scenario: I'm resolving a ticket via GUI and setting the 
custom field for this transaction ("FeedbackOnResolve") to "yes". If I 
also leaving a comment (i.e. writing something in the text field) this 
triggers two transactions: first the comment transaction, then the 
status change transaction 9from open to resolved).


1) it should be better commented that $self->TransactionObj in a batch 
scrip (condition) returns the _first_ _triggering/applicable_ 
transaction object. This can get really awkward in the scrip if you 
write several tests and when not everything fits, the the first 
_applicable_ transaction might not be really the _first_ transaction in 
this cascade. So there is limited reliance on this behavior.


2) transaction custom fields (CFS) are somehow attached to 'comment' (or 
correspondence) transactions only. So in order get TCFs working you are 
forced to fill out the text form in order to actually trigger a 
comment/correspondence transaction to which this CF will be attached. 
This also means that if you're searching for specific values on TCFs you 
need to parse through the appropriate transaction type, i.e. 
comment/correspondence.


Or is there another way to trigger TCFs in scrips for other transaction 
types as e.g. 'Status' or 'Set'?  And why do TCFs are not handled like 
ticket CFs (i.e. triggering an own 'CustomField' typed transaction)?


The whole documentary is more or less completely written for ticket CFs, 
which are handled totally different.


3) if anyone is interested the solution for my problem is the following:

my $resolved = 0;
my $feedback = 0;
my $trans_list = $self->TicketObj->TransactionBatch;
my $trans;
foreach my $trans (@$trans_list) {
my $type = $trans->Type;
my $field = $trans->Field;
if ($type eq "Status" || ( $type eq "Set" && $field eq "Status")){
   $resolved = 1 if ($trans->NewValue eq "resolved");
} elsif ($type eq "Comment") {
my $cfvs = $trans->CustomFieldValues("FeedbackOnResolve");
if (my $value = $cfvs->Next()) {
$feedback = 1 if ($value->Content() eq "yes");
    }
}
}
return 0 unless $resolved && $feedback;
return 1;

- Sebastian


On 02/17/2016 08:36 AM, Sebastian Juenemann wrote:

Hi everyone,

I have an issue which i can't get resolved without further help by
anyone more experienced RT user/admin.

I want to have a special trigger which can be activated during the
resolving stage on a ticket in order to decide whether an appropriate
message will be sent to the ticket requester or not. Feedback mails to
requester are generally deactivated. The idea is that RT users then can
resolve tickets as normal but if they want that a feedback mail shall be
send they can set the transaction CF to 'yes' and do so explicitly.

For this, I've crated a transaction custom field 'feedback', enabled it
for my queue, with selectable values 'yes' and 'no'. I've then created a
batch scrip (from what I've learned it must be batch if transaction CFs
shall be parsed) which checks for two conditions: 1) ticket was resolved
and 2) transaction CF 'feedback' is set to 'yes'. The first part works
perfectly fine, but i don't get the second part working. I've tried
dozens of different ways two access transactions CFs, but it just wont
work.


So here are some methods which i tried unsuccessfully so far:

1)
return 0 unless $self->TicketObj->FirstCustomFieldValue('feedback') eq
'yes'; # only on ticket CFs?
2)
my $cfs=$txn->CustomFieldValues;
my $cf = $cfs->LimitToCustomField('feedback');
my $response = $cf->Next;
return 0 unless $response->Content eq 'yes';
3)
my $cfvs=$txn->CustomFieldValues;
my $feedback = 0;
while (my $cfv = $cfvs->Next)
{
  my $cfObj = $cfv->CustomFieldObj;
  my $cf_name = $cfObj->Name;
  my $cfv_name = $cfv->Name;
  if ($cf_name eq 'feedback' && $cfv_name eq 'yes') {
 $feedback = 1;
  }
}
return 0 if $feedback == 0;

So my question is: how do i access the transaction CF of my last
transaction (i.e. a resolve transaction = comment + status change to
resolve) in a scrip condition?

I found the documentation on this specific topic (transaction CFs, not
tiecket CFs) quite incomplete and hope some of you will be able to help me.

Many thank sin 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: juene...@cebitec.uni-bielefeld.de
-
RT 4.4 and RTIR Training Sessions 
(http://bestpractical.com/services/training.html)
* Hamburg Germany - March 14 & 15, 2016
* Washington DC - May 23 & 24, 2016

[rt-users] scrip condition on transaction custom field

2016-02-16 Thread Sebastian Juenemann

Hi everyone,

I have an issue which i can't get resolved without further help by 
anyone more experienced RT user/admin.


I want to have a special trigger which can be activated during the 
resolving stage on a ticket in order to decide whether an appropriate 
message will be sent to the ticket requester or not. Feedback mails to 
requester are generally deactivated. The idea is that RT users then can 
resolve tickets as normal but if they want that a feedback mail shall be 
send they can set the transaction CF to 'yes' and do so explicitly.


For this, I've crated a transaction custom field 'feedback', enabled it 
for my queue, with selectable values 'yes' and 'no'. I've then created a 
batch scrip (from what I've learned it must be batch if transaction CFs 
shall be parsed) which checks for two conditions: 1) ticket was resolved 
and 2) transaction CF 'feedback' is set to 'yes'. The first part works 
perfectly fine, but i don't get the second part working. I've tried 
dozens of different ways two access transactions CFs, but it just wont 
work.



So here are some methods which i tried unsuccessfully so far:

1)
return 0 unless $self->TicketObj->FirstCustomFieldValue('feedback') eq 
'yes'; # only on ticket CFs?

2)
my $cfs=$txn->CustomFieldValues;
my $cf = $cfs->LimitToCustomField('feedback');
my $response = $cf->Next;
return 0 unless $response->Content eq 'yes';
3)
my $cfvs=$txn->CustomFieldValues;
my $feedback = 0;
while (my $cfv = $cfvs->Next)
{
 my $cfObj = $cfv->CustomFieldObj;
 my $cf_name = $cfObj->Name;
 my $cfv_name = $cfv->Name;
 if ($cf_name eq 'feedback' && $cfv_name eq 'yes') {
$feedback = 1;
 }
}
return 0 if $feedback == 0;

So my question is: how do i access the transaction CF of my last 
transaction (i.e. a resolve transaction = comment + status change to 
resolve) in a scrip condition?


I found the documentation on this specific topic (transaction CFs, not 
tiecket CFs) quite incomplete and hope some of you will be able to help me.


Many thank sin 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: juene...@cebitec.uni-bielefeld.de
-
RT 4.4 and RTIR Training Sessions 
(http://bestpractical.com/services/training.html)
* Hamburg Germany - March 14 & 15, 2016
* Washington DC - May 23 & 24, 2016