We have a Section Access security model that works perfectly through Access Point for all our users. However, when a developer makes a change to a Qlikview Dashboard on the Qlikview Server without refreshing the data, all users are locked out of accessing the document on Access Point. To resolve we have to manually refresh the Dashboard and save without making any further changes.
The document change can be something as small as making a minor cosmetic change.
Has anyone else experienced this?
We're using version 11.20.12852.0 SR11
Solved! Go to Solution.
Yes on the access point each user has only user-rights. But to use the asterisk wildcard didn't mean to give an unlimited access to all data else only for those data which have a valid link-value but not to NULL.
For example: If you restrict your datamodel on a field region and only one location which should have any belonging to a region hasn't one (maybe a new one which is in any state of planning) then NULL occured and this won't be caught be the wildcard and it happend a data-reducing by opening with the already mentioned effects. Therefore you would need a NULL handling which excludes those NULL or replaced it with a dummy-value like 'NULL' or 'EMPTY'. A very good indicator of if a data-reduction has take place is when a save-us dialog appeared if you tried to save the application without reload.
If you work in a bigger environment have a look on the suggestion from Peter. If not it's just a matter of getting used to reload always an application if anything was changed. After the first few times it happen quite rarely ...
A developer opening a document with section access and Data Reduction will reduce the section access table as well. Saving this document as new version will create a document with all other users thrown out (SA resides in the same datamodel, it's just invisible)
Let Developers work on an unsecured document, apply section access as the very last step when publushing, and always reload before making a document available in the AP. You never know what the developer put in as data.
Avoiding data reduction on the developer-side should also work. This meant, has the developer full access to all datas which most often required a NULL handling respectively routines which replace missing or unknown links between the section access and the section application area no reduction takes place and therefore an out-lock of any access point users will be prevented.
I think a developer with access to all data (*, all listed values) can change the layout and without reload (or reload of prod data) the document on the server can be replaced. What do you think about pcammaert ?
Also agree that the Peter's solutions (publisher and/or developer with unsecured .qvw + section access at the end)
ares the best options.
Massimo, my guess is that a developer with access to all data will keep all data in the document but will still reduce the SA table to his/her own ID. I don't know for sure, never tested it.
In a server environment, we (almost) always work with a staged workflow where either security is delayed to the last phase or reloads are performed immediately after promotion to the next stage (DEV->ACC->PRD).
IMHO a final reload in the final environment is the safest choice.
Peter, I don't think that the SA table itself will be reduced.
Have a look at attached file, there are two users Stefan and Peter (password same as user id).
I've openend with Stefan and the DIM1 value got reduced to A.
Saved the QVW.
I am still able to open with Peter, but not with Mary or someone not listed in SA table.
Note that I disabled strict exclusion (which I think could be the reason why the OP users are locked out).
Besides this technical discussion, I agree with what you suggested
the truth hides in the details. I did exactly the same test before my first post, but in my case strict exclusion is always on when I enable "Data Reduction based on...". So you're probably right (as usual).
But then, does a document that only exhibits data reduction for users that have valid link values, and shows all data to all remaining SA users really belong on a company server? I think that whenever Data Reduction is enabled, strict exclusion should be implied.
Of course the last statement isn't really true (I haven't had any case to the contrary in the last 8yrs though), but as far as Section Access and Data reduction are used as part of a security set-up, I agree that it is a technicality.
Anyway, thanks for posting this correction. I hope Mark finds our little discourse useful.
On second thoughts, you stated that the SA table isn't reduced but the data is, leaving nothing for the next user to link to. If there is data overlap between the two, this wouldn't hold either. Interesting case. Let's figure it out....
I didn't want to imply that strict exclusion should be turned off.
I just commented on the pure technical aspect of data reduction reducing SA table itself or not.
After all, this discussion probably won't help Mark, but I think your other recommendations should have.