topic Re: Saving User preference in Integration, Extension & APIs

Saving User preference

Anonymous — Wed, 26 Aug 2015 10:47:28 GMT

Hi,

I am trying to create a table having multiple columns and allow user to choose columns to views. For e.g there could be 10 dimensions added in a table but user wants to see only 5 of them , then they should be able to choose 5 out of 10. At the same time we want that to be persisted. So if the same user logs in again he should only see those 5 column he selected earlier similarly every users can have their own selection persisted.

How can I achieve this in qlik sense ?

Re: Saving User preference

Alexander_Thor — Thu, 27 Aug 2015 16:17:01 GMT

Either you have an external store that you store this into, i.e not Qlik related so pick whatever you are comfortable with.

Or you could store it as a full dynamic property on the object, this however is not something I would recommend as the users would have to have full edit rights on the objects so you will have to edit quite a lot of the default security rules to allow users to persist changes to a published object.

Re: Saving User preference

konrad_mattheis — Fri, 28 Aug 2015 06:18:57 GMT

Please think of to add a seperate area for third party extension. I don't like the approach that every third party extension has to install an own external storage.

If you like to be a plattform, delivery also a possibility to add own storage to the repository. In SAP like Z Tables, in Navision Tables with a special number,...

So we need own repository extensions to save own stuff.

Re: Saving User preference

konrad_mattheis — Fri, 28 Aug 2015 06:20:33 GMT

Even if this is not the best aproach, save it in a Variable, Hidden Bookmark (users can also save bookmarks with standard security rules in published apps),...

Re: Saving User preference

Alexander_Thor — Fri, 28 Aug 2015 08:57:41 GMT

Hmm, no I agree that is not a good approach.

To avoid merge/save conflicts you would have to create 1 variable per user which is pretty horrible as variables will be available in the UI in 2.1

You should never use GenericBookmark for anything besides bookmarks and snapshots as it would blow up your app down the line.

Instead add a normal GenericObject with your own custom type and manage settings in there. Preferably 1 per user to avoid conflicts during app sync between nodes. Adding properties as children or on the object itself creates an area for conflicts if two users are editing during the same saveappobjects cycle.

Now all of this is very overkill just to manage user preferences, I would probably just opt for the browsers local storage if you don't need it to persist between devices.

Sent from my Windows Phone

Re: Saving User preference

Anonymous — Fri, 28 Aug 2015 10:26:07 GMT

I was trying to store the preference outside qlik. But if I create an extension how can I get external storage access while painting the extension.

Re: Saving User preference

Alexander_Thor — Fri, 28 Aug 2015 12:55:24 GMT

If your storage has a web accessible endpoint you would just do a XHR request to it, you could use jQuery to simplify things a little bit https://api.jquery.com/jquery.get/https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage

Another way could be to use local storage, it will then be saved to the user's browser but that might be good enough Window.localStorage - Web API Interfaces | MDN

Re: Saving User preference

konrad_mattheis — Fri, 28 Aug 2015 13:31:25 GMT

I understand that the bookmark is not the best aproach. But was is the real problem behind, if a users saves the own properties there. Yes for each save the bookmark is updated and the current selections are saved, but this is just overwriten. And for each user there is only 1 bookmark.

bye

Konrad

Re: Saving User preference

Alexander_Thor — Fri, 28 Aug 2015 13:45:26 GMT

Well you are free to whatever you want to do I'm just very very strongly discouraging anyone thinking about doing something like that as it can have severe performance implications on your app and on your system.

A bookmark will save every distinct field value and it's selections, so if you have a few selections in a few different fields then add 500 users to that and you quite possibly just grew your application size by 500mb.

As opposed to just using normal GenericObjects which would clock in somewhere around 500kb.

Just because you can does not mean you should.

Re: Saving User preference

Alexander_Thor — Fri, 28 Aug 2015 13:50:53 GMT

There are ways of saving data, it's called GenericObjects. You are free to create your own if you wish.

We are actively trying to avoid hitting the QRS which for a single screen/entity system like Navision or R3 make sense. But for a high performance and click intensive system like Qlik you do not want to query disk/perform IO if you can avoid it. You have a in-memory storage option available, why not use it?

Re: Saving User preference

Stefan_Walther — Mon, 31 Aug 2015 09:59:26 GMT

Having some kind of a data-storage for extensions/mashups, etc.: ... that's definitely something we are looking into ...

In the meantime I highly recommend to think of one of the following options:

- For local storage: use the local storage (as akl‌ recommends below)
- If you need a data-storage across all users, create your own or just just something like Firebase which is easy to set up, also for other people using your extension.

Regards

Stefan