I am stuck on implementing section access with data reduction.
Here is what I am using-
//Access with Reduction
Reduction is on the field DNAME.
I expect ADMIN to see all data, USER2 to see only data related to the value ‘HBEU’ and the USER1 to see all the data.
Everything works as expected except user USER1 has “Access denied”.
I tried below approaches as per https://community.qlik.com/t5/New-to-Qlik-Sense/Section-Access-with-reduction-issue/td-p/1582280
1. Tried * as Reduction but didn't work as the reduction field will not have all values.
2. When i try to give ADMIN rights it works for this scenario but if i give any random value in the Reduction field which is not present in the data set then it shows all the data without any restriction applied.
Any help on where I am going wrong? Any solution if using ADMIN rights but random values in the reduction field will restrict with no access .
Is this a real question? You copied most of Brip51's question, so it's hard to know what applies to your situation versus Brip51's. Like Brip51, you need to give USER1 a value in the REDUCTION1 field. Or is the reduction field DNAME?
This is exactly the same scenario as that of Brip51's that's why i have mentioned that link in my post. The Reduction field is Reduction1 in my case.
I tried the solution suggested , i cannot use '*' in the reduction field since i do not want any restriction to be applied for User1 and there may be chances that there will be limited values in my Reduction field.
If i use the second solution, with ADMIN if i provide any random value in my reduction field which is not present in my data then it does not restrict any data as per the role of ADMIN. But my requirement is , if there is any random value that does not matches with my data then i need to restrict the access.
I see what you mean. You can create a crosswalk from the reduction to the data:
In Section Access, make up a value for REDUCTION1 for User1, like 100.
In Section Application, create a table that lists all the values that User1 can have access to, in a key column, and the value 100 in another column named REDUCTION1. The key column must link to the rest of your data model, and in that way limits User1's access.
I think you could use * to assign an access to all available values - you need just to ensure that there are real values - NULL is no value else NOTHING (there is no possibility to link something to a NOT EXISTING matter).
If you checked your reduction-field - maybe with: if(len(trim(FIELD)) = 0, 'NULL', FIELD) - if it contained values and if not you set an own value - it should work.
Below is the actual data, there are two reduction fields:
1.If the USER_TYPE is GROUP , then no reduction needs to applied.Both the reduction fields will be null.
2.If the USER TYPE is REGIONAL, then he should be able to see the the REGIONS mentioned in REDUCTION1. REDUCTION2 will be null.
3.If the USER TYPE is SITE, then he should be able to see only the entities present in REDUCTION2, REDUCTION1 will be null in this case.
4. The priority of ACCESS is GROUP->REGIONAL->SITE. So even if there are multiple rows for USER1 , the row with USER_TYPE as GROUP will be considered and access will be provided accordingly
As per the suggested solution , I am replacing the nulls with the '*' in Reduction field.
It works for GROUP user, but the problem arises when the hightest level of access is REGIONAL or SITE.Consider below example:
Now, as per the logic for USER1, first the data will be reduced on the basis of REDUCTION1 but since we have provided * in REDUCTION2 it will also show the REGION of ENTITY 12.
So, suppose for ENTITY12 , the REGION is HBEU, then USER1 will be able to see both HBAP and HBEU Data.
Thanks @Lauri . It worked for the above dataset. But in my actual section data i have to provide access to more than 200 users, creating a table for all the users similar to user1 will be challenging.
Also, for some users the entries in the section data gets added but there is no associated data present in the data model, it gets added after sometime.Lets say a User entity is added in the section access table but no connected data is added.So we don't know which positions (primary key) needs to be mapped with that user.Thereby creating an association will not be possible . For section data , we are using a centralized table from other application so we cannot make any changes.
I think your approach won't work in this way. The reason for it is that always all access rules must be fulfilled - there is no "look at first to this and after it for this" inbuilt. But this doesn't mean that you couldn't apply an access-hierarchy whereby it's not very easy. For the howto see here: