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.
Thanks Marcus. The only issue with this is I have had to specify available data for both users and admin. As I understand it, when accessing through Access Point everyone is treated as a user. Therefore if you try and specify unlimited data access (*) in Section Access if doesn't let you see the data via Access Point.
However when accessing on the qlikview server directly I have access to all data so I'm still not sure why it locks everyone out (including myself) from access point if I fail to refresh after making a change. Like Peter suggested though, it seems as if a data refresh as a final stage of a change seems to be the only 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 ...
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
TestSectionAccess_2.qvw 168.5 K
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.
I played a bit with your doc, this is what I got with strict exclusion enabled
- Stefan: open, reload, change layout and save
- Peter: open in another qv.exe; in image the 2. qv.exe, Stefan left, Peter right
- Stefan: change layout and save
- Peter: reopen in another qv.exe
Stefan: reopen, only A !!!
Peter: reopen (close qv, reopen, insert user and pwd) access denied
Stefan: reload and save (3 values in Dim1)
Peter: reopen --> ok
From what I understand it seems that Peter can access the .qvw depending on the values saved in the reduction field; only A -- no access.
Also when I changed Peter to ADMIN, I didn't get access denied.