Qlik Community

New to QlikView

Discussion board where members can get started with QlikView.

Announcements
QlikView Fans! We’d love to hear from you.
Share your QlikView feedback with the product team… Click here to participate in our 5-minute survey.
Rules, plus terms and conditions, can be found here.
Not applicable

UserAccess

Hi All

I'm working with QlikView version 8.5 and trying to tweak UserAccess

I've been successful with the following:

     UserID, Password, Serial, Access, REGION, SMAN, PRODGROUP

     person0, pwd0, *, User, , , , //Person0 has access to all REGION, SMAN and PRODGROUP records

     person1, pwd1, *, User, REG1, , , //Person1 has access to all SMAN and PRODGROUP records for REGION = REG1

     person2, pwd2, *, User, ,15, , //Person2 has access to all REGION and PRODGROUP records for SMAN = 15

     person3, pwd3, *, User, , , 200, //Person3 has access to all REGION and SMAN records for PRODGROUP = 200

But how do I allow a person to see all records for a specific REGION and also all records for a specific PRODGROUP, regardless of REGION

I tried this:

    

     person4, pwd4, *, User, REG1, , ,

     person4, pwd4, *, User, , , 200,

but it only goves person4 access to REG1 records where the PRODGROUP = 200

ie it behaves the same as:

     person4, pwd1, *, User, REG1, , 200,

I suppose I could provide the User with two different User ID's but that's not a good solution.

Any Ideas?

Thanks, Raisin

9 Replies
Luminary
Luminary

Re: UserAccess

Hi Raisin,

I have never worked on QV 8.5 and I'm not sure if this is same as Version 9. Although, here is my understanding...

From Help Documentation :

A wildcard, i. e. *, is interpreted as all (listed) values of this field, i.e. a value listed elsewhere in this table. If used in one of the system fields (USERID, PASSWORD, NTNAME or SERIAL) in a table loaded in the access section of the script, it is interpreted as all (also not listed) possible values of this field.

Please be very careful using the '*' (Wildcard) because it doesn't mean all the values in the Actual Field. It means distinct values you have specified in Section Access Table. Unless you have specified all the distinct values within Section Access.

In your Section Access example, you have specified Region as {Reg1} but if your actual Region contains {Reg1,Reg2,Reg3,...,RegN} then you won't see anything except {Reg1} rows even if the User has '*' in Section Access. It will ONLY take all the values from Section Access but not all the values from actual field.

Within your script you need to create a Psuedo user who has multiple entries for each Region and ProductGroup. So you need to build your script where this Psuedo user have multiple rows and then you concatenate this script with your original script to use the "*" (Wildcard). I understand this may not be clean approach but I don't see any other way around (unless I'm missing something silly).

I'm assuming that you are using "Strict Exclusion" within your script. I hope that makes sense.

Cheers,

DV


www.QlikShare.com


Not applicable

Re: UserAccess

Hi DV and thanks for your reply.

I have not checked the box for "Strict Exclusion" because users end up with a Access Denied message when it's checked But works OK when nor checked

I do not underctand what you are saying with the Pseudo User stuff.

Regards, Raisin

Luminary
Luminary

Re: UserAccess

Hi Raisin,

You are welcome. It makes sense to turn off "Strict Exclusion" option but I hope you are aware that if any User who is part of Field reduction but not part of original data set then he'll get full access. Please be very careful when you are not using "Strict Exclusion" option.

Pseudo User means a dummy user like (User1) or any name for that matter. So this User1 will have multiple rows covering all possible combinations of Section Access Level. If you have this User within your script then you can use the "*" wildcard for other real Users.

Let me know if this doesn't make sense.

Cheers,

DV

www.QlikShare.com

Luminary
Luminary

Re: UserAccess

Hi Raisin,

Have you got this working?

Cheers,

DV

www.QlikShare.com

Not applicable

Re: UserAccess

Hi DV,

No, still not.

This forum is more difficult to work with than I remember. Unfortunately I am unable to work out how to attach a sample QV file to this reply so I've had to post an image of the script instead

Sample.JPG

So what is it you are actually suggesting I do?

Regards, Raisin

Luminary
Luminary

Re: UserAccess

Hi Raisin,

Please click on "Use advanced editor" as shown below and then you browse the file to upload. It helps to have the file to test the Section Access Script.

Thanks,

DV

www.QlikShare.comAdvanced Editor.png

Not applicable

Re: UserAccess

OK, I have attached a file with data to make this a functional sample

User Id's and Pwds are

admin, admin

adam, adam

bill, bill

cloe, cloe

Data restrictions for Bill and Cloe are working but not for Adam.

Adam should see all of region North and also Glass for Regions South, East and West

Regards, Raisin

Not applicable

Re: UserAccess

Hi All,

Is anyone able to assist?

MVP
MVP

Re: UserAccess

Hi there,

This code shows where I have section access set up on %USERLOGIN and I have some users that need to have * access, but not all instances of %USERLOGIN exist.

I create a list of each distinct login in the system, and then load it in to Section Access (with identical field list to the intial Section Access list) with dummy values for the other columns.  The default username and passwords would be a bit insecure if it were not that all these entries are tied to a NT Account that does not exist:

Temp_UserLogin:

LOAD

          max(1) as Counter,

          %USERLOGIN

FROM [$(vDataFolder)PrintViewUserProject.qvd] (qvd)

GROUP BY %USERLOGIN;

// Defaults to scope for *

LOAD

          'USER' as ACCESS,

          '-NOACCESS-' as USERID,

          '-NOACCESS-' as PASSWORD,

          '-NOACCESS-' as NTNAME,

          %USERLOGIN

RESIDENT Temp_UserLogin

;

DROP TABLE Temp_UserLogin;

Looking back at the code now (I wrote it a while back) I can't see why I went via a temporary table - but it may well be that it misbehaved when I tried to do the GROUP BY on the section access part.

Hope that helps.

Steve

Community Browser