Still tryin' to merge tix with matching CFs

Mr. Evans first posted about this 11/08. In archives, i see no
replies to the thread. I haven’t heard anything either, and can’t
find anything but Greg’s original post on the web. If this is a taboo
subject or something, please let me know, but i’d really like to be
able to do this :).

Thanks,
Rob---------- Forwarded message ----------
Mornin’,

I found a post from a ways back asking how to do this, with a
nonfunctional scrip code. The OP wants to do what i want to do:

“What I am trying to do now, is on each ticket submission, Extract
that [Custom] field
and then check to see if there is another ticket that has that same number
in the custom field and if they match, merge the tickets.”

My first question is, assuming a reasonably tuned MySQL suitable to
its (fast) hardware: how horrible would this be in an ever-growing DB?
It must search the DB for every last ticket and compare the two CFs,
yes?

The posted code was:
my $TicketsObj = RT::Tickets->new($RT::SystemUser);
$TicketsObj->LimitQueue(VALUE => ‘AfterHoursSupport’);
$TicketsObj->LimitCustomField(CUSTOMFIELD => ‘AfterHoursTicketNumber’,
OPERATOR => ‘=’, VALUE => $AHTixNum);

if ($TicketsObj->Count == 0) { return 1; }
my $id = undef;
while (my $ticket = $TicketsObj->Next) {
next if $self->TicketObj->Id == $ticket->Id;
$id = $ticket->Id;
last;
}

$id || return 1;

$RT::Logger->debug(“Merging ticket " . $self->TicketObj->Id . " into $id
because of OA number match.”);
$self->TicketObj->MergeInto($id);

1;

The OP did not specify exactly which chunks went where, but that he’d
tried various combinations of condition and prep.
My first thought was that this was incorrect; the condition is
OnCreate and no code need go in that block. Prep should be the field
search and compare, and cleanup the ticket merge itself, yes?

(the above is the OP’s exact code and doesn’t reflect my own setup).

/chown -R us:us /yourbase

/chown -R us:us /yourbase

I have this working in my RT 3.8.2 installation. It isn’t a very busy system and I have yet to notice any performance issues. We only get about 50 tickets per day and it has less than 5000 tickets in the system.

First, you need to setup and use the RT Extension to extract custom fields. RT-Extension-ExtractCustomFieldValues-1.8 - RT Extension-ExtractCustomFieldValues Extension - metacpan.org (There is a newer version 2.0 out which I have not used yet)

Make sure this scrip runs before the merge scrip. Otherwise, the custom fields won’t be populated to match on. I did this by naming the scrip “1Add UniqueID Custom Field”.

Once you are sure the Custom Field extraction is working, The following scrip should get you started on being able to match and merge on that field. The Custom Field name I match on is UniqueID. I omit the check for the queue which is in the previous scrip example you posted.

Description: “2Merge on UniqueID match” (the 2 at the beginning has it run just after the CF extraction)
Condition: OnCreate
Action: User Defined
Template: Global template: Blank
Stage: TransactionCreate

Custom condition:

Custom action preparation code:
1;

Custom action cleanup code:

my $uniqueid = undef;
$uniqueid = $self->TicketObj->FirstCustomFieldValue(‘UniqueID’);
$RT::Logger->debug(“My Uniqueid: $uniqueid for search.”);

my $TicketsObj = RT::Tickets->new($RT::SystemUser);
$TicketsObj->LimitCustomField(CUSTOMFIELD => ‘UniqueID’, OPERATOR => ‘=’, VALUE => $uniqueid);

if ($TicketsObj->Count == 0) { return 1; }
my $id = undef;
while (my $ticket = $TicketsObj->Next) {
next if $self->TicketObj->Id == $ticket->Id;
$id = $ticket->Id;
$RT::Logger->debug(“Merging ticket " . $self->TicketObj->Id . " into $id because of UniqueID number match.”);
$self->TicketObj->MergeInto($id);
}

$id || return 1;

1;

I have this working in my RT 3.8.2 installation. It isn’t a very busy system and I have yet to notice any performance issues. We only get about 50 tickets per day and it has less than 5000 tickets in the system.

First, you need to setup and use the RT Extension to extract custom fields. RT-Extension-ExtractCustomFieldValues-1.8 - RT Extension-ExtractCustomFieldValues Extension - metacpan.org (There is a newer version 2.0 out which I have not used yet)

I’m running 2.0 of ECFV with my 3.8.2 - works perfectly, except i
don’t know how to tell it to stop looking after first match.

Custom action preparation code:
1;

Interesting - why this, instead of leaving it blank?

my $TicketsObj = RT::Tickets->new($RT::SystemUser);

I have no idea what this means. That is, i imply it’s gathering
itself to cycle through all existing tickets, but i’m not sure what
new(system user) has to do with anything.

Is this sort of basic info covered in the O’Reilly book? I’m having a
hard time finding a comprehensive list of the various $meanings and
$parts.

My only remaining issue with this function now is that, as mentioned,
the last match with ECVF always wins - i am searching the body for my
CFs, and multiple matches replace previous. I’m not sure how to
constrain a given CF to the first match found, as that’s always the
one i want, and later mentions are always historical in context (“This
value is now foo. Value previous to this was blah,” etc., and i end
up with blah in my CF instead of foo).

Thanks Jeremy, this was driving me nuts. I do not understand enough
about to role of prep vs cleanup to have known i needed a return in
there - was leaving blank. Was also splitting match code and merge
code into prep and cleanup respectively. Neither worked…

Rob

/chown -R us:us /yourbase

I have this working in my RT 3.8.2 installation. It isn’t a very busy system and I have yet to notice any performance issues. We only get about 50 tickets per day and it has less than 5000 tickets in the system.

This has been working. Incoming tickets are scanned for CFs, then
merged when the CF i’m looking for matches. Now here’s a funny
story…

I can’t create any child, or refers-to, or any other sort of new
ticket linked to this one. It has the same CF value, and is being
Created, so… it gets instantly merged into the original ticket…

The only workaround i can think of is to restrict the search and merge
to a queue, and create linked tickets outside that queue, but that
isn’t very satisfying and means explaining to everyone why they can
never have two linked tickets in the same queue. Anyone have a better
idea?

/chown -R us:us /yourbase

Hi Rob;

What happens if you create the ticket first, then update /modify it
adding the CF and link relationship after …
Its more clicks for the users but may work for you …

In a way I think there is some contradictions on what you doing, you
want all tickets with the same CF to merge , but at the same time you
want some not to

Regards;
Roy

Rob Munsch wrote:

I have this working in my RT 3.8.2 installation. It isn’t a very busy system and I have yet to notice any performance issues. We only get about 50 tickets per day and it has less than 5000 tickets in the system.

This has been working. Incoming tickets are scanned for CFs, then
merged when the CF i’m looking for matches. Now here’s a funny
story…

I can’t create any child, or refers-to, or any other sort of new
ticket linked to this one. It has the same CF value, and is being
Created, so… it gets instantly merged into the original ticket…

The only workaround i can think of is to restrict the search and merge
to a queue, and create linked tickets outside that queue, but that
isn’t very satisfying and means explaining to everyone why they can
never have two linked tickets in the same queue. Anyone have a better
idea?


/chown -R us:us /yourbase


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

*Roy El-hames *

ISP Systems

Vialtus Solutions

(formerly Pipex Business)

Direct Dial: +44(0) 208 587 6181

E-mail: rfh@vialtus.com mailto:rfh@vialtus.com

Visit us on:

www.vialtus.com http://www.vialtus.com/

This email is subject to:

http://www.vialtus.com/disclaimer.html

What happens if you create the ticket first, then update /modify it adding
the CF and link relationship after …

I’m not sure what you mean; this is the chain of events already. The
ticket comes in, and ExtractCustomFieldValues scans the body for info
that goes into custom fields as it’s created.

Some tickets will need to spawn other tickets. Since they’re related
to the same task / info / event, they need to have the same CF data.
But since they have the same CF data, the ticket Create event merges
it into the parent or referrer or whatever.

I guess what i want is tickets that are created via email submission
should be merged without user intervention, but manually created
tickets should not.

Its more clicks for the users but may work for you …

I do not envision success telling the users that, heh.

In a way I think there is some contradictions on what you doing, you want
all tickets with the same CF to merge , but at the same time you want some
not to

Yeah, i guess more precisely it’s how they’re created that’s
important. Automated systems may spew 2-10 notifications about the
same event, and they arrive via email, and they should all be one
ticket. A user creating a ticket by hand should be trusted to be
creating a new ticket for a reason and not get it automerged.

If i can’t solve this, i either can’t automerge all the automated
duplicates, or i can’t use links. Neither option is attractive.

Clunky last resort at this point seems to be to clear the CF on the
form when following the Create link from Links… box, then add them
back afterwards. Bleh.

/chown -R us:us /yourbase

I’ve got this working in RT4.4. My one issue is that it matches and merges into tickets that are resolved or rejected. Ideally I’d prefer to merge only into new or open tickets. I’m not a developer so I haven’t been able to figure out how to do this yet.

Perhaps more importantly, I’d also like to match three CFs. Right now I’m extracting Subject, SourceIP, and DestinationIP from the email and inserting into CFs. I edited this script to merje based on subject like this:

my $subj = undef;
$subj = $self->TicketObj->FirstCustomFieldValue(‘Subject’);
$RT::Logger->debug(“My Subject: $subj for search.”);

my $TicketsObj = RT::Tickets->new($RT::SystemUser);
$TicketsObj->LimitCustomField(CUSTOMFIELD => ‘Subject’, OPERATOR => ‘=’, VALUE => $subj);

if ($TicketsObj->Count == 0) { return 1; }
my $id = undef;
while (my $ticket = $TicketsObj->Next) {
next if $self->TicketObj->Id == $ticket->Id;
$id = $ticket->Id;
$RT::Logger->debug(“Merging ticket " . $self->TicketObj->Id . " into $id because of Subject match.”);
$self->TicketObj->MergeInto($id);
}

$id || return 1;

1;

Could anyone assist me in editing this script further to merge if all three match of my CFs match, and it’s a new or open ticket.

OK, I got this working by extracting all the values I wanted to match into a single multi-line CF called matchstring, then added some additonal code to re-open a case if the match is on one that has already been closed.

my $matchstring = undef;
$matchstring = $self->TicketObj->FirstCustomFieldValue(‘Matchstring’);
$RT::Logger->debug(“My Matchstring: $matchstring for search.”);

my $TicketsObj = RT::Tickets->new($RT::SystemUser);
$TicketsObj->LimitCustomField(CUSTOMFIELD => ‘Matchstring’, OPERATOR => ‘=’, VALUE => $matchstring);

if ($TicketsObj->Count == 0) { return 1; }
my $id = undef;
while (my $ticket = $TicketsObj->Next) {
next if $self->TicketObj->Id == $ticket->Id;
$id = $ticket->Id;
$RT::Logger->debug(“Merging ticket " . $self->TicketObj->Id . " into $id because of matchstring match.”);
$self->TicketObj->MergeInto($id);
$id || return 1;
if( $ticket->Status ne “open” ) {
$ticket->SetStatus( “open” );
}
return 1;
}

1;

Thanks for bothering to come back and update this, I am actually knocking the rust off and implementing a new RT at a new site for the first time in… er, well, since that post up there!