Re: [rt-users] Tikcet MergedInto Operation Problem in RT
On 3 Apr 2013, at 03:41, Yuming Zhu y...@redhat.com wrote: Hi, Guys I got a problem when I query the DB for ticket history data. When I do this operations on rt web, the DB Tickets table as followed: 1. create two tickets 193729 193730 id EffectiveId Status -- --- - 193729 193729 new 193730 193730 new 2. merge 193729 into 193730. 193729's status becomes resolved id EffectiveId Status -- --- - 193729 193730 resolved 193730 193730 new so in STEP II, status of merged ticket became resolved But if this, because ticket can be created with new, open or resolved status, and if there's no any status change before merging, the status of merged ticket couldn't be known logically. so we can't get the exact history data, although the case should hardly exist. I'm not sure I understand the problem. The status of the merged ticket is now 'new' which what you'd expect. The status of 193729 isn't really relevant any more, is it? Could it be considered as a bug or defect for change(remove this feature or add a status change record in transactions table)? This behaviour is configurable in ticket lifecycles. The default is that the ticket that was merged away from is set to resolved. You can change that to whatever you like, although the documentation does recommend that it's an 'inactive' status (defined elsewhere in the lifecycle, but resolved or rejected by default) I suspect odd things might happen if you set it to an active status. You could always create a new inactive status 'merged' in the lifecycle, and then set the on_merge status to that. I don't think it makes much difference though, since the status of the merged away ticket isn't displayed anywhere in the UI. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: [rt-users] Tikcet MergedInto Operation Problem in RT
Hi, Tim Sorry for this unclear description. I mean that the Status of merged ticket #193029 between Creation and Merging Operation can not be sure, if I want to get the history by DB queries. Because of the resolving action with MergedInto Operation hasn't been record in Transactions Table, such as id objectIdtypefield oldValue newValueCreated n 193729 StatusStatus new resolved XXX n+1 193729 AddLinkMergedInto null ***/193730 XXX Now through OldValue new of transaction n, I can get that status before merged. I think it's the only way in my case. It's also what I exactly expect, so that every change of ticket can be found in Transactions Table. Cheers, Yuming. - Original Message - From: Tim Cutts t...@sanger.ac.uk To: Yuming Zhu y...@redhat.com Cc: rt-users@lists.bestpractical.com Sent: Wednesday, April 3, 2013 4:12:50 PM Subject: Re: [rt-users] Tikcet MergedInto Operation Problem in RT On 3 Apr 2013, at 03:41, Yuming Zhu y...@redhat.com wrote: Hi, Guys I got a problem when I query the DB for ticket history data. When I do this operations on rt web, the DB Tickets table as followed: 1. create two tickets 193729 193730 id EffectiveId Status -- --- - 193729 193729 new 193730 193730 new 2. merge 193729 into 193730. 193729's status becomes resolved id EffectiveId Status -- --- - 193729 193730 resolved 193730 193730 new so in STEP II, status of merged ticket became resolved But if this, because ticket can be created with new, open or resolved status, and if there's no any status change before merging, the status of merged ticket couldn't be known logically. so we can't get the exact history data, although the case should hardly exist. I'm not sure I understand the problem. The status of the merged ticket is now 'new' which what you'd expect. The status of 193729 isn't really relevant any more, is it? Could it be considered as a bug or defect for change(remove this feature or add a status change record in transactions table)? This behaviour is configurable in ticket lifecycles. The default is that the ticket that was merged away from is set to resolved. You can change that to whatever you like, although the documentation does recommend that it's an 'inactive' status (defined elsewhere in the lifecycle, but resolved or rejected by default) I suspect odd things might happen if you set it to an active status. You could always create a new inactive status 'merged' in the lifecycle, and then set the on_merge status to that. I don't think it makes much difference though, since the status of the merged away ticket isn't displayed anywhere in the UI. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
[rt-users] Tikcet MergedInto Operation Problem in RT
Hi, Guys I got a problem when I query the DB for ticket history data. When I do this operations on rt web, the DB Tickets table as followed: 1. create two tickets 193729 193730 id EffectiveId Status -- --- - 193729 193729 new 193730 193730 new 2. merge 193729 into 193730. 193729's status becomes resolved id EffectiveId Status -- --- - 193729 193730 resolved 193730 193730 new so in STEP II, status of merged ticket became resolved But if this, because ticket can be created with new, open or resolved status, and if there's no any status change before merging, the status of merged ticket couldn't be known logically. so we can't get the exact history data, although the case should hardly exist. Could it be considered as a bug or defect for change(remove this feature or add a status change record in transactions table)? Thanks Yuming Zhu
