...

We're implementing a new Intranet and in the spec it requires web-based applications to run within a framed environment whenever possible. Basically all our tools are in a list framed on the left and when clicked they load in a frame on the right.

I've been able to get OTRS to load in the frame and all was fine until today. It appears that anytime we click a message in the message thread view (something historical), OTRS logs us out. This only occurs on those links and the rest of the app runs fine in the frames.

Take OTRS out of the frame and the message history links behave as they should.

I tryed to reproduce it. I created an frame html page ... and OTRS works fine in this frame (zoom, message threads, historry, ...).

If you can reproduce it, create an bug report on http:/bugs.otrs.org/ with your html frame page to repeoduce the error.

One more thing. Our intranet is mixed. The left frame and frameset comes from one machine/ip while otrs comes from another. Not sure if that mixed ip deal is doing something to the session cookies or not.<

Found the link issue, but also know now what's going on. It's a security setting in IE. When OTRS is loaded from a frameset on another server it is considered a third party application, the security system kicks in and rejects the cookie... then otrs is forced to use the Session parameter. When this occurs, the Agent Zoom links for the message thread are broken because the Session is appended after the anchor, not before. So looks like a bug with the url after cookies are rejected. Can probably reproduce without frames by disabling cookies then browsing a message base.