Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Modular Section Access

Hi,

I have developed a small QV Desktop application where most users will be in one group and a select few in another privileged group with access to more data.

Now, I would ideally like to use section access to achieve the issue below but if that is not possible please advice.

The question at hand:

When someone opens the document I would like them to be automatically in the default group without having to provide credentials (I assume USERID=*, PASSWORD=* solves this). If they actually need the capabilities of the second group then a button should be available that prompts for credentials and subsequently changes their group to the one with additional data access. I would not like to use NTNAME or serial number as group membership of the "privileged"-group will change often and on short notice.

Is this possible? Can it be executed through a MACRO or is it possible to access (and change) the System(?) variable that tracks a user group?

Thank you in advance!

Peter

1 Solution

Accepted Solutions
Peter_Cammaert
Partner - Champion III
Partner - Champion III

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?

Peter

View solution in original post

5 Replies
Peter_Cammaert
Partner - Champion III
Partner - Champion III

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?

Peter

Not applicable
Author

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.

Peter

Peter_Cammaert
Partner - Champion III
Partner - Champion III

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...

marcus_sommer

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:

- Marcus

Not applicable
Author

Thank you for helping me understand the workings of SA.