Go through the Section Access topic in the Qlikview Reference Manual document, you will find the example and explanation for you requirement.
or just go through this document
Hope this helps you.
Thanks I have read them, and I still dont have a solution. Sorry for the insistent, but I like qlikview and this security problem may me go in other decision.
I will reduce the problem
Brand Segment Sales A 1 2000 A 2 100 A 3 12000 B 1 3155 B 1 4654 B 2
C 2 544 C 3 4897 C 4 21321 C 1 513463
I have 7 users -> 3 Brand manager and 4 segments analysts
They should have access as the following table indicates, where the * means all.
USER BRAND SEGMENT ADMIN * * U1 A * U2 B * U3 C * U4 * 1 U5 * 2 U6 * 3 U7 * 4
Do you understand my problem? is it feasible?
Your script has some syntax errors. Since you are using Personal Edition I cannot attach any applications for you, but use this script instead. Notes to bear in mind:
- In section access, "*" does not mean "all" but "listed values". That means that you need at least one user with all possible values, one per line, as the ADMIN user below.
- QlikView is case sensitive, fields in section access must have the same exact spelling in the data model than in the section access table
- It's not mandatory but highly recommended to add an ACCESS field so you can later on set additional security settings and make sure you don't lock yourself outof the document when testing
- Fields in section access have fixed names, ACCESS, USERID (USER is not valid)
Data: LOAD * INLINE [ BRAND, SEGMENT, Sales A, 1, 2000 A, 2, 100 A, 3, 12000 B, 1, 3155 B, 1, 4654 B, 2, 321321 C, 2, 544 C, 3, 4897 C, 4, 21321 C, 1, 513463 ]; SECTION ACCESS; Security: LOAD * INLINE [ ACCESS, USERID, BRAND, SEGMENT ADMIN, ADMIN, A, * ADMIN, ADMIN, B, * ADMIN, ADMIN, C, * ADMIN, ADMIN, *, 1 ADMIN, ADMIN, *, 2 ADMIN, ADMIN, *, 3 ADMIN, ADMIN, *, 4 USER, U1, A, * USER, U2, B, * USER, U3, C, * USER, U4, *, 1 USER, U5, *, 2 USER, U6, *, 3 USER, U7, *, 4 ]; SECTION APPLICATION;
Hope that helps.
Section access table is actually in loaded into memory but hidden from all users and not accessible. If you want to write the section access table to a database you will need to load it in a different part of the script with different field names and then you can use a QVD file to store it or you can create a chart in a different file and export to csv or xls file and import this file into your database.
And yes, you can use the ADMIN user to add all new values in BRAND and SEGMENT as displayed above.
Hope that helps.
If I understand your question correctly, you want to keep the Section Access table in a database, edit it there and load it from there (not from inline definition) - if that is so, then you certainly can do it, it loads just like any other table.
As to whether you can just keep expanding the Section Access table with more fields, sure you can, but if you want to restrict access to the data based on values of more than one field for a single user, then it might get problematic, depending on what exactly would you like to achieve.
Thanks to all of you!
I have a doubt if I change a little the access i have errors
LOAD * INLINE [
BRAND, SEGMENT, Sales
A, 1, 2000
A, 2, 100
A, 3, 12000
B, 1, 3155
B, 1, 4654
B, 2, 321321
C, 2, 544
C, 3, 4897
C, 4, 21321
C, 1, 513463
LOAD * INLINE [
ACCESS, USERID, BRAND, SEGMENT
ADMIN, ADMIN, A, *
ADMIN, ADMIN, B, *
ADMIN, ADMIN, C, *
ADMIN, ADMIN, *, 1
ADMIN, ADMIN, *, 2
ADMIN, ADMIN, *, 3
ADMIN, ADMIN, *, 4
USER, U1, A, *
USER, U2, B, *
USER, U2, C, *
USER, U3, C, *
USER, U4, *, 1
USER, U5, *, 2
USER, U6, *, 3
USER, U7, *, 4
USER, U8, A, 1
USER, U8, B, 1
USER, U8, C, 2
USER, U9, A, *
USER, U9, B, 1
I want the user "U8" to have access to the segment 1 of the Brands A and B and also to the segment 2 of the Brand C.
But with this code I can see segments 1 and 2 of the brands A B and C.
Happens sth similar in the case of U9
Thats exactly what I want to do! load directly from a DB and filter by more than one field!
Do you know a way to do it!?
As I said, you can load directly from DB without problem - LOAD statements in Section Access can use every source they can use anywhere else. Just make sure the special Section Access fields are named correctly (ACCESS, USERID, and so on).
For filtering on more than one field, the problem is in how the initial data reduction works internally. This data in Security table:
ACCESS, USERID, BRAND, SEGMENT ... USER, U8, A, 1 USER, U8, B, 1 USER, U8, C, 2 ...
means actually this: "for user U8, select A, B, C in field BRAND, select 1, 2 in field SEGMENT, reduce data keeping possible values". The user can see every row of data where BRAND is either A, B or C AND SEGMENT is either 1 or 2. As you can see, how the values are combined in particular rows of Security table has no meaning here.
For your requirement of restricting access to records with particular combinations of the fields, the only way I am aware of is to create the combinations in data and assign them to the user in Security table. It can get somewhat hard to manage if there is plenty of possible combinations. Here is what I mean:
Data: LOAD *, BRAND&'+'&SEGMENT as BR_SEG INLINE [ BRAND, SEGMENT, Sales A, 1, 2000 A, 2, 100 A, 3, 12000 B, 1, 3155 B, 1, 4654 B, 2, 321321 C, 2, 544 C, 3, 4897 C, 4, 21321 C, 1, 513463 ]; SECTION ACCESS; Security: LOAD * INLINE [ ACCESS, USERID, BRAND, SEGMENT, BR_SEG ... USER, U8, , , A+1 USER, U8, , , B+1 USER, U8, , , C+2 ... ];
(please note - because you are making a selection in the combination field BR_SEG you can leave the values for BRAND and SEGMENT empty, this means there will be no selection on these fields. However, if there are no matching selections in ANY of the fields, the user will get locked out of the document if Strict Exclusion is enabled)