Well, the blank limitation field is only there to allow Access=ADMIN users to see everything when opening a document in QV Desktop.
You can try a single SA entry with Access=ADMIN and the required limitation value. Upon reloading the document on the server, all data will still be stored by the batch reload engine because data reduction is only performed upon opening the document, and the document is open before the reload kicks out all remaining data.
But with this account you will never be able to inspect all data ever again.
thank you for your suggestions, but I am afraid to tell that nothing leads to the desired result.
As soon as I mention the Service Account User a second time in the Secion Application part (regardless of BLANK or '*' in the Limitation field), the Application won't open on accesspoint again. So I have to exclude this Service account User in the Section Application Part with the "where" condition. Then every User is limited correctly except for the Service Account (can't open).
What you are trying to do you will not be able to.
If you use the blank, to reload the document it will not allow the service account to login, because in theory he has no data assign to him and so will be denied.
You can try using *, but there are issues with this also. Star needs all data that has been assigned. So, if you have North, South, East and West and you only assign North, South and East then the reload will only pull that data.
You should never use the service account to access the QVW, other than reloading the data.
Allow me to disagree.
As long as the service account is of Access=ADMIN, there will not be a reduced reload, only a reduced AP View.
See documents in attachment. The QVW has section access with reduction on Region = North,South,East,West. USERIDs are all ADMINs:
USERID A (password A) sees North South East West
USERID B (password B) has data reduction to North South
USERID C (password C) has data reduction to East West.
If I let the QlikView Server perform reloads with Section Access user = B, then user A will still be able to view all regions in the AP, while user B (the reload account) will only have access to North and South.
But of course I'm not making use of this asterisk trick.
There are ways to get around this for sure, but best practice is to load section access before data is loaded. When you do the this "A" user becomes the "Service Account" and will load all the data and then the reduction will be applied to the other users.
LOAD * INLINE [
ACCESS, USERID, PASSWORD, REGION
ADMIN, ADMIN, ADMIN,
USER, USER1, U1, AFRICA
USER, USER2, U2, AMERICA
USER, USER3, U3, ASIA
USER, USER4, U4, EUROPE
USER, USER5, U4, AMERICA
USER, USER5, U5, *
LOAD * INLINE [
In this example a reduction field has been added called REGION. The purpose is to
limit the USERS to their sales region profits.
USER1 will only be able to see the profits for AFRICA, USER2 the profits for AMERICA
and USER3 will only see the profits for the ASIA region.
USER4 will be able to see the profits for EUROPE and AMERICA.
USER5 will be able to see all regions listed in the reduction field REGION except for
Even if USER5 has “*“ for the REGION reduction field, star means “all listed values”
not all values for the field. Since no USER has OCEANIA listed for the REGION field,
USER5 will not have access to the values for OCEANIA.
If we want USER5 to see OCEANIA as well, we need to add an extra line in our section
USER, USER5, U5, OCEANIA
SA.qvw 148.0 K
while I do agree with you that the asterisk in Section Access is not always what you want it to be, I think this "best practice" is only applicable if the document developer has a perfect idea about what ALL-AND-EVERYTHING really means. After developing multiple security solutions in QlikView, I gradually came to believe that loading section access after everything else is a way better approach, mainly for three reasons:
- Loading section access data from an external database makes the set of values highly unpredictable, in a sense that both the LINK values in the Section Access table, the LINK fields in the Facts/Dimension tables and any intermediate grouping tables tend to be unknown to the QlikView script.
- Link values may be very dynamic, in that the data source dictates what will be visible to whom, including the value of "whom"
- In most cases that I met, Link fields have to account for multiple reduction fields. That means that again the single asterisk won't do much good and that the developer is on his own to expand something like *|*|* in all possible combinations of all values in three different fields. How do you do this when section access is at the front of everything else?
Aside from all cons that can be brought up against this approach, in this thread the example with the SA at the end clearly did solve the case of not being allowed to assign a reduction value to the Reload ADMIN account.
Thanks for your feedback.
thank you for your Post.
I know how challanging it can be when it comes to more complex security mecanisms.
For those who face this challenge the first time this document might be helpful.(attached).
It shoud exactly cover your mention when it comes to applying data-security on more than just one field ( f.e. 3 fields)
But this 'bridge-table approach' can be applied after the section Access part.
your document doesn't cover the security requirements I often face. To most (enterprise) qlikview users, security has to be managed externally and in its entirety. They don't like being forced to change a QlikView script each time a new GROUPx is created.
Moreover, in many cases (except in QV-based product development where they are a necessary evil) hidden scripts are seen as a feature to-be-avoided. Again security should be external to QV and shouldn't harass developers or hamper development workflows.
I think there is no generic solution for managing data/document security in QlikView. It may be highly situation-dependent. I do apologize if my remarks are of no use to you or this discussion. They're just the results of my personal experiences (and frustrations).