Forum Discussion
RLS and USERELATIONSHIP problem
Hi ju97,
Thank you for bringing this issue to our attention. We understand that the error related to the UseRelationship() and CrossFilter() functions has recently impacted your report, despite it functioning well previously.
As this is a known issue that is currently being addressed, we are unable to keep this thread open indefinitely.For official updates, you can check for more information through the provided link : Known issue - Reports that use functions with RLS don't work - Microsoft Fabric | Microsoft Learn
In the meantime, if you continue to experience difficulties, we kindly encourage you to create a new thread. This will allow us to assist you more effectively.
Thank you for your understanding, and please know that we are here to help!
Best regards,
Atheeq.
A note that while the TREATAS function will give you the same result, the performance will be much slower than USERELATIONSHIP. TREATAS is creating a "virtual" relationship which is more compitationally intensive. This may not matter if your model is small, but if you have a complex model (like I did) this would not have been feasible.
In my case duplicating my dimensional table which had the RLS applied to it, one time for each role, and then using an active relationship to my fact tables instead, worked great and actually improved the performance of my model. Dimensional tables are usually small so the duplication did not increase my file size much at all.
Thank you for your reply. Performance is very important in our organization. Therefore the TREATAS function is not a solution for us unfortunately. Also the second solution not. It is perhaps too difficult for me to explain in short. Our situation: There is one group of people who can see everything and a second group who can see everything EXCEPT one table which they cannot access. The optional relationship between that special table and the fact table is essential because otherwise the second group will not see anything at all because Power BI always actives all relationships. Even if you do not select an item (column) from a table. So it's like 'all' or 'nothing'.
The USERELATIONSHIP was perfect for this.
Performance is indeed important but if your model is small (relatively) or your measures are very simple, you may not experience any degradation in performance. I'd advise you to try the TREATAS solution first on a few measures as its quite simple to implement, and see the impact on performance.
If the impact is large, I'm happy to help but I don't understand your situation. Can you provide screenshots of your model / more details on your setup and RLS needs? "The optional relationship between that special table and the fact table is essential because otherwise the second group will not see anything at all" - did you mean to say the first group in this sentence, rather than the second group? I'm guessing you are activating the relationship to remove data for your second group?Thank you. Yes.... you are right. I meant the first group. (sorry)
Here a explanation in short in the most compact way I can.
If you know a solution it will be very much appreciated.
But like everybody is saying: It was working perfectly fine before. Therefore I'm still hoping Microsoft Power BI developement team will be able to fix the issue asap.
THANK YOU
Hi,
I am still not sure I fully understand your case, but I think the measure should look something like this. It generates a numeric value. You can either apply a filter on a visual saying value>0 or not. Maybe this helps you.
MeasureToUseAsFilter =/*Apply this measure to the desired visual set to be greater than 0Value Blank in the security dim is the situation where securitydim is not used.*/VAR SelectedSecuritydim = SELECTCOLUMNS(Security_dim, "id", Security_dim[dimId])RETURNIF(COUNTROWS(SelectedSecuritydim)=0, --This is the case when selecting blank in the Security_Dim1,IF(CALCULATE(COUNTROWS('Fact'),'Fact'[dimId] IN SelectedSecuritydim) > 0, 1, 0))hi there,
I did some testing and I believe it is working. THANK YOU
You need to create a new "Dimension" as a security dimension as a workaround. If you understand.
Unfortunately, MS thinks this was a bug before; and now its solved. I'm as frustrated as you but I understand the security breach before, in terms of RLS and OLS, I think. Whatever, you have to solve it with an intermediate table if that makes any sense to you.
