Row level security and bidirectional cross-filtering

Kudos for a superbly formulated post :smileyhappy:

I have found one work-around for this

Member Member Count =
CALCULATE (
    DISTINCTCOUNT ( vMEMBER[Client_Subscriber_Member_ID] );
    FILTER (
        vMEMBER;
        vMEMBER[Client_Subscriber_Member_ID]
            IN VALUES ( vENROLLMENT[Client_Subscriber_Member_ID] )
    )
)

I have not tested the performance of this measure, but on this dataset it seems reasonable. The measure can also be added to the filter of the table visual and set to [Member member count]=1 to show only the corresponding [Client_subscriber_member_id].  Based on your report, this will allow you unchech the 'Apply security filter in both directions'.

Thank you for the reply sturlaws ,

The challenge with that measure is, because the RLS is not driving up to the vMEMEBER the count is not getting limited.  It's sort of an odd behavior but seems to bee the case. 

You did make me realize that the same logic I use on the group filter could be used to limit the vENROLLMENT then a count of the filtered vENROLLMENT (filtered in the role measure, not from model relationships) would work.  I will have to test the efficiency though.  vENROLLMENT is 3M lines and vMEMEBER is 1.5M

So this is the RLS DAX expression applied to vMEMEBER.

VAR _UPN = USERPRINCIPALNAME()
VAR _GroupList =
    CALCULATETABLE ( 
            SUMMARIZE(vSECURITY,vSECURITY[Client ID],vSECURITY[Group ID]),
            FILTER ( vSECURITY, vSECURITY[User_Email] = _UPN ) 
        )
VAR _AllGroupList =
    CALCULATETABLE(
        VALUES ( vSECURITY[Client ID] ),
        FILTER ( vSECURITY, vSECURITY[User_Email] = _UPN && vSECURITY[Group ID] = "AllGroups")
    )
RETURN
    CALCULATE(
        COUNTROWS( vENROLLMENT ),
        INTERSECT( SUMMARIZE ( vENROLLMENT , vENROLLMENT[Client ID] , vENROLLMENT[Group ID] ) ,_GroupList )
    )
    +
    CALCULATE(
        COUNTROWS( vENROLLMENT ),
        INTERSECT( SUMMARIZE ( vENROLLMENT , vENROLLMENT[Client ID] ) , _AllGroupList )
    )
    > 0

As to your second question, the hard coding on the vCLIENT is mainly out of a desire to be certain on the security filtering because of not 100% trusting the measure filtering in Roles.

I had the vCLIENT filtering dynamic previously and if I do that and rely on only 1 security role then I don't have an issue because I can enable RLS on the bidirectional cross-filtering relationship.

This is probably the route I will end up going but I was hopeful the other solution could be made to work.

My updated file with the new Role filter on vMEMBER is attached.