We have a ticket in our RT 3.6.6 installation containing correspondence which
belongs to a different ticket.
(A user followed up on a ticket using a new message with a changed subject
line, sent direct to one of my technicians, rather than replying to the RT
system’s address.
The technician pasted the tag in the subject line and forwarded the messages
to RT - but unfortunately pasted the wrong tag, resulting in the messages
being attached to the wrong ticket).
I know how to identify the transaction numbers (from the links to the
transactions in the ticket history), but is there any easy way to move the
transactions to the correct ticket?
I know how to identify the transaction numbers (from the links to the
transactions in the ticket history), but is there any easy way to move the
transactions to the correct ticket?
I’m sure someone else will have a more authoritative answer, but it
looks as if you could simply update the “objectid” field of the
corresponding transaction in the transactions table. Something like:
update transactions set objectid = where id =
;
This worked just fine in my simple test. Note that I’m working from
RT 3.8.1 assumptions, but our production RT 3.4.6 install appears to
have a similar schema.
Yeah, it can be that easy as described by Lars, however you loose
notifications when you move txns around using this way.
May be it’s better to forward again to correct ticket and tender an
apology in another.On Fri, Oct 31, 2008 at 5:23 PM, Lars Kellogg-Stedman lars@oddbit.com wrote:
I know how to identify the transaction numbers (from the links to the
transactions in the ticket history), but is there any easy way to move the
transactions to the correct ticket?
I’m sure someone else will have a more authoritative answer, but it
looks as if you could simply update the “objectid” field of the
corresponding transaction in the transactions table. Something like:
update transactions set objectid = where id =
;
This worked just fine in my simple test. Note that I’m working from
RT 3.8.1 assumptions, but our production RT 3.4.6 install appears to
have a similar schema.
Yeah, it can be that easy as described by Lars, however you loose
notifications when you move txns around using this way.
How hard would it be to add a “move to another ticket” option to each
transaction? Maybe one that’s only available on the “History” page,
rather than in the normal view? Or maybe just a new permission to
enable it? I know I’ve seen requests for this sort of thing before,
but I’ve never really thought about the implications.
Yeah, it can be that easy as described by Lars, however you loose
notifications when you move txns around using this way.
How hard would it be to add a “move to another ticket” option to each
transaction? Maybe one that’s only available on the “History” page,
rather than in the normal view? Or maybe just a new permission to
enable it? I know I’ve seen requests for this sort of thing before,
but I’ve never really thought about the implications.
That violates part of RT’s central “history is immutable” philosophy. At
a code level, it should be pretty straight forward, but it’s unlikely to
ever be accepted in the core.
“Jesse” == Jesse Vincent jesse@bestpractical.com writes:
How hard would it be to add a “move to another ticket” option to
each transaction? Maybe one that’s only available on the
“History” page, rather than in the normal view? Or maybe just a
new permission to enable it? I know I’ve seen requests for this
sort of thing before, but I’ve never really thought about the
implications.
Jesse> That violates part of RT's central "history is immutable"
Jesse> philosophy. At a code level, it should be pretty straight
Jesse> forward, but it's unlikely to ever be accepted in the core.
So, make it “copy”, and let the original copy be marked up as having
been moved, but not remove it.
SIMtone Corporation fundamentally transforms computing into simple,
secure, and very low-cost network-provisioned services pervasively
accessible by everyone. Learn more at www.simtone.net and www.SIMtoneVDU.com
So, make it “copy”, and let the original copy be marked up as having
been moved, but not remove it.
+1
Because there’s a different between “history is immutable” and “my
software knows better than you”. People do make mistakes, and it’s
nice to be able to correct them. My secret vested interest in this is
that if I adopt the use of message-id references for associating email
with tickets, I need a mechanism for correcting the case where someone
replies to an old email with the intent of opening a new issue.
Copy would be lovely. As would “clone this transaction to a new ticket”
So maybe in addition to “Reply” and “Comment”, and “Forward” on each
transaction, there would be a “Clone”? Should this be associated with
a new permission?
Copy would be lovely. As would “clone this transaction to a new ticket”
So maybe in addition to “Reply” and “Comment”, and “Forward” on each
transaction, there would be a “Clone”? Should this be associated with
a new permission?
Probably.
Minor UI item, at that point, I may want to replace the buttons with a
dropdown of actions.
I believe Dirk Pape has a Fork/Clone patch floating around out there. I
think it was him. I know I snagged it from somewhere.
Jesse Vincent wrote:
So, make it “copy”, and let the original copy be marked up as having
been moved, but not remove it.
+1
Copy would be lovely. As would “clone this transaction to a new ticket”
Because there’s a different between “history is immutable” and “my
software knows better than you”. People do make mistakes, and it’s
nice to be able to correct them. My secret vested interest in this is
that if I adopt the use of message-id references for associating email
with tickets, I need a mechanism for correcting the case where someone
replies to an old email with the intent of opening a new issue.