Howdy All.
We work with a vendor and store the vendor’s ticket # in a custom field.
We’d like to be able to add a comment to the RT ticket by "cc"ing RT on
vendor email. The subject of the message contains the vendor ticket
number, and I’ll determine the RT # via a search.
I’m trying to figure out the best way to do this. The “Right” method
appears to be a custom RT::Interface::Email module, but the only “hook"
appears to be GetCurrentUser and there’s no way to set ticket number or
modify the message. I looked at the code and don’t see a
"GetCurrentTicket” callback. Are the RT::Interface::Email modules
only good for authentication?
Another method is to replace the rt-mailgate script with one of my
own. This seems like an “excessive” hack into RT internals. Is there
a more official way?
Robert
Howdy All.
We work with a vendor and store the vendor’s ticket # in a custom field.
We’d like to be able to add a comment to the RT ticket by "cc"ing RT on
vendor email. The subject of the message contains the vendor ticket
number, and I’ll determine the RT # via a search.
I’m trying to figure out the best way to do this. The “Right” method
appears to be a custom RT::Interface::Email module, but the only “hook”
appears to be GetCurrentUser and there’s no way to set ticket number or
modify the message. I looked at the code and don’t see a
“GetCurrentTicket” callback. Are the RT::Interface::Email modules
only good for authentication?
Another method is to replace the rt-mailgate script with one of my
own. This seems like an “excessive” hack into RT internals. Is there
a more official way?
You may just want to borrow the Nagios scrips on the wiki and On
Create find the existing ticket you need to merge into and set the CF
from there. You’ll find the Scrip Action interface to be a lot easier
to do what you need (since the tickets exist and you can set
properties).
-kevin
Howdy All.
We work with a vendor and store the vendor’s ticket # in a custom field.
We’d like to be able to add a comment to the RT ticket by "cc"ing RT on
vendor email. The subject of the message contains the vendor ticket
number, and I’ll determine the RT # via a search.
…
You may just want to borrow the Nagios scrips on the wiki and On
Create find the existing ticket you need to merge into and set the CF
from there. You’ll find the Scrip Action interface to be a lot easier
to do what you need (since the tickets exist and you can set
properties).
Thanks for the idea Kevin… I got a modified scrip working. That
solution takes the new ticket and merges it with my main one. It works,
but you have the side-effect of potentially a lot of extra tickets and
also additional “requestors” because they’re merged.
Is there any way to avoid the new ticket with new requestor? I get the
feeling the ticket is already created by the time “on-create” hits, so
that damage is already done.
One solution is to extract the text and add the comment to the other
ticket and then change the status of the newly created ticket to
“delete”. I still get an extra ticket, but at least it doesn’t do much
harm. I’m leaning towards that… I guess it’s cleaner than intercepting
it at the mail entry.
Robert
Howdy All.
We work with a vendor and store the vendor’s ticket # in a custom field.
We’d like to be able to add a comment to the RT ticket by "cc"ing RT on
vendor email. The subject of the message contains the vendor ticket
number, and I’ll determine the RT # via a search.
…
You may just want to borrow the Nagios scrips on the wiki and On
Create find the existing ticket you need to merge into and set the CF
from there. You’ll find the Scrip Action interface to be a lot easier
to do what you need (since the tickets exist and you can set
properties).
Thanks for the idea Kevin… I got a modified scrip working. That
solution takes the new ticket and merges it with my main one. It works,
but you have the side-effect of potentially a lot of extra tickets and
also additional “requestors” because they’re merged.
Is there any way to avoid the new ticket with new requestor? I get the
feeling the ticket is already created by the time “on-create” hits, so
that damage is already done.
Tickets must exist for Scrips to run on them
One solution is to extract the text and add the comment to the other
ticket and then change the status of the newly created ticket to
“delete”. I still get an extra ticket, but at least it doesn’t do much
harm. I’m leaning towards that… I guess it’s cleaner than intercepting
it at the mail entry.
I’m not sure what this buys you over merging the ticket (which
effectively makes the new ticket disappear into the old ticket) but if
it helps you manage your Requestors, then go for it
-kevin
Howdy All.
We work with a vendor and store the vendor’s ticket # in a custom field.
We’d like to be able to add a comment to the RT ticket by "cc"ing RT on
vendor email. The subject of the message contains the vendor ticket
number, and I’ll determine the RT # via a search.
…
You may just want to borrow the Nagios scrips on the wiki and On
Create find the existing ticket you need to merge into and set the CF
from there. You’ll find the Scrip Action interface to be a lot easier
to do what you need (since the tickets exist and you can set
properties).
Thanks for the idea Kevin… I got a modified scrip working. That
solution takes the new ticket and merges it with my main one. It works,
but you have the side-effect of potentially a lot of extra tickets and
also additional “requestors” because they’re merged.
Is there any way to avoid the new ticket with new requestor? I get the
feeling the ticket is already created by the time “on-create” hits, so
that damage is already done.
Tickets must exist for Scrips to run on them
One solution is to extract the text and add the comment to the other
ticket and then change the status of the newly created ticket to
“delete”. I still get an extra ticket, but at least it doesn’t do much
harm. I’m leaning towards that… I guess it’s cleaner than intercepting
it at the mail entry.
I’m not sure what this buys you over merging the ticket (which
effectively makes the new ticket disappear into the old ticket) but if
it helps you manage your Requestors, then go for it
-kevin
Has the performance problem with many merged tickets been resolved?
If not, this method will perform better instead of taking much time
and CPU to pull up a ticket with many, many merges.
Regards,
Ken