Disclaimer: The following is a modification of OTRS core files and insertion of data into OTRS tables. If you don't feel comfortable with this, don't do it. Get someone to help you. It modifies a core component of OTRS, so please make and verify backups before you start. There is no warranty associated with the following, and any changes you'd make to your installation of OTRS are your responsibility to fix. It's possible to modify Ticket.pm: For example, after my $DestinationTime = $Self->{TimeObject}->DestinationTime( StartTime => $Self->{TimeObject}->TimeStamp2SystemTime( String => $Ticket{Created} ), Time => $Escalation{FirstResponseTime} * 60, Calendar => $Escalation{Calendar}, ); # update first response time to $DestinationTime $Self->{DBObject}->Do( SQL => 'UPDATE ticket SET escalation_response_time = ?, change_time = current_timestamp, ' . ' change_by = ? WHERE id = ?', Bind => [ \$DestinationTime, \$Param{UserID}, \$Ticket{TicketID}, ] ); add: # add history $Self->HistoryAdd( TicketID => $Param{TicketID}, CreateUserID => $Param{UserID}, HistoryType => 'EscalationResponseTimeStart', Name => "\%\%Escalation Solution Time Stopped", #something that makes sense to where it happened. ); note that merge/close/remove sets: # update escalation times with 0 my %EscalationTimes = ( EscalationTime => 'escalation_time', EscalationResponseTime => 'escalation_response_time', EscalationUpdateTime => 'escalation_update_time', EscalationSolutionTime => 'escalation_solution_time', ); These are the values that are stored (therefore they'd be good candidates for HistoryAdd): # (time stamps of expected escalations) EscalationResponseTime (unix time stamp of response time escalation) EscalationUpdateTime (unix time stamp of update time escalation) EscalationSolutionTime (unix time stamp of solution time escalation) # (general escalation info of nearest escalation type) EscalationDestinationIn (escalation in e. g. 1h 4m) EscalationDestinationTime (date of escalation in unix time, e. g. 72193292) EscalationDestinationDate (date of escalation, e. g. "2009-02-14 18:00:00") EscalationTimeWorkingTime (seconds of working/service time till escalation, e. g. "1800") EscalationTime (seconds total till escalation of nearest escalation time type - response, update or solution time, e. g. "3600") And these are the ticket_history_types >40 stored in ticket_history_type nameEscalationSolutionTimeStopEscalationResponseTimeStart EscalationUpdateTimeStartEscalationSolutionTimeStart EscalationResponseTimeNotifyBeforeEscalationUpdateTimeNotifyBefore EscalationSolutionTimeNotifyBeforeEscalationResponseTimeStop EscalationUpdateTimeStop Now, admittedly, the ticket_history_types are more granular (start/stop) than the Ticket's escalation entries, which appear to only occur as they happen. In my opinion if you're going to go as far as to add these HistoryAdd entries to Ticket.pm, you might as well provide yourself some custom ticket_history_types to match, therefore you can look them up. Make sure valid_id is 1 and you may want to make sure create_by and change_by is 1 (or a different user id (an integer), if you want to be sure you did it...) "Can't this be done without hacking the code?" No. As you'll see in Ticket.pm, there is no HistoryAdd for Escalations. If there were, I think we wouldn't be discussing this. "What's the downside of adding custom ticket_history_types?" Theoretically, none. Just don't collide with existing names (keep the name unique). Oh, there's a possibility that OTRS may eventually add identically named history_types so you may want to prefix your names (my_EscalationResponseTime) ? as you add them. Difficulty level: low to moderate. (requires some basic knowledge of proper placement of code and a tolerance to modify/insert data into tables) Danger level: low if it's implemented correctly. High if you don't terminate strings, parentheses, semicolons properly. This modifies Ticket.pm. If your entry breaks it, Tickets can't be processed, and OTRS will not work at all. Have a backup ready and test in a test environment. Will not survive updates. I hope this helps someone. On Thu, Oct 25, 2012 at 8:46 AM, Derek Kiely wrote:

Hi Phillippe,

This is something that I would really like to be able to use. Please let me know if you have found a way of doing this or have a workaround for implementing it.

Many Thanks

Derek Kiely

-----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Philippe-Arnaud HARANGER Sent: 24 October 2012 09:03 To: otrs@otrs.org Subject: [otrs] Putting Escalation statuses into the ticket history

Hello,

I'm currently looking for a elegant way to keep track of the different escalations a ticket had been through. To my understanding, the elements currently in the ticket_history_type table from from 41 to 49 are destined to do so. As per ./scripts/test/Event/Escalations.t, lines 256 and following, it also seems that they aren't implemented yet.

Can you give me any feedback on this subject? Does anyone knows when the function is planned to be released? If not how may I contribute?

Cheers,

Philippe-Arnaud

(This message is a bump from the dev@ list.) --------------------------------------------------------------------- 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

Thanks Gerald I will give it a go, much appreciated. Derek Kiely From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Gerald Young Sent: 25 October 2012 14:49 To: User questions and discussions about OTRS. Subject: Re: [otrs] Putting Escalation statuses into the ticket history Hasten to add: You may find that you'll need $Ticket{TicketID} instead of $Param{TicketID} if the former is being referenced previously. On Thu, Oct 25, 2012 at 9:44 AM, Gerald Young mailto:crythias@gmail.com> wrote: Disclaimer: The following is a modification of OTRS core files and insertion of data into OTRS tables. If you don't feel comfortable with this, don't do it. Get someone to help you. It modifies a core component of OTRS, so please make and verify backups before you start. There is no warranty associated with the following, and any changes you'd make to your installation of OTRS are your responsibility to fix. It's possible to modify Ticket.pm: For example, after my $DestinationTime = $Self->{TimeObject}->DestinationTime( StartTime => $Self->{TimeObject}->TimeStamp2SystemTime( String => $Ticket{Created} ), Time => $Escalation{FirstResponseTime} * 60, Calendar => $Escalation{Calendar}, ); # update first response time to $DestinationTime $Self->{DBObject}->Do( SQL => 'UPDATE ticket SET escalation_response_time = ?, change_time = current_timestamp, ' . ' change_by = ? WHERE id = ?', Bind => [ \$DestinationTime, \$Param{UserID}, \$Ticket{TicketID}, ] ); add: # add history $Self->HistoryAdd( TicketID => $Param{TicketID}, CreateUserID => $Param{UserID}, HistoryType => 'EscalationResponseTimeStart', Name => "\%\%Escalation Solution Time Stopped", #something that makes sense to where it happened. ); note that merge/close/remove sets: # update escalation times with 0 my %EscalationTimes = ( EscalationTime => 'escalation_time', EscalationResponseTime => 'escalation_response_time', EscalationUpdateTime => 'escalation_update_time', EscalationSolutionTime => 'escalation_solution_time', ); These are the values that are stored (therefore they'd be good candidates for HistoryAdd): # (time stamps of expected escalations) EscalationResponseTime (unix time stamp of response time escalation) EscalationUpdateTime (unix time stamp of update time escalation) EscalationSolutionTime (unix time stamp of solution time escalation) # (general escalation info of nearest escalation type) EscalationDestinationIn (escalation in e. g. 1h 4m) EscalationDestinationTime (date of escalation in unix time, e. g. 72193292) EscalationDestinationDate (date of escalation, e. g. "2009-02-14 18:00:00") EscalationTimeWorkingTime (seconds of working/service time till escalation, e. g. "1800") EscalationTime (seconds total till escalation of nearest escalation time type - response, update or solution time, e. g. "3600") And these are the ticket_history_types >40 stored in ticket_history_type name EscalationSolutionTimeStop EscalationResponseTimeStart EscalationUpdateTimeStart EscalationSolutionTimeStart EscalationResponseTimeNotifyBefore EscalationUpdateTimeNotifyBefore EscalationSolutionTimeNotifyBefore EscalationResponseTimeStop EscalationUpdateTimeStop Now, admittedly, the ticket_history_types are more granular (start/stop) than the Ticket's escalation entries, which appear to only occur as they happen. In my opinion if you're going to go as far as to add these HistoryAdd entries to Ticket.pm, you might as well provide yourself some custom ticket_history_types to match, therefore you can look them up. Make sure valid_id is 1 and you may want to make sure create_by and change_by is 1 (or a different user id (an integer), if you want to be sure you did it...) "Can't this be done without hacking the code?" No. As you'll see in Ticket.pm, there is no HistoryAdd for Escalations. If there were, I think we wouldn't be discussing this. "What's the downside of adding custom ticket_history_types?" Theoretically, none. Just don't collide with existing names (keep the name unique). Oh, there's a possibility that OTRS may eventually add identically named history_types so you may want to prefix your names (my_EscalationResponseTime) ? as you add them. Difficulty level: low to moderate. (requires some basic knowledge of proper placement of code and a tolerance to modify/insert data into tables) Danger level: low if it's implemented correctly. High if you don't terminate strings, parentheses, semicolons properly. This modifies Ticket.pm. If your entry breaks it, Tickets can't be processed, and OTRS will not work at all. Have a backup ready and test in a test environment. Will not survive updates. I hope this helps someone. On Thu, Oct 25, 2012 at 8:46 AM, Derek Kiely mailto:dkiely@kemptechnologies.com> wrote: Hi Phillippe, This is something that I would really like to be able to use. Please let me know if you have found a way of doing this or have a workaround for implementing it. Many Thanks Derek Kiely -----Original Message----- From: otrs-bounces@otrs.orgmailto:otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.orgmailto:otrs-bounces@otrs.org] On Behalf Of Philippe-Arnaud HARANGER Sent: 24 October 2012 09:03 To: otrs@otrs.orgmailto:otrs@otrs.org Subject: [otrs] Putting Escalation statuses into the ticket history Hello, I'm currently looking for a elegant way to keep track of the different escalations a ticket had been through. To my understanding, the elements currently in the ticket_history_type table from from 41 to 49 are destined to do so. As per ./scripts/test/Event/Escalations.t, lines 256 and following, it also seems that they aren't implemented yet. Can you give me any feedback on this subject? Does anyone knows when the function is planned to be released? If not how may I contribute? Cheers, Philippe-Arnaud (This message is a bump from the dev@ list.) --------------------------------------------------------------------- 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