Restrict access vs data model

mmstefan — Wed, 25 Nov 2020 16:16:04 GMT

Good morning,

I have following problem with restricting access to data for users - I have a database containing sales volumen in the branches and for single employees (Akquisitors)
The goal of this report is to show on 2 charts to each employee (identified by NTNAME in SECTION ACCESS) total sales volume of each branch and his own (employee's) sales volume. Employee cannot see sales volume of his colleagues, only specified users (like branch directors) can do that.

To be honest I don't know how to define SECTION ACCESS or maybe i need to change the data model?

SECTION ACCESS;

LOAD * INLINE [
ACCESS, NTNAME, ACQUISITOR_NO, BRANCHID
USER,AT\123025236,*,*
];

SECTION APPLICATION;

ACQUISTOR:
LOAD * INLINE [
ACQUISITOR_NO, Name, BRANCHID
18291, Name1, 1
11555, Name2, 1
11236, Name3, 2
14214, Name4, 3
18712, Name5, 2
];

BRANCH:
LOAD * INLINE [
BRANCHID, BranchName
1, Branch1
2, Branch2
3, Branch3
];

SALES:
LOAD * INLINE [
ACQUISITOR_NO, Vol
18291, 10000
11555, 2500
11236, 12000
14214, 7800
18712, 5600
];

Many thanks in advance for your help.
Best regards

Re: Restrict access vs data model

marcus_sommer — Thu, 27 Jun 2019 09:14:04 GMT

It's not possible within a classical hierarchically data-structure because you couldn't allow and denied the access to certain data at the same time - means to restrict the data on the employee-level and allow the viewing on a higher aggregation.

If the restrictions are more a kind of usability instead of very strict rules it could be solved with an access-control to certain sheets/objects and/or additionally conditions - on osuser() - within the various dimensions/expressions.

If not you will need changes on the data-structure. This could be done by keeping different respectively doubled data within the datamodel and/or to mask the data: Mask or de-identify data for certain users using Section Access.

Another far more easier way would be to split your application. For this you will only need two simple section access without too much efforts in maintaining two applications (most of the work could be done ones and is just a copy & paste task). After some years in struggling with a complex set analysis we use this simple approach and fullfill the real requirements much better because we don't have a forecasting or any planning on the employee-level else it starts by the store-level and therefore we could simplify things and providing a different focus on the important views.

- Marcus

topic Re: Restrict access vs data model in QlikView

Restrict access vs data model

Re: Restrict access vs data model