Tikcet MergedInto Operation Problem in RT

RT Users
1

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

  1. 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

2

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

  1. 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.

3

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.From: “Tim Cutts” tjrc@sanger.ac.uk
To: “Yuming Zhu” yzhu@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

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

  1. 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.