Lets say that there are 3 tickets. A, B and C If Ticket C is merged to Ticket B. And afterwards Ticket B is merged to Ticket A. Is it normal that when an extra email arrives for Ticket C that it will be added to Ticket B? I would expect the new email to be added to Ticket A. Currently my installation of OTRS 3.0.4 behaves like describe above, but it seems counter intuitive right? Dion
If Ticket C is merged to Ticket B. And afterwards Ticket B is merged to Ticket A.
Is it normal that when an extra email arrives for Ticket C that it will be added to Ticket B?
After I've merged "B" into "A", there is no "B" anymore where mail could be added to... How comes you still have a ticket "B"? frank
Ticket B does exist, or at least its TicketID. If this ticket is opened it does normally not have any messages attached, only the message that it is merged. But when I merge Ticket C with B, and then B with A. Then a new email with ticketID C will be attached to ticket B and not to ticket A. Dion -----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Frank Thommen Sent: vrijdag 5 augustus 2011 10:43 To: User questions and discussions about OTRS. Subject: Re: [otrs] Merging multiple Tickets
If Ticket C is merged to Ticket B. And afterwards Ticket B is merged to Ticket A.
Is it normal that when an extra email arrives for Ticket C that it will be added to Ticket B?
After I've merged "B" into "A", there is no "B" anymore where mail could be added to... How comes you still have a ticket "B"? frank --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
In the database there are the following tables that are relative to merged tickets 'ticket' 'link_type' 'link_relation' The 'ticket' table has, among others, columns called 'id' and 'tn'. The 'id' column holds a number used in the database as a reference. The 'tn' column holds the ticket number as displayed in the web interface. The 'link_type' table has columns called 'id' and 'name' The 'id' column holds a reference number for the entry in this table The 'name' column holds the text describing the entry. The 'link_relation' table has columns called 'source_key', 'target_key' and 'type_id' The 'source_key' holds a reference to a ticket 'id' in the 'ticket' table The 'target_key' holds a reference to a ticket 'id' in the 'ticket' table The 'type_id' holds a reference to the 'id' in the 'link_type' table Each entry in the link_relation table has only one source id and one target id.
From your example tickets A, B and C all continue to exist in the database even after they are merged. When C is merged to B an entry is entered in the link_relation table using the link_type id of 2 ... ParentChild ... With B as the source and C as the target. When B is subsequently merged to ticket A a second entry is created in the link_relation table using the id of 2 again. This time A is the source and B is the target.
When a reply is received for ticket C the ticket number is stripped from the
subject and a database lookup retrieves the 'id' from the 'ticket' table
used in the database.
This id is then checked against the 'target_key' column of th
'link_relation' table. If an entry is found then the corresponding
'source_key' is retrieved to identify the parent ticket.
In this way the system identifies that B is the parent of C.
Taking a leap of faith here (and going by your experience), I do not think
it does any subsequent check to see if B has a parent.
This would explain why replies to C are added to the ticket B and not A.
Rory
On 5 August 2011 09:50, Dion van Adrichem
Ticket B does exist, or at least its TicketID. If this ticket is opened it does normally not have any messages attached, only the message that it is merged.
But when I merge Ticket C with B, and then B with A. Then a new email with ticketID C will be attached to ticket B and not to ticket A.
Dion
-----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Frank Thommen Sent: vrijdag 5 augustus 2011 10:43 To: User questions and discussions about OTRS. Subject: Re: [otrs] Merging multiple Tickets
If Ticket C is merged to Ticket B. And afterwards Ticket B is merged to Ticket A.
Is it normal that when an extra email arrives for Ticket C that it will be added to Ticket B?
After I've merged "B" into "A", there is no "B" anymore where mail could be added to... How comes you still have a ticket "B"?
frank --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
This is a correct observation Rory. But the point is, should OTRS check for a possible next parent? In my opinion, yes. Dion From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Rory Sent: vrijdag 5 augustus 2011 11:49 To: User questions and discussions about OTRS. Subject: Re: [otrs] Merging multiple Tickets In the database there are the following tables that are relative to merged tickets 'ticket' 'link_type' 'link_relation' The 'ticket' table has, among others, columns called 'id' and 'tn'. The 'id' column holds a number used in the database as a reference. The 'tn' column holds the ticket number as displayed in the web interface. The 'link_type' table has columns called 'id' and 'name' The 'id' column holds a reference number for the entry in this table The 'name' column holds the text describing the entry. The 'link_relation' table has columns called 'source_key', 'target_key' and 'type_id' The 'source_key' holds a reference to a ticket 'id' in the 'ticket' table The 'target_key' holds a reference to a ticket 'id' in the 'ticket' table The 'type_id' holds a reference to the 'id' in the 'link_type' table Each entry in the link_relation table has only one source id and one target id.
From your example tickets A, B and C all continue to exist in the database even after they are merged. When C is merged to B an entry is entered in the link_relation table using the link_type id of 2 ... ParentChild ... With B as the source and C as the target. When B is subsequently merged to ticket A a second entry is created in the link_relation table using the id of 2 again. This time A is the source and B is the target.
When a reply is received for ticket C the ticket number is stripped from the
subject and a database lookup retrieves the 'id' from the 'ticket' table
used in the database.
This id is then checked against the 'target_key' column of th
'link_relation' table. If an entry is found then the corresponding
'source_key' is retrieved to identify the parent ticket.
In this way the system identifies that B is the parent of C.
Taking a leap of faith here (and going by your experience), I do not think
it does any subsequent check to see if B has a parent.
This would explain why replies to C are added to the ticket B and not A.
Rory
On 5 August 2011 09:50, Dion van Adrichem
If Ticket C is merged to Ticket B. And afterwards Ticket B is merged to Ticket A.
Is it normal that when an extra email arrives for Ticket C that it will be added to Ticket B?
After I've merged "B" into "A", there is no "B" anymore where mail could be added to... How comes you still have a ticket "B"? frank --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
participants (3)
-
Dion van Adrichem -
Frank Thommen -
Rory