Shared user created bookmarks disappear on Access Point after document reload for the person shared with

[Maccyd]

Hello,

I am looking for some help with an issue with have with our QlikView shared bookmarks on Access Point for.  When we reload a document from Management Console the shared bookmark disappears for the person it was shared with, but when the creator of the bookmark goes back into the document on Access Point it will then re-appear.

Here is the scenario we tested:

User1 creates a bookmark on the Access Point and shares this with only User2.

User2 can see the bookmark in More-Repository-Items Shared With Me (drop down)-Bookmarks.

When we reload document in Management Console User2 can no longer see the bookmark.

User1 simply opens the document on the Access Point and now User2 can see the shared bookmark again.

So the bookmark still exists that User1 created but it is almost as if Access Point ‘forgets’ it is a shared bookmark after reload until User1 goes back into the document on Access Point and it seems to reinitialise the shared bookmark.

Has anyone experienced anything similar or has any idea why this is happening?

If you need any further information let me know!

Thank you for your help.

Adam

[Daniele_Purrone]

Hi @Maccyd, that should not happen, of course.
I remember seeing this in the past on a couple of occasions when server objects were stored on a .Shared file. Can you check if you are using a .Shared or .Tshared file for that specific document? If it's .shared, please convert it to .tshared.

If it's already a .thsared file, I'd say that you'd need to see if this behaviour happens also in other scenarios. For instance, create a few test shared bookmarks form other users, and see if the behaviour is the same.

It'd be also interesting to know which version of QlikView server you are using.

And in which client does the issue happen? AJAX or Plugin?

[Maccyd]

Thank you @Daniele_Purrone for getting back to me.

I am going to liase with our IT team as I do not have visability of the area where the .shared file is saved.  I will get back to you to confirm if this works.

Looking in management console it looks like the server is using : 12.40.20100.0

We are using AJAX to access reports.

Thanks,

Adam

[Maccyd]

Hi @Daniele_Purrone 

My bad, turns out i did have access to the area where the shared files are saved.  The document with the issue has a .tshared file.

I have got a handful of users to create bookmarks across different documents and the same thing happens each time, whether they are .shared or .tshared.  I even created a brand new document to test and the same thing still happened.

Do you have any ideas of anything else I can check or try?  Could it be a tick box I am missing on the documents or management console?  I've looked in every section I can see and haven't come across anything that I think would make a difference!

Thanks,

Adam

[marcus_sommer · Accepted solution]

Does it also happens if the applications isn't reloaded per qmc else with the desktop client?

Another point to check could be the shared-file itself - means saving it separately at several stages: before and after the bookmark creation, after the document and session closing, after the qmc reload, after opening the app from the other users and after the creation users opened it again. Does the file really change? When - what changed?

Further things which might be related to the issue:

• session recovery enabled?
• session collaboration enable?
• server objects enabled within qmc and document properties generally enabled or restricted to some object-types and users?
• the refresh settings within the document properties?
• allow only one document in memory enabled?
• any section access within the application?
• authentication method and licence-type

I don't know if and how such settings could impact the issue but I wouldn't be surprised if there are any dependencies ...

- Marcus

[Maccyd]

Hi @marcus_sommer ,

Thanks for the help!

'Allow Only One Copy of Document in Memory' was ticked, when i unticked this and tested it then worked, I have kept track over the last few weeks and it seems to be working fine with no adverse effects to the server.

Thank you,

Adam.