Forum Discussion
Helper IIHow do I define Permission Level when publishing an app and specifying a specific user or group
I want to publish an app from a workspace, and I want to deploy the app to a specific group who won't have access to the workspace, but will have access to the app.
The dataset is a shared dataset from another workspace.
The dataset has role security applied.
When I deploy the app and specify the group name who this app will be deployed to, I want to define their permissions as "Contributor" so the RLS does not take into effect in this app. (This app will be high-level benchmarking counts without detail). I see if I add the group to the workspace I can assign them a permission level, but when I push an app out to them, I cannot. I do not want this group to have "Read only" permission to the app, because then RLS will take into effect and the app will be pointless.
Gurus! Help?
Trying to bypass RLS is your problem. Its a security system designed to prevent bypassing, because it would be a security flaw otherwise. Taking into account your other thread, i'd suggest you need to use a superuser role in your model to negate the RLS for this user group. You are very much trying to bend Power BI into a weak security model that it simply doesn't allow. Its not that Apps aren't right for you, its that you can't bypass the security (and for good reason).
Apps are designed to be the live consumption area.
Workspaces are your draft/collaboration area.
Power BI desktop is your development space.
13 Replies
Adding anyone to the App is designed to be for "report consumers". Adding them to the workspace as a contributor is exactly as its described, it expects them to be a developer.
The purpose of row-level security is to ensure anyone accessing the dataset cannot do so without first being given a role. What you are doing is trying to circumvent row-level security. This is difficult for a reason as it would be a security flaw.
You are best off having a role created in your row-level security such that you can add the group in.
omacoderOk- maybe a better question is-- when publishing the app and specifying a group to push the app out to, what role do they get? You mention "report consumers".
For comparison purposes, what role is comparable in the permissions of a workspace?
- Admin?
- Member?
- Contributor?
- Viewer?
It seems that after Jul 2019, a whole new realm opened up that is really fubarring our implementation.
It seems the best practice has, after that point in time, shifted from using apps back to using workspaces with the addition of the viewer role, since the viewer role of a workspace can now handle RLS, where the workspace before wasn't able to handle RLS?
Apps within workspaces do not have roles as the user does not have permissions to anything outside of what the report provides. When publishing the workspace app, you also get to detiremine whether they can have access to the underlying dataset.
The Roles in workspaces exists because those users are developers, and access to materials needs to be specified depending on what role that person is playing in the development. Roles don't make sense in the workspace app, as the users are essentially "viewers" of the data.