Fri, 10 Apr 2026 17:52:44 +0000 https://bugs.horde.org/ticket/3660 Mailbox not changed in session This is one of the bug reports I hate personally, but I can't tell you more than that /sometimes/ changing the folder is not persistant. Whether I switch to a folder with the drop down box or through ono of the trees doesn't matter. I get to the correct mailbox, but the new mailbox doesn't seem to be saved in the session. Any following action is done in the context of the old mailbox, reading messages, refreshing the mailbox view, etc. Of course this is not reproducable, but once that happens, I can only get IMP to stay in the new mailbox if go to a different folder first. Mon, 20 Mar 2006 08:37:33 +0000 https://bugs.horde.org/ticket/3660#t17962 FWIW, I have never seen this behavior. Maybe a session-handler related issue? (I am using file-based sessions) Tue, 21 Mar 2006 04:49:12 +0000 https://bugs.horde.org/ticket/3660#t17983 Ah, that's a good hint. I had indeed mysql sessions turned on in HEAD to test the login/logout issue. Tue, 21 Mar 2006 09:29:55 +0000 https://bugs.horde.org/ticket/3660#t17990 > Ah, that's a good hint. I had indeed mysql sessions turned on in HEAD > to test the login/logout issue. My guess is you are switching mailboxes in your main frame while the sidebar is reloading so the mailbox change is not being set in the session properly. This sounds like it is a duplicate of our previous SQL concurrent sessions ticket. Wed, 22 Mar 2006 21:47:03 +0000 https://bugs.horde.org/ticket/3660#t18038 Sorry, I forgot to close this ticket. This has been fixed by my changes to the mysql session handler. This only works if using a mysql engine that supports row level locking like InnoDB. What do people think, does this justify an sql upgrade script? Or should we even consider table level locking if people are not using InnoDB? I guess that's a bad idea for a session table. Wed, 22 Mar 2006 23:22:28 +0000 https://bugs.horde.org/ticket/3660#t18041 > What do people think, does this justify an sql upgrade script? Or > should we even consider table level locking if people are not using > InnoDB? I guess that's a bad idea for a session table. Yes... but perhaps it'd be better to default to slow and safe instead of faster but buggy... Thu, 23 Mar 2006 02:52:46 +0000 https://bugs.horde.org/ticket/3660#t18042