Hi Wiktor, Wiktor Wodecki schrieb:
Hi there,
this minor enhancement to Kernel/System/Ticket.pm allows the generic agent to use decision constraints based on changetime.
This is useful in automatic state changes scenarios where you'd want to escalate things.
Please consider to apply.
--- Ticket.pm.orig 2007-02-27 15:21:58.000000000 +0100 +++ Ticket.pm 2007-02-27 15:22:31.000000000 +0100 @@ -2660,6 +2660,10 @@ $SQLExt .= " AND st.until_time >= '".$Self->{DBObject}->Quote($Param{TicketPendingTimeNewerDate})."'"; } } + # get tickets changed more than x minutes ago + if ($Param{TicketChangeTimeOlder}) { + $SQLExt .= " AND st.change_time < NOW() - interval '".$Param{TicketChangeTimeOlder}."'"; + } # database query $SQLExt .= " ORDER BY $SortOptions{$SortBy}"; if ($OrderBy eq 'Up') {
The SQL-syntax "interval" isn't SQL-standard but MySQL-specific - am I right? Your modification really looks good as far as I can decide! I would appreciate it being included in further releases. I implemented a similar enhancement: I wrote a script with reusing bin/PendingJobs.pl that looks for tickets previously not worked on to send ToDo-notifications to the belonging agents. But my implementation uses the ticket-history and looks for the latests activities. Your approach to use change_time within Kernel::System::Ticket::TicketSearch is really interesting. The question is: When is change_time changed? As far as I could see, it is change within Kernel::System::Ticket through this subs: SetCustomerData TicketFreeTextSet PendingTimeSet LockSet StateSet ResponsibleSet PrioritySet TicketCreate So many (all?) changes on ticket-properties result in a refreshed change_time. But e.g. if you just add a note to a ticket, the change_time remains. This could also be a problem for you? My approach (can be found on mailing-list (german or english?)) notices the added note. Bye, Alex