Complex Section Access

[MarcellSzeles]

Hi All,

I'm looking to get some guidance on my issues with section access.
What I need to solve is something looks something like this:

Region | Country | Branch | Product

There could be access given in any permutation of the above "matrix".
So there could be an user with the rights below (<ANY> means any from the database, not just the listed options in section access):

REGION	COUNTRY	BRANCH	PRODUCT
EU	<ANY>	<ANY>	IMPORT
EU	HU	BUD	EXPORT

In this scenario I'd want the given user to access to all "IMPORT" lines what belongs to "EU" AND access to "EXPORT" lines within the branch "BUD" (which is also in EU, HU).

And so on... Would I need to build all 4! (24) combinations?

I have seen a .qvw file floating around (Generate Complex Authorization Script in QlikView ... - Qlik Community - 1690689) to generate a complex access script, however this seems to be very obsolete, nothing happens when converted to .qvf.

Thank you in advance!

[Chanty4u]

Y can't you try with *?

SECTION ACCESS;

LOAD * INLINE [

ACCESS, USERID, REGION, COUNTRY, BRANCH, PRODUCT

ADMIN, DOMAIN\USER1, EU, *, *, IMPORT

ADMIN, DOMAIN\USER1, EU, HU, BUD, EXPORT

];

SECTION APPLICATION;

Data:

LOAD Region, Country, Branch, Product, OtherFields

FROM YourDataSource.qvd (qvd);

[marcus_sommer]

I think the efforts to create all necessary combinations is usually overrated because often they could be rather simply created with loop- and/or join-approaches - which might be used very dedicated or maybe in a cartesian logic, like:

t: load distinct User from Users; join(t) load distinct Country from Countries;

and then mappings (might be created in similar ways) are used to apply the relevant values and afterwards may come some filter to remove the non-matching.

In regard to use wildcards for all values it could be helpful to apply them to a dummy user with the ACCESS of NONE. If they are listed there the wildcard of * would reflect them. Further all relevant data of existing countries, products, what ever shouldn't be extracted within the section access else within the previous layer. After loading and preparing the relevant facts and dimensions these values could be fetched with loads against the system-tables, for example:

t: load text(fieldvalue('Country', recno())) as Country autogenerate fieldvaluecount('Country');

[MarcellSzeles]

There are 2 problems with this logic:

* will only apply values that are existing in the section access table.
For the above example, if there's also a value for country like "DE" and no user is given the section access for "DE", then * will not include "DE".

A solution for this could be to load all distinct values to a dummy user, fine.

But the main problem with the following

ACCESS, USERID, REGION, COUNTRY, BRANCH, PRODUCT
ADMIN, DOMAIN\USER1, EU, *, *, IMPORT
ADMIN, DOMAIN\USER1, EU, HU, BUD, EXPORT

is that Section Access will take combine everything with an AND relation. Therefore the user will not only see "EXPORT" (product) for "BUD" (branch), but they'll see "EXPORT" for all EU countries.

[MarcellSzeles]

@marcus_sommer 

I think the efforts to create all necessary combinations is usually overrated because often they could be rather simply created with loop- and/or join-approaches - which might be used very dedicated or maybe in a cartesian logic, like:

t: load distinct User from Users; join(t) load distinct Country from Countries;

and then mappings (might be created in similar ways) are used to apply the relevant values and afterwards may come some filter to remove the non-matching.

I'll have to give myself some time to interpret this, because currently it's not getting together in my mind.

Related to loading all distinct values to "counter" the wildcard problem, thank you, that's been my idea as well, I'm / I was just looking to see if there's something sophisticated in 2025.

[marcus_sommer]

I think it's a quite common behaviour of an authorization - only listed values get an access + any denying will overwrite all permissions + all conditions are always associated per AND (never enabling any kind of OR logic).

In my earlier days I regarded it as a weakness but nowadays I like this simplified approach because it avoids mistakes within more complex logic - already during the development and later by maintaining it and/or by changes within the data-set.

This doesn't mean that no OR logic could be used to define the wanted accesses else that they then need to be resolved to an appropriate AND records. Like above hinted this mustn't be done manually else could be created within the script with native transformation-processes.

Beside this you are intending to use multiple fields for the authorization which will probably reside in different tables. AFAIK it's possible to build such logic. But it will have it's costs - with a higher complexity and/or the lost of using the wildcard-feature. Personally I would try to reduce it by concatenating the fields, maybe like:

F1 & '|' & F2 as AccessKey

and also reducing the number of the associated tables or implementing it against the fact-table.

[marcus_sommer]

Meant was that all existing field-values are already known before a section access implementation should happens because everything were already loaded within previous layers and could be there quite easily extracted and stored.

Thinking it further it may also be useful to add an own authorization layer between the generator- and data-model layers which which creates n versions of authorizations which are later just picked.