Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi all,
I have a question regarding the use of a wildcard in the USERID column for the section access. Is it possible to use the user directory plus a wildcard e.g.
ACCESS USERID REDUCTION
USER ACCOUNTS\* TEST
If i try this, I always get an error message, that the data can not get saved, because I'm getting locked out. So it looks like this is not possible. Or am I doing something wrong here?
Any feedback would be very much appreciated.
Thank you very much for your support.
Best regards,
Dirk
In that case, you need a table with those users USER ID to build this section access table. Not even a loop is needed, just load the table. For your internal users, use a separate table with their info and concatenate all together.
You cannot do this. You need to list all users. One dynamic way to do it, is to get the list of users somewhere, maybe though an LDAP connection, loop through it to create a temp table with users and then use this table in your section access.
However, if you don't mind me asking. If you want to allow all users, why even have a section access? And if the answer is "to reduce based on a field", why simply not removing in the script?
Thank you very your feedback. I have some external users, who shall see only part of the data, that's why I want to go with section access. My example was simply to show, what I try to do. I thought it might be possible, because you can use wildcards in USERID, but obviously only * not * combined with a user directory.
My external users use SAML for authenticating, so I don't have groups to distinguish them from my internal users. I need to test, if I can use * in the USERID and * in the GROUP - maybe my SAML users will get access then to one set of data only.
I will test it and then post the results here in the forum.
In that case, you need a table with those users USER ID to build this section access table. Not even a loop is needed, just load the table. For your internal users, use a separate table with their info and concatenate all together.
If you're using SAML for the external users, you can use a static attribute on the virtual proxy. Example: https://community.qlik.com/t5/Qlik-Sense-Documents/Using-Rules-to-segregate-Consumption-from-Develop.... I'd expect something like this to work:
This will not work if you're already using a claim for groups and want to continue using that claim for other access (e.g. to a stream, etc).