
Hi,
I'm trying to have unlock timeouts working on the system but it won't.
I've set up a 1 minute unlock timeout for Postmaster Queue (which receives
all tickets).
I create a new ticket via customer interface. I can see the ticket appear in
the Postmaster queue, the state is new, and it is not locked.
I lock the ticket in the zoom view, the ticket is still new, but locked.
Now, I wait a couple minutes and launch the UnlockTickets.pl script from the
command line :
--
# bin/UnlockTickets.pl --timeout
UnlockTickets.pl

Hi Brice, On Fri, Jan 30, 2004 at 01:45:15PM +0100, Brice Levy wrote:
I'm trying to have unlock timeouts working on the system but it won't. I've set up a 1 minute unlock timeout for Postmaster Queue (which receives all tickets). I create a new ticket via customer interface. I can see the ticket appear in the Postmaster queue, the state is new, and it is not locked. I lock the ticket in the zoom view, the ticket is still new, but locked. Now, I wait a couple minutes and launch the UnlockTickets.pl script from the command line : -- # bin/UnlockTickets.pl --timeout UnlockTickets.pl
- unlock tickets Copyright (c) 2002 Martin Edenhofer Unlock old tickets: -- The ticket is still locked. Same if I wait for the cronjob to do it. Using '--all' actually unlocks the ticket, though. What criteria must the ticket match to be unlocked with --timeout ? Did I miss something ?
Your setup sounds ok. Take a look on the UncountedUnlockTime config option [Kernel/Config/Defaults.pm] # UncountedUnlockTime # (don't count this hours as unlock time - weekdays: Mon,Tue,Wed,Thu,Fri,Sat,Sun;) $Self->{UncountedUnlockTime} = { Fri => [ 16,17,18,19,20,21,22,23 ], Sat => [ 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 ], Sun => [ 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 ], Mon => [ 0,1,2,3,4,5,6,7,8 ], }; [...] Maybe this is the problem. If not, http://bugs.otrs.org/. Thanks! :)
Thank you, Brice
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

Your setup sounds ok.
Take a look on the UncountedUnlockTime config option
I had left Default.pm untouched, and did not use UncountedUnlockTime in Kernal/Config.pm, so the values were the default ones. The test was done this morning, friday morning actually, so the unlocktime should have been counted. I pasted the defaults from Default.pm, only removing the whole friday line, and it worked ! If I add the friday line again, it does not work anymore.
Martin Edenhofer
Brice

On Fri, Jan 30, 2004 at 02:48:10PM +0100, Brice Levy wrote:
Your setup sounds ok.
Take a look on the UncountedUnlockTime config option
I had left Default.pm untouched, and did not use UncountedUnlockTime in Kernal/Config.pm, so the values were the default ones. The test was done this morning, friday morning actually, so the unlocktime should have been counted. I pasted the defaults from Default.pm, only removing the whole friday line, and it worked ! If I add the friday line again, it does not work anymore.
I noticed a similar problem with our unlocking, as we're not counting non-business hours on every day of the week (1900-0700). Adding in copious output statements, it seems there's a bug in bin/UnlockTickets.pl, where it doesn't properly count what hours fall within the UncountedUnlockTime. The following changes "appear" to work, but YMMV: change: elsif ($CountDay eq $ToDay && $Nh >= $_) { (about line 152) to: elsif ($CountDay eq $ToDay && $CountDay ne $LockDay && $Nh >= $_) { change: elsif ($CountDay eq $LockDay && $h <= $_) { (about line 155) to: elsif ($CountDay eq $LockDay && $CountDay ne $ToDay && $h <= $_) { and then add a final "else" to the end of the same block (156-157ish): else { if($h <= $_) { $UncountedUnlockTime = $UncountedUnlockTime+(60*60); } } This seems to properly account for the fact that there can be uncounted unlock times both at the beginning and the end of the day, AND will only pay attention to uncounted unlock times that are <= the current hour. Mike -- Michael A. Gurski (opt. [first].)[last]@pobox.com http://www.pobox.com/~[last] 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7 17 57 1E 4E 62 56 45 70 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB AD81 ADC9 E606 1166 213E 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042 7788 1DCE B5EE C0B4 F04B Views expressed by the host do not reflect the staff, management or sponsors.

On Fri, Jan 30, 2004 at 11:10:51AM -0500, Michael Gurski wrote:
This seems to properly account for the fact that there can be uncounted unlock times both at the beginning and the end of the day, AND will only pay attention to uncounted unlock times that are <= the current hour.
Forgot to mention this is in OTRS 1.1.3, but it looks like UnlockTickets.pl hasn't changed since then. -- Michael A. Gurski (opt. [first].)[last]@pobox.com http://www.pobox.com/~[last] 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7 17 57 1E 4E 62 56 45 70 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB AD81 ADC9 E606 1166 213E 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042 7788 1DCE B5EE C0B4 F04B Views expressed by the host do not reflect the staff, management or sponsors.

Hi, On Fri, Jan 30, 2004 at 11:10:51AM -0500, Michael Gurski wrote:
Take a look on the UncountedUnlockTime config option
I had left Default.pm untouched, and did not use UncountedUnlockTime in Kernal/Config.pm, so the values were the default ones. The test was done this morning, friday morning actually, so the unlocktime should have been counted. I pasted the defaults from Default.pm, only removing the whole friday line, and it worked ! If I add the friday line again, it does not work anymore.
I noticed a similar problem with our unlocking, as we're not counting non-business hours on every day of the week (1900-0700). Adding in copious output statements, it seems there's a bug in bin/UnlockTickets.pl, where it doesn't properly count what hours fall within the UncountedUnlockTime. The following changes "appear" to work, but YMMV:
change: elsif ($CountDay eq $ToDay && $Nh >= $_) { [...]
I reviewed bin/UnlockTickets.pl and I found the bug. Now it should work fine. Thanks for your help! :) Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
participants (3)
-
Brice Levy
-
Martin Edenhofer
-
Michael Gurski