Oh yes, forgot to mention that and yes I know that would work. My concern there was that if the amount of dimension ids grows really high, am I in risk of suffering from severe performance issues while opening the document and during distribution?
Now that I think about it, I guess LAURAL would then also have a quite substantial list of values anyway...
Thank you anyway! If someone has any other insights to give, that would be great but I think this solved the issue in my mind well enough
What you are seeing is the as designed behaviour. The * means "all the dimensionids explicitly listed in the section acces table" (not all possible values). So I would expect HENRYB to have the same access as LAURAL in your code.
IsrarKhan is correct. The solution is to add Henry 3 times as shown. If you have more users than shown in your example, and if you have at least 1 user for each possible DimensionID, then you can use * for HENRYB.
Logic will get you from a to b. Imagination will take you everywhere. - A Einstein
The behavior with the ADMIN user is quite interesting though. The documentation didn't completely explain why these kind of differences happen. For example, without the strict exclusion you can have the issue that if one of your limitations does not match to any value in the field, NONE of the limitations apply! (ie. if you have section access limit values in fields Dim1 and Dim2. Then if the Dim1 doesn't contain any matches, the user is shown all the data without any limitation from Dim2 either.)
With ADMIN user, if you apply a sections access similar to LAURAL, the user sees only what is specified, but when some of the values do not match, then even with the strict exclusion enabled that user suddenly sees everything while the USER type would not be able to see the document at all.
I can provide examples of this if someone is interested. This certainly was a surprise for me when I found this out through testing...