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 <[email protected]> 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 > EscalationSolutionTimeStopEscalationResponseTimeStartEscalationUpdateTimeStart > 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 > <[email protected]>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: [email protected] [mailto:[email protected]] On Behalf Of >> Philippe-Arnaud HARANGER >> Sent: 24 October 2012 09:03 >> To: [email protected] >> 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 >> > >
--------------------------------------------------------------------- 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
