Thanks Gerald

I will give it a go, much appreciated.

Derek Kiely

From: otrs-boun...@otrs.org [mailto:otrs-boun...@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 
<cryth...@gmail.com<mailto:cryth...@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 
<dki...@kemptechnologies.com<mailto:dki...@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-boun...@otrs.org<mailto:otrs-boun...@otrs.org> 
[mailto:otrs-boun...@otrs.org<mailto:otrs-boun...@otrs.org>] On Behalf Of 
Philippe-Arnaud HARANGER
Sent: 24 October 2012 09:03
To: otrs@otrs.org<mailto: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


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

Reply via email to