We have a ton of tickets in a queue from another instance of RT in our
instance of RTIR (RT4/RTIR3). I’ve been able to modify the Lifecycles so
that I can move tickets to the “Incident Reports” queue now (thanks Kevin
for your advice with that). I’d like tickets moved to that queue treated
like new Incident Report tickets in RTIR but hitting some snags.
The condition for On Queue Change itself isn’t a problem since that part is
pretty straight forward (either using the built in “On Queue Change” or a
user defined condition).
The problem is that the provided “SetIPFromContent” (which presumably is
the RTIR_FindIP.pm) doesn’t work when using “On Queue Change” as a
condition. This is probably because the content of the transaction is that
of a queue change and does not contain any correspondence-style content and
it’s not something you can run against the action. What I need however is
something that will run against each part (attachment?) of this already
existing ticket.
I attempted to do this using a simple loop over each of the transactions
but it’s kind of hacked up and the loop doesn’t even seem to run once (as
if there are no transactions with attachments).
*As a test I made the following scrip but I’d like something more native
to RTIR_FindIP.pm if possible. *
NAME: OnQueueChange Find IPs
Condition: On Queue Change
Action: User Defined
Template: Blank
Stage: Transaction Create
Condition and Preperation: “return 1;”
Cleanup Code:
use Regexp::Common qw(net);
use NetAddr::IP;
use Data::Validate::IP qw(is_ipv4 is_ipv6);
my $attachments = $self->TransactionObj->Attachments;
my @ourips = RT->Config->Get(‘OurIPs’);
my $CF_Obj = RT::CustomField->new($RT::SystemUser);
$CF_Obj->LoadByName( Name => “URL” ); # *** See note
my @inserted;
Loop over each attachment in the TransactionObj and trap IPv4 and IPv6
addresses.
Insert those into the “IP” CustomField.
*** Note - For testing I’ve changed it to URL and I’m trying to simply
write \
*** - the word “TEST” instead.
*** - URL is a valid CF and this AddValueForObject works outside the
\
*** - while loop below.
while (my $message = $attachments->Next) {
next unless $message->ContentType =~
m!^(text/html|text/plain|message|text$)!i;
my $content = $message->Content;
my @lines = split(/\n/,$content);
foreach my $line (@lines) {
if ($line =~ /($RE{net}{IPv4}|$RE{net}{IPv6})/g) {
$CF_Obj->AddValueForObject( Object => $self->TicketObj, Content =>
“TEST” )
unless grep($1,@inserted); # *** See note
push(@inserted,$ipaddr);
}
}
}
I’ve been banging my head against this for a few hours now and can’t get
the loop to work it seems let alone find a way to do this more natively
with RTIR_FindIP.pm.
Hello RT Users,
We have a ton of tickets in a queue from another instance of RT in our instance of RTIR
(RT4/RTIR3). I’ve been able to modify the Lifecycles so that I can move tickets to the
“Incident Reports” queue now (thanks Kevin for your advice with that). I’d like tickets moved
to that queue treated like new Incident Report tickets in RTIR but hitting some snags.
The condition for On Queue Change itself isn’t a problem since that part is pretty straight
forward (either using the built in “On Queue Change” or a user defined condition).
The problem is that the provided “SetIPFromContent” (which presumably is the RTIR_FindIP.pm)
doesn’t work when using “On Queue Change” as a condition. This is probably because the content
of the transaction is that of a queue change and does not contain any correspondence-style
content and it’s not something you can run against the action. What I need however is
something that will run against each part (attachment?) of this already existing ticket.
I attempted to do this using a simple loop over each of the transactions but it’s kind of
hacked up and the loop doesn’t even seem to run once (as if there are no transactions with
attachments).
rt-crontool has the --transaction all argument for exactly this usage.
Move your tickets, run rt-crontool (search or condition to find the
tickets) --action FindIP --transaction all
RT will scrap the complete history of those tickets running them
through IP extractor (so all Create/Comment/Correspond would be
checked).
rt-crontool has the --transaction all argument for exactly this usage.
Move your tickets, run rt-crontool (search or condition to find the
tickets) --action FindIP --transaction all
RT will scrap the complete history of those tickets running them
through IP extractor (so all Create/Comment/Correspond would be
checked).
Well I attempted it and while it cycled through the tickets and their
transactions it didn’t process them as expected with the action provided.
I had to use RT::Action::RTIR_FindIP as the action since just specifying
FindIP didn’t work (failed to load module FindIP). I don’t know if I used
the wrong action or if something else is awry here but the tickets
themselves did not change even though there are IP addresses to be found in
all of them except one.
Here’s what I ran and a small sample of the output:
–search-arg “Incident Reports” --condition RT::Condition::Overdue --action
RT::Action::RTIR_FindIP --transaction all --verbose
1265908:
Using transaction #3422057…
Using transaction #3422063…
Using transaction #3423198…
Using transaction #3423201…
Using transaction #3423203…
Using transaction #3423857…
Using transaction #3423858…
Using transaction #3424782…
Using transaction #14047288…
Using transaction #67295392…
Using transaction #67295393…
Using transaction #67295394…
1266189:
Using transaction #3425710…
Using transaction #3425718…
Using transaction #3425742…
Using transaction #3425743…
Using transaction #3425847…
Using transaction #14047295…
Using transaction #67295419…
Using transaction #67295420…
Using transaction #67295421…
rt-crontool has the --transaction all argument for exactly this usage.
Move your tickets, run rt-crontool (search or condition to find the
tickets) --action FindIP --transaction all
RT will scrap the complete history of those tickets running them
through IP extractor (so all Create/Comment/Correspond would be
checked).
Well I attempted it and while it cycled through the tickets and their
transactions it didn’t process them as expected with the action provided.
I had to use RT::Action::RTIR_FindIP as the action since just specifying
FindIP didn’t work (failed to load module FindIP). I don’t know if I used
the wrong action or if something else is awry here but the tickets
themselves did not change even though there are IP addresses to be found in
all of them except one.
Here’s what I ran and a small sample of the output: