Negative changes 6.14 -> 6.16

[Viktor Pracht]

The cookies are deleted on logout.

Deleting cookies

I meant having the login screen delete them. Thus, regardless of whether an upgrade has happened or not, the "old cookies" problem will be done with. If the user is seeing a login screen, then any cookie they have is old and should be removed.

So . . . we add a little cookie tester and deleter to the login screen javascript. (Easy to say . . . I don't do javascript anymore and wouldn't know where to start!)

[Martin Heiland]

The problem is, that most users don't know how and where to delete cookies (http://healthskills.files.wordpress....te-cookies.jpg) or clear a browsers cache.
This must happen automatically and only if a new version has been installed. Otherwise we would break the positive effects of mod_expires and so on. So the main obstacle is detecting GUI updates, which might be solved by some checksum matching on old vs. new files within javascript.

Greetings

Cookie expiration

I'm curious - why not just add a "delete the cookies" at the login screen loading? They've logged out, they obviously don't need any previous cookies when they log in again . . . .they'll get a new one upon login.

As for browser cache . . yeah, that's certainly an issue. META tags to the rescue!

[Viktor Pracht]

Deleting the cookies means the session will be lost and the user will have to log in again. If you don't mind that, just restart the groupware and all existing sessions become invalid automatically (ha! it was a feature and not a bug, after all ). I'd be surprised though, if deleting cookies solved a real problem and not merely worked aroud a side-effect of the other issues.

For the cache, that's a normal Apache configuration issue and not unique to OX. When you plan to upgrade, configure your mod_expire accordingly, e. g. like described in this thread. We plan to add detection of stale browser caches, but that will only detect, but not solve the problem; properly configuring mod_expire will.

You Rock!!

Martin, you rock!! Thanks a million. As you said, just removing that darned folder-json package fixed my issues, even ones I hadn't mentioned (like all the folders being in weird places).

As far as the cookies go, I could probably make a work-around to delete them until you guys issue an updated package. Time to go dust off the old "CGI howto" books . . . :-)

Again, thanks. Such an easy fix!

[Martin Heiland]

Please uninstall the experimental package "open-xchange-folder-json" and restart OX to solve issue 1 and 2. The folder name has not been changed, it's just another foldertree representation.
We're already planing on solving the browsercache issue, this is not an exclusive problem of OX 6.16.

Greetings

While it's been great seeing the response I got to some issues after we upgraded from 6.14 to 6.16, there are still some lingering issues I wanted to note. You folks feel free to tell me if I am full of crap, but here's what I am seeing:

1. Name changes in new mysql db: The "System Users" folder, which is a Public contacts folder which contains all the system users, has been renamed to "system-ldap". WTF?

2. The icon set in the upper left corner works fine, except that the E-Mail icon instantly brings up a "Unable to establish connection to email server" message and says the module has been disabled. It hasn't. Only recourse is to use the folder list below it to get into the INBOX.

3. I have had to tell all my users to MANUALLY delete their cache, AND their cookies. Leaving the old cookies results in the wrong SessionID in the XMLHttpRequests, which of course results in failure. Some users simply don't have a clue how to clean out those cookies and cache files. I strongly suggest that we add a cookie cleaner in the login screen (after a good login) before setting the new one.

These are made all the more difficult to troubleshoot by the fact that I can't really see the html that the browser is rendering, especially around that E-Mail icon. View Source is useless, and even Firebug isn't helping. (Browser is not sending an XMLHttpRequest when I click the icon, so I can't track that). I have spent hours and hours on this issue. I do this as a volunteer for my local church; it isn't my day job, so finding these hours to make this work for the church staff isn't easy!