Section Access - Access is denied

[tmumaw]

Good morning everyone,

I'm new to Section Access and have watched/read everything I can find.  I have made a section access table which looks like this.

Access = USER  USERID=DAVEY\JACKP  NODE1=  NODE2=  NODE3=R172000000 NODE4= NODE5= NODE6= NODE7= NODE8= NODE9= SAPROFITCENTER=

When I have a SAPROFITCENTER value it works perfect, however when I only have a NODE value the user gets access is denied.  By having a value in NODE3 he should be able to see all SAPROFITCENTERS.  Here is my section access and part of my script.  Thanks

Section Access;
LOAD
"ACCESS",
"USERID",
SAPROFITCENTER,
QVF_ID,
Upper(NODE1) as NODE1,
Upper(NODE2) as NODE2,
Upper(NODE3) as NODE3,
Upper(NODE4) as NODE4,
Upper(NODE5) as NODE5,
Upper(NODE6) as NODE6,
Upper(NODE7) as NODE7,
Upper(NODE8) as NODE8,
Upper(NODE9) as NODE9
FROM [lib://QVD/Section Access/SAUsers.QVD] (qvd)
;
Section Application;

ExpandedNodes:
LOAD
Upper(Node1) as NODE1,
Upper(Node2) as NODE2,
Upper(Node3) as NODE3,
Upper(Node4) as NODE4,
Upper(Node5) as NODE5,
Upper(Node6) as NODE6,
Upper(Node7) as NODE7,
Upper(Node8) as NODE8,
Upper(Node9) as NODE9,
ParentGroup,
Path,
NodeIDCostCenterName,
ParentIDGroup,
Node
FROM [lib://QVD/Section Access/ExpandedNodes.QVD]
(qvd)
Where Node1 = 'R130000000' or
Node1 = 'R183000000' or
Node1 = 'R190000000' ;

//ExpandedNodeNames:
inner join (ExpandedNodes)
LOAD
Level1,
Level2,
Level3,
Level4,
Level5,
Level6,
Level7,
Level8,
Level9,
ParentCostCenterGroup,
"Davey Hierarchy",
NodeIDCostCenterName,
ParentIDCostCenterGroup,
Level,
DepthCostCenterGroup
FROM [lib://QVD/Section Access/ExpandedNodeNames.QVD]
(qvd);

//ProfitCenters:
Inner Join (ExpandedNodes)
LOAD
NodeIDCostCenterName,
"Profit Center",
SAPROFITCENTER,
"Profit Center Name",
"PC Desc"
FROM [lib://QVD/Section Access/CostCenterGroupHierarchy.QVD]
(qvd);

[marcus_sommer]

Just comment the section access statement to load the section access data as a normal table which is displayed within the table-viewer which should show now synthetic keys between your tables. Often it worked with them but IMO it's a mistake which could have some side-effects. Therefore I think I would load the data with a crosstable statement to get the multiple node-fields into a single one probably combining it with the SAPROFITCENTER to get a proper key.

Beside this it's often helpful to create a tablebox from the section access table and the appropriate associations from your datamodel to see if they contain really the expected content - means not to look for technically issues which might not there else to look if the data are loaded properly.

- Marcus

[tmumaw]

I made it a table and end up with a synthetic key.  So now what does that tell me?

[marcus_sommer]

It tells you that your datamodel has some weaknesses - at least if you not intentionally created it in this way. There are meanings that synthetic keys aren't bad and maybe sometimes even a benefit but IMO it's a sign that the developer hadn't completely comprehend the data and the to the requirements deduced datamodel.

If now anything didn't worked like expected I wouldn't look for any causes unless the datamodel is build properly.

In your case it means there might no real issue with the section access feature itself else the reason is probably the not really suitable datamodel. Therefore my suggestion to look to these data within a tablebox maybe within an extra sheet and a couple of listboxes. With it you could simulate the effects of the section access which worked in general like selections unless it didn't set the state-value to FALSE for the excluded values else just dropped the data from the application.

Here a post with multiple links including tips of resolving synthetic keys and applying the mentioned crosstable-loads:

Get started with developing qlik datamodels - Qlik Community - 1485839

and if you really want to dive deep into the synthetic key stuff you may read:

 Should We Stop Worrying and Love the Synthetic Key?

- Marcus

[tmumaw]

Good Morning Marcus,

I did what you suggested.  I created 2 list boxes one with the USER and the other with NODE3.  When I select R172000000 the correct USER shows up, then when I select just the USER the correct NODE3 shows up.  So I am sort of confused.  I thought section access acted like a user making a selection in the app.  Thanks Thom

[marcus_sommer]

That is one step - the next is to look within further listboxes/tableboxes which data are remain available for the user - it should be exactly those which the user should have access to and everything else should be greyed out. And this should be fitting for each user.

- Marcus

[tmumaw · Accepted solution]

Hi Marcus,

I was able to get it to work.  I think there is an issue in Qlik.  I changed all my USERS to ADMINS and it works.  They still only see what they are allowed to see.  Wonder what is going on with this?  Thanks for all your help.  Looks like we gain a lot of followers.

Thom

[tmumaw]

Marcus,

Check this out.

https://community.qlik.com/t5/Qlik-Sense-App-Development/Difference-Section-Access-User-and-Admin-Ql...

[marcus_sommer]

I never used section access + other security settings within Sense and have therefore no own experience especially in regard to the differences to View. I think the Qlik help descriptions to this feature have some weaknesses respective errors and omissions - in general due to history from View and particularly by implementing the feature into Sense.

In regard to the script and the datamodel doesn't exists much and bigger differences between Sense and View and therefore I assume that this is also true for the main-logic behind section access.

This means in regard to your observations respectively those from your provided links that the specifying of admin/user within ACCESS hasn't an impact on the data-reduction itself - it depends completely on the approved data. But it has - at least in View - an influence to the various settings which were needed for the section access (restrictive mode, preventing binary loads, ... and related to those what happens by non-matching users/reductions or any failure) and also to the security settings of the application. Means assigning an user as ADMIN within the section access made the user to an ADMIN for the application itself. This means the user is able to change the various settings to get access to nearly all information about and within the application. The simplest case here is just to execute a reload to get access to all data because section access is only applied by opening the application. Most of it is only relevant by having a physically access to the file and/or using the desktop client or the IE plugin - but until today it's probably not very seldom that's used in this way within View environments. Therefore assigning the proper access-rights within ACCESS isn't irrelevant.

I don't know if this touched also any application settings/rights in Sense because the application/security logic is quite different to View - but I wouldn't discard any impact of it to easily because there may also scenarios in which it isn't indifferent if an user is an USER or an ADMIN.

- Marcus