We recently upgraded our RT instance from 3.4.5 to 3.6.0. The new
version is really great and I like the fact that the front page can now
be customized so very easily.
There is one thing that has changed, and that’s the behaviour of RT when
dealing with merged tickets. Let’s say I have two tickets: 100 & 200.
I merge 100 into 200. In 3.4.5 I could type either ticket number
into the search box and bring up ticket 200. In 3.6.0 I can only access
ticket 200. Trying 100 in the search box returns “0 tickets found”.
If I use rt-mailgate and send an e-mail with a subject of [mydomain.com
#100] the transaction is properly appended to ticket 200, so there is no
problem along those lines.
Is this “working as designed” or has something gone awry between the two
versions?
Barry
Barry,
Not to say 3.6.0 is perfect, but we like the current design as far as
merged tickets. If we have merged the two (using your example of #100
and #200), then #100 really should never be looked at anyway, other than
what was originally appended to #200. We really don’t want anyone
looking at #100 anymore, ever. It is old, has been merged into another
ticket and, therefore, is not relevent to any further research or
discussion among anyone in our organization and we never want it
referred to either. We want everyone to refer to the ticket that is
active and being worked on. We feel that is consistent with the
decision to merge them in the first place. Anything else could get
confusing, like one person referring to #100 while another is referring
to #200 in an E_mail conversation. It opens the door to miscommunication
and communication is hard enough without opening the door to confusion.
But hey, that’s just our opinion and how we like it. Everyone has there
preferences.
Kenn
LBNL
Barry L. Kline wrote:
Barry,
Not to say 3.6.0 is perfect, but we like the current design as far as
merged tickets. If we have merged the two (using your example of #100
and #200), then #100 really should never be looked at anyway, other than
what was originally appended to #200. We really don’t want anyone
looking at #100 anymore, ever. It is old, has been merged into another
ticket and, therefore, is not relevent to any further research or
discussion among anyone in our organization and we never want it
referred to either. We want everyone to refer to the ticket that is
active and being worked on. We feel that is consistent with the
decision to merge them in the first place. Anything else could get
confusing, like one person referring to #100 while another is referring
to #200 in an E_mail conversation. It opens the door to miscommunication
and communication is hard enough without opening the door to confusion.
But hey, that’s just our opinion and how we like it. Everyone has there
preferences.
So what is the appropriate response for someone who has gotten
an email with the original number and wants to follow up but
someone else has merged it? How does that person referring
to #100 catch up? Merging it usually doesn’t make the problem
go away.
Les Mikesell
lesmikesell@gmail.com
Les Mikesell wrote:> On Mon, 2006-07-17 at 17:27, Kenneth Crocker wrote:
So what is the appropriate response for someone who has gotten
an email with the original number and wants to follow up but
someone else has merged it? How does that person referring
to #100 catch up? Merging it usually doesn’t make the problem
go away.
Hi Les.
That is my EXACT problem. We have some queues where the admins get
paged with a ticket. Let’s say that ticket #200 is created and the
admins get paged. One of them decides that 200 needs to be merged into
100 (for whatever reason). The other admins look at the queue, can’t
find 200 anymore and have no idea what happened to it. Was it deleted?
Was it merged? All they end up doing it wasting time trying to find
200.
I suppose I could write a scrip to send a notification when a ticket is
merged, but then I’d have to listen to the complaints of excessive pages.
Oh well, you win some and you lose some.
Barry
That is my EXACT problem. We have some queues where the admins get
paged with a ticket. Let’s say that ticket #200 is created and the
admins get paged. One of them decides that 200 needs to be merged into
100 (for whatever reason). The other admins look at the queue, can’t
find 200 anymore and have no idea what happened to it. Was it deleted?
Was it merged? All they end up doing it wasting time trying to find
200.
I suppose I could write a scrip to send a notification when a ticket is
merged, but then I’d have to listen to the complaints of excessive pages.
Oh well, you win some and you lose some.
Barry
I certainly hope this is a bug. Purposefully vaporizing request numbers
would be a very undesirable design decision as far as I’m concerned. I much
prefer being able to type in either request number and be redirected as
required.
Still on 3.4.4 right now. Waiting for things like this to shake out before
upgrading.
-Tim
That is my EXACT problem. We have some queues where the admins get
paged with a ticket. Let’s say that ticket #200 is created and the
admins get paged. One of them decides that 200 needs to be merged into
100 (for whatever reason). The other admins look at the queue, can’t
find 200 anymore and have no idea what happened to it. Was it deleted?
Was it merged? All they end up doing it wasting time trying to find
200.
I suppose I could write a scrip to send a notification when a ticket is
merged, but then I’d have to listen to the complaints of excessive pages.
Oh well, you win some and you lose some.
Barry
I certainly hope this is a bug. Purposefully vaporizing request numbers
would be a very undesirable design decision as far as I’m concerned. I much
prefer being able to type in either request number and be redirected as
required.
That is the intended behavior.
That is my EXACT problem. We have some queues where the admins get
paged with a ticket. Let’s say that ticket #200 is created and the
admins get paged. One of them decides that 200 needs to be merged
into
100 (for whatever reason). The other admins look at the queue, can’t
This is causing us problems in our workflow too. A search on either
ticket number should pull up the new merged ticket, whichver number
it is given.
Please restore the RT 3.4 behavior. Thanks.
smime.p7s (2.47 KB)
Not to say 3.6.0 is perfect, but we like the current design as far
as merged tickets. If we have merged the two (using your example of
#100 and #200), then #100 really should never be looked at anyway,
other than what was originally appended to #200. We really don’t
want anyone looking at #100 anymore,
The old behavior was that if you searched on ticket 100, it would
show you ticket 200. This is the only sensible behavior 
smime.p7s (2.47 KB)
(I’m pretty sure I did say this was bug the other day 
Patches are certainly welcome, if anyone wants to beat me to it.On Wed, Jul 19, 2006 at 12:39:04PM -0700, Kenneth Crocker wrote:
I agree wholeheartedly.
Kenn
LBNL
Vivek Khera wrote:
On Jul 17, 2006, at 6:27 PM, Kenneth Crocker wrote:
Not to say 3.6.0 is perfect, but we like the current design as far
as merged tickets. If we have merged the two (using your example of
#100 and #200), then #100 really should never be looked at anyway,
other than what was originally appended to #200. We really don’t want
anyone looking at #100 anymore,
The old behavior was that if you searched on ticket 100, it would show
you ticket 200. This is the only sensible behavior
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
We’re hiring! Come hack Perl for Best Practical:
Careers — Best Practical Solutions
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
We’re hiring! Come hack Perl for Best Practical:
Careers — Best Practical Solutions
(I’m pretty sure I did say this was bug the other day
Yes you did… and thus is the peril of having two threads on the same
subject displayed in a threaded mail reader…
I wouldn’t know where to look else I’d take a hack at fixing it.
smime.p7s (2.47 KB)