Hi Jim, On Thu, Jun 19, 2003 at 09:19:50AM +0100, Jim Wight wrote:
Yesterday, I spent a long time composing a customer reply, only to lose it all when I finally clicked Submit. It seems that my session had expired while I was composing the message. When I clicked Submit, I was returned to the login screen, and there was no trace of the message in the ticket or of having been sent.
I suppose I have two options to prevent it happening again: increase SessionMaxTime in Config.pm sufficiently such that if an agent doesn't log out at the end of the day expiry will happen harmlessly during the night, or not bother running var/cron/session.
No, SessionMaxTime in Config.pm will set the session timeout. And var/cron/session will just remove old sessions (with session timeout) from the RAM/DB/FS.
Incidentally, why is SessionMaxTime expressed in seconds, when other timeouts, e.g. queue unlock and queue escalation, are expressed in minutes? Seconds seems unnecessarily fine-grained for the purpose. In fact, I would have thought hours would be perfectly adequate.
It's easy, do it by adding the following to Kernel/Config.pm for 24 h session timeout. $Self->{SessionMaxTime} = 60*60*24;
There doesn't seem to be the possibility of having unlimited-length sessions (why do sessions have to be limited in length, anyway?) except by giving SessionMaxTime a very large value. What is the maximum it can have? Couldn't a value of 0 be used for the purpose, in the same way that 0 means "no unlock" and "no escalation" for queues?
Because of security reasons. At the moment the max session time out is 24h. Anyway, we could add the 0 config option for no timeout (if _really_ needed!).
Jim
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- nohl: 12:34am up 126 days, 9:59, 7 users, load average: 0.13, 0.38, 0.39