Need help setting up Role using USERPRINCIPALNAME() with an extra parameter

[Pierrev31]

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! 

[OwenAuger]

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

[OwenAuger]

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

[Pierrev31]

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! 

[OwenAuger · Accepted 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

[Pierrev31]

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!