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 objectId type field oldValue newValue Created n 193729 Status Status new resolved XXXXXXX n+1 193729 AddLink MergedInto null *******/193730 XXXXXXX
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.
