Just putting here links of what I read:
https://community.qlik.com/t5/Qlik-Design-Blog/Data-Reduction-Using-Multiple-Fields/ba-p/1474917
https://community.qlik.com/t5/Qlik-Design-Blog/Basics-for-complex-authorization/ba-p/1465872
https://community.qlik.com/t5/QlikView-App-Development/Section-Access-with-Multiple-fields/m-p/48932...
All of the articles above do not apply to my use case.
I do have multiple records for a single user (user can view multiple countries) but all the other columns are not linked to country.
All of my section access reduction fields (columns) should be simply translated to
(SECTIONCOL1Val1 OR SECTIONCOL1Val2 ... OR SECTIONCOL1ValN) AND (SECTIONCOL2Val1 OR ... OR SECTIONCOL2ValM) AND (SECTIONCOL3Val1 OR ... OR SECTIONCOL3ValX)
.
The issue I'm having is that STAR IS * is not registering for more than 2 columns. So it works for 2 columns but when 3 it does not. I have an ADMIN user that has all star "*" values for all 3 columns but the third column does not register as "*".
My section access table contains all possible values that will appear in the data, so that is not a problem.
Also, I tried avoiding the STAR IS * and just added 3 different tables (SECTIONCOL1, ANY_INDICATOR) with values for each reduction fields. If ANY_INDICATOR then all values are selected. This should be massively fast because of no synthetic key, no concatenated key. But this results in a cycle and all of the tables in the model get loosely linked which slows down the app massively (when section access is enabled then cycle/loosely linked message is silenced but that does not mean that the cycle is eliminated because the app is still slow).
I also tried removing STAR * completely and listing all the keys for ADMIN but it does not work with third column.
How is it a cycle? Simple, one global table X with users and their access selects 3 small tables that filter the FACTS table. But then the filtering through small table A can affect the global table X (by silly Qlik dependency analysis, dependency is obviously directed in one direction towards the FACTS table, selections in FACTS will never filter the Section access table) which can then have an effect on another small table B that again filters the FACTS and this is a cycle.
Making a single column with concatenation is out of the question. It slows the app ridiculously.
