I'm not sure I follow. You say "In QV11 if section access is used in the load script, but disabled in the document properties the application will fail to open in Access Point, and any user attempting to access it will receive an error."
First, section access cannot be disabled in the Document properties. If Section Access is present in your script, Section Access will be enabled at all times. It may not work as expected though. For example by entering redundant data in your SA table that allows everyone in.
Second, do you really mean to say in your above sentence that if you disable section access in the document properties, no one can get in anymore (even those people listed in your SA table)? We do use Section Access all the time in this way in QV11 and without Data reduction or strict exclusion... Just to have a flexible and dynamic way of automatically assigning document CALs.
I must have misunderstood something...
Peter – thanks for the reply. I don’t think you misunderstood anything – let me try to clarify. When I referred to “disabling section access in the document properties” I did mean simply unchecking the “Initial Data Reduction Based on Section Access” option in the document properties. In our old environment, in QV11 SR2, when section access was utilized in the load script, but a developer inadvertently unchecked the “Initial Data Reduction Based on Section Access” option in the document properties and the application was promoted into production – the result was that the application could not be opened by anyone. Neither by individuals who had security in the section access security table, nor by individuals who didn’t. The application did refresh successfully, however, so the system account running QVDS was able to access the document without issue. This situation only happened twice in 10 years, but it was a nice security feature for us. If the developer made a mistake, and our promotions reviews and support team didn’t catch it – QlikView would “shut down” the application so no one could use it (instead of removing the row-level security and causing a larger issue for us). After a recent upgrade to QV12 this scenario occurred, and instead of QV “locking out” all users in AccessPoint, it actually removed row-level security for those in the security table (which technically should be the expected behavior by unchecking “Initial Data Reduction Based on Section Access”).
So, I would like to discuss this with others. Do any of you agree/disagree with my observation? Was there a documented enhancement somewhere between QV11 SR2 and QV12.10 SR6 that changed this behavior? Is there a different cause for what I observed in QV11 or in QV12 that might account for this? Is there something that I am overlooking?
Peter – I’m interested to hear more about your scenario. It appears that you are saying the opposite of me with QV11 – that you intentionally use section access security in the load script while disabling the “Initial Data Reduction Based on Section Access” option and it works differently than what I am describing. What version of QV11 are you running? I do like your comment about the security table containing redundant data which could be counteracting my security. I didn’t conduct the review of the application in question, so I don’t know if such a problem was present in the table (I suspect not however, as one would think such an error would be noticeable and quickly detected). Honestly, my first thought was this was an enhancement made by Qlik. Although I liked the behavior I described in QV11, I have to admit the behavior I described in QV12 seems much more logical.
Peter – reading your dynamic document CAL assignment scenario, do you then configure the section access security table to grant access to all rows of data to any user found in the security table? What version of QV11 do you run? Perhaps our disagreement stems from different releases of 11?