Prevent selections outside Section Access

[Skage]

Hi all!

Is there a way to prevent selections of values that are not included in a user's data-slice when using Section Access?

The value isn't visible or searchable but selections can be made with api, bookmarks, buttons and actions.

Example... I have two users, A & B, that each have access, by multiple rows in the Section Access-table, to odd and even ids in the Section Application.
If I create a button that makes a selection to a value not belonging to user A then that value will still be selected.

Section Access;
LOAD * INLINE [
ACCESS, USERID, ORGID2 
ADMIN, AD\Admin, *
USER, AD\A, 1
USER, AD\B, 2
USER, AD\A, 3
USER, AD\B, 4
USER, AD\A, 5
USER, AD\B, 6
USER, AD\A, 7
USER, AD\B, 8
USER, AD\A, 9
USER, AD\B, 10
];

Section Application;
Load RowNo() as ORGID2, RowNo() as ORGID, Rand() as Data AutoGenerate(11);

The issue isn't showing 0 values but the fact that other non-locked selections become invalid and are removed.

One work-around is to only have one row per user in the Section Access-table and connect it to an intermediate table that contains the user's identifier and all possible values. Those possible values connect to the real data model. But with many users and possible values the permutations will increase quickly.

/lars

[marcus_sommer]

By a correct working section access it shouldn't be possible because only authorized data remain within the data-set and everything else is removed during the opening-process of the application - means no selections are possible.

[Skage]

@marcus_sommer 

That's exactly what I assumed before testing it myself and the reason for asking the question...

I know what SA does but I'd like to prevent selections, via primarily via api in a mashup, but it show the same behavior with bookmarks, buttons or actions as well.

Do you mean that there is an issue with the script?

User A will only see odd numbers but with a button a selection can be made with an even number.

If you create a Sense app with that script and create a button that select a number not in the slice of that user you will see that it IS showing up in the selection bar. That number can't be selected in a filter pane because it is not showing nor can it be searched for it in the same filter pane, but the button WILL select it.

[Or]

That's interesting, and almost certainly a bug. I'd suggest reporting it as such.

I was able to replicate this on my end - a user restricted to Dim1 = XX was able to select Dim1 = YY using a button (though no data was available for this, it did show up in the Current Selections section). Since no actual data was available for this, everything was grayed out as excluded and the user wasn't actually exposed to any information they shouldn't have, though I suppose someone with a Professional license and a lot of patience could set up a button and cycle through potential field values to get a list of possible ones outside their permission. As security issues go, that doesn't sound too major.

[Skage]

QlikView does not and Qlik Sense do perform the selection of a value outside reduced data.

It's probably yet another Sense-WAD so I'll just stick to the ugly work-around.

[marcus_sommer]

If I understand you right the section access is working like expected because the unauthorized data are removed but the selection-bar showed not possible dimension-values if these selections are made indirectly with bookmarks or any actions?

In this case I doubt that's avoidable with any configuration because the selection-bar showed the attempted selections and not the applied ones. It's a native behaviour in Qlik since the very old QlikView days and not related to section access in any way.

This means if you really want to prevent this you will need to filter all kind of indirect selections dynamically in regard to the authorized data of the current user or in other words you couldn't simply use predefined globally selection-lists.

In this regard I suggest to re-think the entire usability approach because all the magic behind the actions have often much more disadvantages as benefits, see:

Let the User Select - Qlik Community - 1463978

[Or]

Hi @marcus_sommer 

Just to clarify, at least based on my own testing just now...

Load * INLINE [

Field1

AA

BB

];

Section Access limits the user to just AA, either directly or indirectly through another field.

If I try to select AA using a button, this works as expected.

If I try to select BB using a button, it shows up in the current selections section and all values are grayed out (excluded) for every field in the app except Field1 (where all values are shown in Alternative light gray)

If I try to select CC using a button, nothing happens (no selection is made).

So, the issue is that the user can make a selection on values that are excluded by Section Access, not on any arbitrary value they happen to try. This is true regardless of whether you are selecting on the reduction field or on any other field in the app.

Luckily, Qlik does still respect the reduced app's data when you try to make a second action. For example:

Load * INLINE [

Name, Salary

John, 100

Jane, 150

June, 200

];

If someone is limited to seeing John, they could use a button to select Jane, but if they tried to use a second button to select Salary = 150, that would bounce the Jane selection (because it is excluded from 150 in the reduced version). This means you can't use buttons to go fishing for matching data, only for a single field's values at a time.

[marcus_sommer]

I also did a short testing before above deducing the logic behind the behaviour but not with section access because I have none without a full-access and didn't want to make so much efforts and just added a button with a search-string with a non existing period:

But in regard to your noticed behaviour of the selections and the applied coloring my deducing might be wrong or is at least not a complete explanation.

If I think more about I'm not so sure which data are really removed by the section access - the ones from the data-tables and from the system-tables or only from one of them and/or may any of the state-tables have also an impact? Sure seems to be that any kind of the data must be remain because otherwise the noticed behaviour couldn't happens.

If I would have to guess I would think that only the data from the system-tables are removed and the ones in the data-tables remain and this is causing a kind of cross-intersection effect to the possible selection-values and their coloring.

[Or]

QV behaves differently here, I believe, compared to QS. QS shows the actual selection, not the criteria used to select it (except in bookmarks), I believe. I'd also note that in your example, nothing suggests 202309 is a value, just that the search string (202307|202308|202309) was used to make a selection. If you attempted to do the same thing with just 202309, I imagine nothing would be selected.

Qlik doesn't recreate the data for each user in full (reduced by Section Access of course) - doing so would be extremely inefficient - so I imagine you're on target regarding the behavior. It seems like in this particular scenario, actions can squeeze by the mechanism that handles the reduction.

[marcus_sommer]

You are probably right that Sense and View are working a bit different in regard to the selection-bar. Beside of this I believe there is rather no way to influence this behaviour whereby personally I regard this more as a side-effect of a not native usage than as a bug.

Native usage means just to use the normal field-selections and no magic-approaches with actions, set analysis, alternate states and whatever - unless you are willing to make all extra steps of showing and explaining the users which objects may behave differently to the direct selected values and why. In a very small dose these technically features could become very useful but as a standard usage it cost a lot of time (not mandatory the technically implementation but the documentation of the when/where/why).