I should reply "No, this isn't possible" for a variety of reasons, most of them having to do with circumventing and/or rebuilding standard QlikView behavior which may work in QV Desktop but certainly won't work in the AP and vice-versa.
I see two main problems:
- QlikView Authentication is performed before you enter a document. So you would want to ignore all built-in security techniques (Section Access is useless here) and build something of your own.inside your QV document?
- User Input in QlikView is something tricky. QlikView isn't designed to accept input except the occasional value or table column. You could create something like what you describe using two input fields, some heavy object/sheet visibility expressions, and some data hiding logic. But there is no real data reduction and actual security will be ... er minimal. For example, once your document is loaded in QV Desktop, it may prove very easy to remove any restrictions.
Can you describe what exactly you want to manage using these credentials? Is it just to show/hide sheets and objects?
Thank you for your reply Peter!
Alright, what I would like to accomplish is to allow most of the users to open the QV without the hassle of providing credentials (as they would not be granted complete viewing rights nor administrative access), some users would ideally be able to request a "permission upgrade" and after providing credentials being granted full viewing rights (and/or) Admin status.
The purpose of this is a) to prohibit users to manipulate the document (saving/layout/etc.) and b) to filter which tables that are visible. An acceptable solution would be being able to password protect a table/graph. Unfortunately NTNAME/ SERIAL/DOMAIN can't really be used as I expect group membership to change often.
If this can't be done then I will probably go forth with usual section access and force everyone to log on.
I don't understand why Section Access wouldn't cover your requirements. The only difference when using SA would be that document users get their authorizations from the start and not just after promoting to a higher security level. But then, which Admin/Full viewer/Power user really likes having to enter a new set of credentials every time after opening a document with default viewing rights?
For example consider this:
- If you can use NTNAME Section Access, you should. It comes with Single Sing-On, so no more usernames or passwords. Ever
- Use a star in the NTNAME field for everyone with limited rights.
- Explicitly specify account names in NTNAME for every special user, whether a Full User or an Admin. If your data model doesn't need reduction, you can keep that feature disabled, and implement only a set of linked values to show/hide objects and sheets.
- Group management can be done by listing AD group names in NTNAME, instead of user names. Your access management now moves to AD (group membership) instead of being locked inside your document.
- Group names in NTNAME can easily extend the authorizations to four categories: Admins, Full Viewers, Restricted Viewers & Users that don't get in at all.
That's pretty easy to set up. You'll have a bit more work with tying all managed sheets and objects into the permissions system. Conditional Show will come to the rescue...
I agree with the statements from Peter that you should try to implement your requirements with the standard-approach of section access and not with own solutions which only increase the needed efforts and the complexity and reduced the security to only a kind of usability. Some years ago I implemented a similar logic within the IE plugin and some macros but I couldn't really recommend it and we changed it soon.
Maybe not the pure doctrine but quite practically could be to use two applications with a included section access whereby the section access not controlled/reduced the available dataset else controlled the access to the application: