Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
On Jul 19, 2006, at 3:51 PM, Jesse Vincent wrote: (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 Description: S/MIME cryptographic signature ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
(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 :-) > > > > > > > > > >___ > >http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > > >Community help: http://wiki.bestpractical.com > >Commercial support: [EMAIL PROTECTED] > > > > > >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: > >http://bestpractical.com/about/jobs.html > ___ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [EMAIL PROTECTED] > > > 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: > http://bestpractical.com/about/jobs.html > -- ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
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 :-) ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
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 :-) smime.p7s Description: S/MIME cryptographic signature ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
On Jul 18, 2006, at 9:27 AM, Barry L. Kline wrote: 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 Description: S/MIME cryptographic signature ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
On Tue, Jul 18, 2006 at 10:59:05AM -0700, Tim Berger wrote: > On 7/18/06, Barry L. Kline <[EMAIL PROTECTED]> wrote: > > > > > >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. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
On 7/18/06, Barry L. Kline <[EMAIL PROTECTED]> wrote: That is my EXACT problem. We have some queues where the admins getpaged with a ticket. Let's say that ticket #200 is created and theadmins 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'tfind 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 ismerged, 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 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
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 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
On Mon, 2006-07-17 at 17:27, Kenneth Crocker 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 [EMAIL PROTECTED] ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
Re: [rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
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: 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 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
[rt-users] Search on merged ticket differs between 3.4.5 & 3.6.0
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 ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] 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: http://bestpractical.com/about/jobs.html
