Forum Discussion
Need help setting up Role using USERPRINCIPALNAME() with an extra parameter
Hello everyone!
I created a Role where a Partner could only see their own Engagements by using the USERPRINCIPALNAME() measure.
It is as follows:
If he is a Lead Eng. Partner or and Eng. Partner or and Associate Partner, he should be able to see the Engagement he is a part of.
In the following example, Partner B is an Eng Partner for the Engagement 3000431234, so he should see that row. The way I have set up, he can only see the rows his username shows up. However, in this case he would need to be able to see the other Engs. as well because one of the Engagements he is part of is in the Lead Engagement 2001401234. In cases where neither of these two conditions apply, he should not be able to see either the Eng. nor the Lead Eng.
Lead Engagement | Engagement | Lead Eng Partner Email | Eng Partner Email | Associate Partner Email |
2001401234 | 3000431234 | n/a | ||
2001401234 | 3000401555 | n/a | ||
2001401234 | 2001401234 | n/a |
And that is where I'm having trouble setting up, because in some cases such as this one, the partner isn't in either of those three email fields, but because he is part of the Lead Engagement, he should also be able to see them as well.
Any help is appreciated! Thanks!
Thanks Pierrev31
Yes that clarifies it!
Here is how I would write the RLS filter expression assuming the table is named Engagements:
VAR UPN = USERPRINCIPALNAME () RETURN CALCULATE ( NOT ISEMPTY ( Engagements ), Engagements[Lead Eng Partner Email] = UPN || Engagements[Eng Partner Email] = UPN || Engagements[Associate Partner Email] = UPN, ALLEXCEPT ( Engagements, Engagements[Lead Engagement] ) )We only need to check the 2nd condition since it dominates the 1st condition. That is, if the current user exists on at least one row with the current row's Lead Engagement, then that user exists on the current row.
Mock-up PBIX attached.
Regards
5 Replies
Hi Pierrev31
Just clarifying the requirement:
For the 2nd condition, where a Partner can see rows relating to Lead Engagements that he is a part of, does that apply regardless of whether he is Lead Partner, Lead Eng Partner or Associate Partner against the Lead Engagement in question?
In other words, is is the rule that if a Partner appears at all in at least one row for a particular Lead Engagement, he should see all rows for that Lead Engagement?
Regards
Owen
Hello!
Yes If he appears at all as a Lead Eng Partner, Eng Partner or Associate Partner for any Engagement, he should be able to see all rows associated with the Lead Engagement of that Engagement. So just to make it clear, I expanded the base to show what I mean:
Lead Engagement Engagement Lead Eng Partner Email Eng Partner Email Associate Partner Email Can see? 2001401234 3000431234 [email protected] [email protected] n/a Yes 2001401234 3000401555 [email protected] [email protected] n/a Yes 2001401234 2001401234 [email protected] [email protected] n/a Yes 2007543543 2007543543 [email protected] [email protected] n/a No 2007543543 3001546654 [email protected] [email protected] n/a No 2005125452 2005125452 [email protected] [email protected] [email protected] Yes 2005125452 3005324565 [email protected] [email protected] n/a Yes He is part of the Engagement 3000431234, part of the larger Lead Engagement 2001401234, so he should also be able to the rows for the Eng. 3000401555 and Eng, 2001401234, even though he doesn't show up in any of those email columns for those two Engagements, as they are part of the larger Lead Engagement 2001401234.
Same thing applies to the Lead Eng. 2005125452, as he is an Associate in the Eng. row 2005125452, so he should the entire Lead Eng.
And in the case of the Lead Eng. 2007543543, as he doesn't show up in any rows for the Engs. he shouldn't be able to see it at all.
Thank you very much! Hope I was clear!
Thanks Pierrev31
Yes that clarifies it!
Here is how I would write the RLS filter expression assuming the table is named Engagements:
VAR UPN = USERPRINCIPALNAME () RETURN CALCULATE ( NOT ISEMPTY ( Engagements ), Engagements[Lead Eng Partner Email] = UPN || Engagements[Eng Partner Email] = UPN || Engagements[Associate Partner Email] = UPN, ALLEXCEPT ( Engagements, Engagements[Lead Engagement] ) )We only need to check the 2nd condition since it dominates the 1st condition. That is, if the current user exists on at least one row with the current row's Lead Engagement, then that user exists on the current row.
Mock-up PBIX attached.
Regards
Glad to hear it 🙂
In the RLS filter expression, CALCULATE adds the values in the current row of Engagements as a filter.
The modifier
ALLEXCEPT ( Engagements, Engagements[Lead Engagement] )removes all filters from the Engagements except Engagements[Lead Engagement].
In other words, it keeps the just Lead Engagement filter from the current row, ignoring all other values on the current row.
The overall CALCULATE expression then determines whether any rows exist for that Lead Engagement containing the current user.
Some discussion of the function in this article:
https://www.sqlbi.com/articles/using-allexcept-versus-all-and-values/
Regards
