Find everything you need to get certified on Fabric—skills challenges, live sessions, exam prep, role guidance, and more.
Get startedGrow your Fabric skills and prepare for the DP-600 certification exam by completing the latest Microsoft Fabric challenge.
After Applying Row Level security I had to make a few changes to the interactions between tables, but everything worked fine.
However, once I published to the service a dropdown filled with portfolio names suddenly showed ALL available report names.
Row level security still hid MOST of the data, resulting in errors in the visuals when selected, but not all.
It seems the service (app.powerbi.com) doesn't quite handle the row level security the same way as the desktop.
Because of this, I added a filter on to the drop down to remove the additional rows from the drop down so that the users couldn't select items they were not supposed to see as a temporary measure.
This has mostly worked, though I would prefer not to have this filter on and the row level security to work as it does in the desktop app.
What's more, one user cannot see anything in the dropdown with the filter on (even though I've checked how his user principal etc is showing and it is all fine)
Some of the way we set things up originally worked fine until we applied row level security, after that it didn't like some of the joins and the like so we have made a few changes, removed joins and added measures as filters and the like.
Some information about the set up:
Table - Client Details: Central Distinct List of clients, portfolios, ids etc
Used in Drop Down
Joins - 1-> many across most tables to filter by Portfolio Id
1 join BI-directional to "User Portfolios" which is used in row level security
Due to Drop down not filtering out portfolios in web service added a measure as a filter (detailed below)
Table - User Permissions: UserEmail (w/o suffix) and Portfolio Id
Has row level security applied to it:
In desktop mode this filters all tables and drop downs
As it does not seem to work when published I also added this:
PortfolioFilterNoSuffix = CALCULATE(COUNT(UserPermissions[EmailNoSuffix]), FILTER(UserPermissions,UPPER(UserPermissions[EmailNoSuffix]) = UPPER([UserEmailNoSuffix])))
And then the clientdetails drop down was filtered by > 0, however, I have just tried "not blank" to see if it resolves the user issue (pending response)
Table - DistinctDates: Distinct list of dates across reporting tables
Joins 1 to Many to Reporting Tables (by date)
Joins both directions to ->
Table - DistinctDatesClient: - Distinct list of Dates per client
Date used in drop down
Hi @Davidian
I have not experienced the same issues that you have experienced with regards to re-level security What I would recommend doing is making sure that you have followed the row level security best practice. In doing so in doing so that should work as expected, especially when using the drop downs and slices.
I would recommend following this blog post from Kasper which you can test to see if it works as expected: Power BI Desktop Dynamic security cheat sheet - Kasper On BI
Forgot to say - thanks for what you have supplied - I have been playing and it allowed me to notice something else that I didn't realise about power bi and our internal system.
The perms DB as EMAIL and doesn't have UPN but UPN is the same as EMAIL for MOST people but as a fallback I also had UN in there which is in the perms DB - but once you publish to webservice it doesnt use the local UN it basically becomes the UPN lol
So, I am getting the UPN loaded in to the DB and then will update the tables etc and see if that fixes the RLS issue with the drop down still needing a filter on it once published to web and come back to you.
Cheers!
Join the community in Stockholm for expert Microsoft Fabric learning including a very exciting keynote from Arun Ulag, Corporate Vice President, Azure Data.
User | Count |
---|---|
54 | |
39 | |
33 | |
31 | |
25 |