Get certified in Microsoft Fabric—for free! For a limited time, the Microsoft Fabric Community team will be offering free DP-600 exam vouchers. Prepare now
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 | PartnerA@abcd.com | PartnerB@abcd.com | n/a |
2001401234 | 3000401555 | PartnerA@abcd.com | PartnerA@abcd.com | n/a |
2001401234 | 2001401234 | PartnerA@abcd.com | PartnerA@abcd.com | 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!
Solved! Go to Solution.
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
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 | PartnerA@abcd.com | PartnerB@abcd.com | n/a | Yes |
2001401234 | 3000401555 | PartnerA@abcd.com | PartnerA@abcd.com | n/a | Yes |
2001401234 | 2001401234 | PartnerA@abcd.com | PartnerA@abcd.com | n/a | Yes |
2007543543 | 2007543543 | PartnerD@abcd.com | PartnerF@abcd.com | n/a | No |
2007543543 | 3001546654 | PartnerD@abcd.com | PartnerD@abcd.com | n/a | No |
2005125452 | 2005125452 | PartnerD@abcd.com | PartnerD@abcd.com | PartnerB@abcd.com | Yes |
2005125452 | 3005324565 | PartnerD@abcd.com | PartnerD@abcd.com | 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
Hello! I think it worked! I'm testing right now, but so far it's perfect! If possible, could you explain how the ALLEXCEPT function worked here to do this? It would be great in case I face a similar problem in the future. Thank you very much!
Check out the October 2024 Power BI update to learn about new features.
Learn from experts, get hands-on experience, and win awesome prizes.
User | Count |
---|---|
30 | |
15 | |
11 | |
10 | |
9 |