Am Fr, den 07.05.2004 schrieb Robert Kehl um 16:52: Hi,

...

For example, I had an open ticket where I send the customer a reply yesterday at 15 o'clock, which changed the status of the ticket from open to "pending auto close+". An hour later, the customer send a reply.

9:35 hours later, the ticket became unlocked and I received an email with the subject "Lock Timeout!". The queue the ticket is in was set to 7000 minutes timeout for escalation time and 5000 minutes for unlock timeout.

Here are the last few lines of the history:

StateUpdate Old: 'open' New: 'pending auto close+' x dseifert (Daniel Seifert) 04.05.2004 15:00:18

SetPendingTime Set Pending Time to 2004/05/07 14:59. - dseifert (Daniel Seifert) 04.05.2004 15:00:18

FollowUp FollowUp for [2004042810000334]. x root@localhost (Admin OTRS) 04.05.2004 16:00:11

StateUpdate Old: 'pending auto close+' New: 'open' - root@localhost (Admin OTRS) 04.05.2004 16:00:11

Unlock Ticket unlock. - root@localhost (Admin OTRS) 05.05.2004 01:35:01

The previous reply from me had to wait 4.5 days (mail received on 29.04.2004 14:18:08, reply sent 04.05.2004 15:00:18), but during these 4.5 days the ticket did NOT unlock! Just this night, after less than 10 hours, it did.

Which were those 5000 hours, weren't they?

I don't think so. 5000 minutes is just 3.5 days, this wouldn't make sense as it waited 4.5 days before. It may be the 7000 minutes, this would fit (but this is the escalation timeout). Nonetheless it doesn't make sense that it gives a timeout at all. OTRS should calculate the timeout from the last email received, not from some random earlier one.

...

This happened regularly the last few weeks after I upgraded to 1.2.3, I didn't have this problem previously. No chances were made to any OTRS settings in this time (quite sure about that ;-))

Please let me know whether I should file this as a bug.

Still thinking about the bug/feature thing...

If I were to bet money on it, I would put it on bug ;-) -- Daniel Seifert

On Saturday, May 08, 2004 11:04 PM Robert Kehl wrote:

On Friday, May 07, 2004 9:33 PM Daniel Seifert wrote:

...

Am Fr, den 07.05.2004 schrieb Robert Kehl um 16:52:

...

...

The previous reply from me had to wait 4.5 days (mail received on 29.04.2004 14:18:08, reply sent 04.05.2004 15:00:18), but during these 4.5 days the ticket did NOT unlock! Just this night, after less than 10 hours, it did.

Which were those 5000 hours, weren't they?

I don't think so. 5000 minutes is just 3.5 days, this wouldn't make sense as it waited 4.5 days before. It may be the 7000 minutes, this would fit (but this is the escalation timeout).

Nonetheless it doesn't make sense that it gives a timeout at all. OTRS should calculate the timeout from the last email received, not from some random earlier one.

Ack. What we's need were the whole history of the offending ticket alongside its contents. May you forward a mitigated version to me via PM alongside any additional information that weren't suited for a public ML.

After reviewing the history you sent I must say I cannot draw a line between the lockout and neither 5000 nor 7000 hours. It's not obvious, why it gets unlocked. What happens at the time of unlocking, ie. which script runs at that time? It may well be a GenericAgent job unlocks the ticket, aside any automatic unlock time. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

On Sunday, May 09, 2004 10:38 PM Daniel Seifert wrote:

$ cat ~otrs/var/cron/unlock 35 * * * * $HOME/bin/UnlockTickets.pl --timeout >> /dev/null

This was set by the OTRS rpm default installation and the unlock time matches the cron-job run time.

So I guess it's a bug in UnlockTickets.pl

I don't. We forget the $Self->{UncountedUnlockTime}. Let's see: The ticket came in on 28st of April, 19:18:06, the owner is root. You became owner at 20:55:45. You and the customer then did something on the ticket, and you set it to 'pending auto close+' on 4th of May, 15:00:18, the pending time (doesn't really matter here) is set to 7th of May, 14:59. An hour later the customer sended another Followup, setting the ticket to state "Open". This is very important - the ticket won't have unlocked if no FollowUp had been received. The owner is changed back to 'root@localhost', what is probably undesirable. Now we're coming to the 5th of May, 01:35, one point in time the regular UnlockTickets.pl is run. Overlooking the code in UnlockTickets.pl, I see some calculations going on there dealing with the parameter $Self->{UncountedUnlockTime}. In short, the parameters holds the hours from Fri, 16:00 till Mon, 06:00 to not be counted as Unlock Time. Calculating back from the 5th of May, 01:35 5000 hours and taking the above into account, I believe you land up somewhere near the ticket create time. Can you confirm this? Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

On Monday, May 10, 2004 10:49 AM Daniel Seifert wrote:

...

An hour later the customer sended another Followup, setting the ticket to state "Open". This is very important - the ticket won't have unlocked if no FollowUp had been received. The owner is changed back to 'root@localhost', what is probably undesirable.

I don't see where the owner is changed back to root?

04/05/2004 16:00:11

...

Now we're coming to the 5th of May, 01:35, one point in time the regular UnlockTickets.pl is run. Overlooking the code in UnlockTickets.pl, I see some calculations going on there dealing with the parameter $Self->{UncountedUnlockTime}. In short, the parameters holds the hours from Fri, 16:00 till Mon, 06:00 to not be counted as Unlock Time.

In 1.1.3 we set the timeout so high as we did not want it to unlock during the weekend (which it did in version 1.1.3). While I think it is a good idea to not count Sat+Sun, why do you keep out Fri 16-24:00 and Mo 0-6:00? This would mean you have to not count all the other nights as well ;)

Ask Martin ;) The time span is configurable in Config.pm. This is the default from Defaults.pm - adapt to suit your needs: # 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 ], };

...

Calculating back from the 5th of May, 01:35 5000 hours and taking the

5000 minutes.

Yep. *g*

...

above into account, I believe you land up somewhere near the ticket create time. Can you confirm this?

It comes pretty close. Yet it means that OTRS is counting the complete time the ticket is locked && unanswered, even though the last reply has just come in a few hours ago.

Now it comes to the owner change. At the time the lockout was calculated, the owner was root@localhost, who owned the ticket right at the beginning of the ticket's life spawn. Therefore, the system could have had decided that 'root@localhost' has been a lazy one throughout the whole time, by not having looked at anything that had happened to the ticket in the meantime. The owner change may be undesirable, but has to take place because a FollowUp is to be taken as an action performed on the ticket. So, this is not the failure itself, but maybe it's cause.

So UnlockTickets.pl may be working according to specificiation, but I think the specification has a flaw :-)

Not the spec, but some piece of code probably, or your configuration. Can you please compare the rights of 'root@localhost' and 'dseifert'? Additionally: Who is the Postmaster, I bet 'root@localhost'? May you please switch on the FollowUp-Notification and try to reproduce the ticket? I'm wondering wether you'd get a notification or not. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388 -- Tolle Verkleidung hast Du da. DANKE. Terry Pratchett

On Monday, May 10, 2004 2:04 PM Daniel Seifert wrote:

...

Hi,

...

Am Mo, den 10.05.2004 schrieb Robert Kehl um 13:28:

...

...

have unlocked if no FollowUp had been received. The owner is changed back to 'root@localhost', what is probably undesirable.

I don't see where the owner is changed back to root?

04/05/2004 16:00:11

It doesn't say "Owner changed to root", it just says that the user 'root' has changed the ticket state. But the ticket still belongs to me. Iit does this whenever a follow-up is received, as the follow-up is sorted in by the system, not by me manually :) I don't think this is a configuration issue on my side.

That's what it's ought to be, good.

...

No, it wasn't, it was in my queue. Otherwise it wouldn't have been me receiving the ticket timeout, but root, would it?

Point.

...

...

Can you please compare the rights of 'root@localhost' and 'dseifert'?

How do I do this?

http://localhost/otrs/index.pl?Action=AdminUserGroup

...

...

Additionally: Who is the Postmaster, I bet 'root@localhost'?

Postmaster on the Linux box?

No, the OTRS PostMaster. $Self->{PostmasterUserID} - if not set, it defaults to 1, which were 'root@localhost'. Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388

Hi Bastien, On Mon, May 10, 2004 at 04:26:41PM +0200, Support Technique wrote:

Can we enable several smtp server depending on the queue for example. I can have several emails and several different domains for receiving in different queues, but they all got sent to the same smtp, how can I get around that? (With out rewriting all the send module)

There is no other way. (Kernel/System/Email/SMTP.pm)

-- Bastien support@ritme.com

Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!

Am Mo, den 10.05.2004 schrieb Robert Kehl um 15:22: Hi,

...

...

...

Can you please compare the rights of 'root@localhost' and 'dseifert'?

How do I do this?

http://localhost/otrs/index.pl?Action=AdminUserGroup

Both dseifert and root have full rights for groups admin, stats and users. I also have some other groups (dseifert, management, software) where dseifert has full rights and root has none. Neither root nor me have any rights for group faq

...

...

...

Additionally: Who is the Postmaster, I bet 'root@localhost'?

Postmaster on the Linux box?

No, the OTRS PostMaster. $Self->{PostmasterUserID} - if not set, it defaults to 1, which were 'root@localhost'.

It is set to 1 in Defaults.pm. -- Daniel Seifert

On Friday, May 14, 2004 7:57 AM Daniel Seifert wrote:

Here's another example on how useless the current timeout is:

Thank you, but I believe, we got it beforehand. The Timeout is chosen unluckily, as it is an absolute measurement. The idea of changing it is noted. Regards, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388