Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello guys,
is it possible to know whether a user has logged in with Admin privileges or User ones?
I mean, in section access I have this situation:
Section Access;
LOAD * INLINE [
ACCESS, USERID, PASSWORD
ADMIN, USER1, aaa
ADMIN, USER2, bbb
USER, USER3, ccc
USER, USER4, ddd
];
Thanks to the QvUser() variable I'm able to know the name of the user (USER1...USER4), but what if I'd like to set something using the ACCESS column (thus ADMIN or USER)?
Thanks.
N.
You are offered "Save As" because the data is being reduced. If you don't want reduction, turn it off on the Document Properties -> General tab. If you do want reduction, make sure you reload when logged in with an Admin id. And perhaps set "*" for the LEVEL of that id as well.
-Rob
Like Rob mentioned the save as occurred after a data-reduction. To avoid it could become quite hard - even for the admin-users - because with the wildcard * you could only fetch existing values. But if there are missing keys or NULL's the data-reduction will happens. It's quite the same like directly selecting/accessing NULL within the UI - it's not possible. To avoid it you would need more or less efforts within the datamodel to check them all and filling missing values and/or replacing the NULL's with real values and/or remove invalid data already during the load-process.
But IMO it's not really necessary because manually opening an application and performing any adjustments without the aim/need to execute a reload, too is probably rather seldom so that the occasionally save as query is just a bit bothersome but not a big issue.
Personally we do this task a bit different and using NTNAME within the section access instead of USERID + PASSWORD and query then with something like:
wildmatch(osuser(), 'AdminGroupA*', 'AdminGroupX*')
if an admin-user opened the application or not. With this approach all the sheets and objects are always visible for the admin-user because the osuser() does always exists whereby the qvuser() seems to be only existing after opening the application and entering the user credentials and becomes invalid respectively is removed after a reload and the re-creation of the ActiveDocument.
Beside this you may consider to include the visibility-conditions already within the section access. I never did it myself but I know that there are possibilities for it. For this take a look on the links at the bottom from this post:
Section Access - Qlik Community - 1493681
- Marcus
I suppose you could add another field in the Section Access table that links to another table with a value you can test. Like
Section Access;
LOAD * INLINE [
ACCESS, USERID, PASSWORD, LEVEL
ADMIN, USER1, aaa, A
ADMIN, USER2, bbb, A
USER, USER3, ccc, U
USER, USER4, ddd, U
];
Section Application:
LOAD * INLINE [
LEVEL
A
U
];
-Rob
Thank you for the reply, Rob
unfortunately, I currently use your suggestion, but after every data reload the link between USERID and LEVEL is miss, so I have to save the QV file (note that, strangely the option "Save As" instead of "Save" is proposed automatically by QV), then exit and re-enter in the QV file to have the link again available and consequentially the qualification.
For that, I thought to set them using the system field ACCESS instead of my field LEVEL, but I'm not able to catch it.
Hope it's clear.
Thanks.
N.
You are offered "Save As" because the data is being reduced. If you don't want reduction, turn it off on the Document Properties -> General tab. If you do want reduction, make sure you reload when logged in with an Admin id. And perhaps set "*" for the LEVEL of that id as well.
-Rob
Hi Rob,
I have this section access
Section Access;
LOAD * INLINE [
ACCESS, USERID, PASSWORD, ID
ADMIN, ADMIN, 0000, 1
ADMIN, AAAA, 1111, 2
USER, BBB, 222, 3
];
Section Application;
AccessGroups:
LOAD * INLINE [
ID, GRUPPO
1, AMMINISTRATORI
2, PROGPROD
3, OFFMON
];
And I've set the reduction
Then I've set some object as
And the variable MasterUser as
So, when I reload data (logged by USERID = AMDIN), at the end of the reload all conditioned object disappear, and I have to Save (not Save As) the QV file, exit from QV, re-enter in the QV file and, without do anything ,all the conditioned objects appears again (!); at this moment, when I save the QV file, the "Save AS" instead of the "Save" proposal is asked me (note that I'm allowed to override the QV file using the same name).
For all these nuisances, I thought to set the MasterUser by the ACCESS variable and not by the GRUPPO field.
Have you got an idea about this strange behavior and how to workaround it?
Thanks.
Nick.
Like Rob mentioned the save as occurred after a data-reduction. To avoid it could become quite hard - even for the admin-users - because with the wildcard * you could only fetch existing values. But if there are missing keys or NULL's the data-reduction will happens. It's quite the same like directly selecting/accessing NULL within the UI - it's not possible. To avoid it you would need more or less efforts within the datamodel to check them all and filling missing values and/or replacing the NULL's with real values and/or remove invalid data already during the load-process.
But IMO it's not really necessary because manually opening an application and performing any adjustments without the aim/need to execute a reload, too is probably rather seldom so that the occasionally save as query is just a bit bothersome but not a big issue.
Personally we do this task a bit different and using NTNAME within the section access instead of USERID + PASSWORD and query then with something like:
wildmatch(osuser(), 'AdminGroupA*', 'AdminGroupX*')
if an admin-user opened the application or not. With this approach all the sheets and objects are always visible for the admin-user because the osuser() does always exists whereby the qvuser() seems to be only existing after opening the application and entering the user credentials and becomes invalid respectively is removed after a reload and the re-creation of the ActiveDocument.
Beside this you may consider to include the visibility-conditions already within the section access. I never did it myself but I know that there are possibilities for it. For this take a look on the links at the bottom from this post:
Section Access - Qlik Community - 1493681
- Marcus
Thank you Rob and Marcus for your suggestions; I'll work on them.
Nick.