tickets with problematic StateUpdate events

[PavelV]

Hello,

I'm trying to understand how StateUpdates events work in TICKET_HISTORY table, but for merged tickets there are sometime sequences which I don't understad, I think they must be brought there somehow from child tickets.
Is there some clear rule/logic biehind which can help to distingush events which are valid for the Master ticket ?

e.g.

Code: Select all

StateUpdate		|[color=#00DD00]Old: "new" New: "solved"[/color]							|	UserX		|	31.1.2019 13:21
Unlock			|Unlocked ticket.											|	UserX		|	31.1.2019 13:21
Misc			|ResponseTemplate (102/848351/852132)								|	UserX		|	31.1.2019 13:21
EmailCustomer		|Added email. Because the old ticket [INC_2019013175000863] is 'solved'	|	Admin OTRS	|	1.2.2019 2:35
TicketLinkAdd		|Added link to ticket "INC_2019020175000533".						|	Admin OTRS	|	1.2.2019 2:35
SendAnswer		|Email sent to ..												|	UserX		|	1.2.2019 6:57
TimeAccounting		|15 time unit(s) accounted. Now total 15 time unit(s).					|	UserX		|	1.2.2019 6:57
StateUpdate		|[color=#DD0000]Old: "new" New: "pending reminder"[/color]								|	UserX		|	1.2.2019 6:57
SendCustomerNotification|	Notification sent to ..															|	UserX		|	1.2.2019 6:57
FollowUp					|	FollowUp for [INC_2019020175000533].											|	Admin OTRS	|	1.2.2019 7:35
AddNote						|	Added note (Note)																|	UserY		|	1.2.2019 7:41
Merged						|	Merged Ticket (INC_2019020175000533/232958) to (INC_2019013175000863/230882)	|	UserY		|	1.2.2019 7:41
TicketLinkAdd				|	Added link to ticket "INC_2019020175000533".									|	UserY		|	1.2.2019 7:41
FollowUp					|	FollowUp for [INC_2019020175000533].											|	Admin OTRS	|	7.2.2019 7:15
Merged						|	Merged Ticket (INC_2019020175000533/232958) to (INC_2019013175000863/230882)	|	UserX		|	7.2.2019 7:25
TicketLinkAdd				|	Added link to ticket "INC_2019020175000533".									|	UserX		|	7.2.2019 7:25
Lock						|	Locked ticket.																	|	UserX		|	7.2.2019 9:57
Misc						|	Reset of unlock time.															|	UserX		|	7.2.2019 9:57
StateUpdate					|[color=#00DD00]Old: "solved" New: "closed successful"[/color]										|	Admin OTRS	|	8.2.2019 2:11
Unlock						|	Unlocked ticket.																|	UserX		|	12.2.2019 14:33

Using OTRS v5

[crythias]

The datetimestamps from all ticket articles and history will not change from their original ticket, so when they merge, you're going to have some issues with the other ticket's StateUpdates because the history doesn't keep track in itself the ticket number/ticket ID. that it changed on.

Mostly because the ticket_id is tracked by field.

This is probably fixable by a change within the StateUpdate UpdateHistory function.

But you don't have to change code for that. You can use a GenericAgent to make your own StateUpdate note/article (internal/not customer facing) and/or update an article field or two (ticket number and state change info) with fields from <OTRS_Ticket_xxx> and track via that.
It doesn't much help in history, but in the future...

Or don't merge at all and keep links.

[PavelV]

It doesn't much help in history, but in the future...

I'm mostly interested in analyzing history , I suppose we cannot fix this retrospectively that what is written in TICKET_HISTORY table cannot be changed by OTRS anymore ?

Would you say that if we will verify that StateUpdate is following sequence(corresponds with previous state) that it could be a reliable solution ?

e.g.
1. new (created by NewTicket always valid)
2. new->open (valid)
3. new->pending (not valid, expected previous state open)
4. open->pending (valid)
5. open->pending (not valid, expected previous state pending)
4. pending->solved (valid)
5. solved->closed (valid)

[crythias]

There's no reason that new can't go straight to pending from the pending menu item.

The only potential things that can help are the create_time of the history being out of sanity check (for this ticket) where February 1 is different from February 7.