For 2nd point (When selecting "Remove last document state" from the AccessPoint this session doesn't remove from memory and the document retains your selections when you go back into it)
I think you have to change the timed out settings on the IIS Server or Web Server.
Can you please navigate to the mentioned path and change the timeout settings accordingly with respect to your project.
Thanks & Regards
This issue was reported to Qlik Support in the past as a potential defect and the issue was referred to Qlik R&D. The below is a statement from RD regarding the changed functionality of Remove Last Document from the v11.20 track to the 12/12.10 track:
When Removing Last Document State on a document from Accesspoint, any selections user made in the previous session, should be removed when the user accesses the document again.
When Removing Last Document State on a document from Accesspoint, the selections the user made in the previous session are still present when accessing the document the next time.
The reason for this behavior:
When you go from the document to the AccessPoint, without closing the session, no session recovery information is saved. So there is no document state to remove from the shared file when "Remove last document state" is pushed.. What happened in SR13 was that the old session was closed (without saving the state) and therefore a new one was started when we went back to the document. In later versions, we go back to the open session when we go into the document again. The change is an intentional consequence of the fix for a previously reported bug. Before that fix, the webserver always started a new session and did not correctly detect that the user already had an ongoing session on that document. (Using the back arrow does not close the session) To get the behavior that the customer is asking for, they have to push the close-button in the upper right corner before using the back arrow. So when you just use the back arrow, there exists no "Last document state". Thus, pushing the button does not do anything. (If you try pushing the close-button before the back arrow, you can notice a different behavior by removing the "Last document state" or not)
Hopefully this information is what you are looking for.
Of course, while this sounds perfectly logical from a software design point-of-view, most users still get the impression that "it simply doesn't work". Moreover, the design and nature of www connections make the situation only more bewildering as there is no real "connection" concept during communications between a QlikView Server and a QlikView Client. Whenever a QlikView AccessPoint visitor closes the browser without pressing that famous small icon in the top right corner, everything on the client-side disappears without the QlikView Server having a clue about what is going on. The QlikView Server still thinks that a user session is active, and as long as the session timeout hasn't been exceeded, the session will stay alive.
There is no real escape from this situation (Server doesn't know that the client has disappeared, and the Client doesn't know that his/her session is still active), or is there?
Fortunately, there may be one. A long time ago, one of the bright Qlik minds devised a QlikView extension specifically targetted at handling this pseado-deadlock. The extension installs but shows no visible parts, and the only useful thing it attempts is to close the current session with the QlikView Server whenever the running browser gets a message to close down.
Only one thing: as it is quite old, I'm not entirely sure that it still works with QV 12.xx. Please post back if you get good results. Thanks