[rt-users] Tikcet MergedInto Operation Problem in RT

[Yuming Zhu]

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" <tjrc at sanger.ac.uk>
To: "Yuming Zhu" <yzhu at redhat.com>
Cc: rt-users at 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 <yzhu at 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.