How do I define Permission Level when publishing an app and specifying a specific user or group

[omacoder]

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?

[Anonymous]

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.

[omacoder]

Ok- 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?

1. Admin?
2. Member?
3. Contributor?
4. 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?

[Anonymous]

So to be clear here.

If your users are developers and their purpose is to assess in the creation/development of the report in any way, add them to the workspace and assign the appropriate role.

If your users are consumers and their sole purpose is to make use of the reports you have produced, place them into the App permissions.

[omacoder]

Ok-

We would like to use the App feature, but I believe the problem is that we have two levels of "Report Consumers".

One group of people who should have read only to the reports, no access to underlying data.

One group of people who should have contributor access to the reports which bypasses RLS, with access to underlying data, who can copy reports into their own workspaces.

It sounds like, with Apps, we cannot accomplish this and all of our report consumers will still need to do their consumption within the workspaces.

[Anonymous]

@omacoder  yes thats correct. Apps are not for changes, they are consumer only.  Workspaces are exactly for that and those staff will need Pro Licenses.  Apps don't need Pro licenses if you have the workspace on premium.

[omacoder]

Thanks... still confused. All of these individuals are consumers and should not be making any changes.

That's why it still seems appropriate we should be using apps and not giving them access to the workspaces.

But because we apparently cannot customize the level of a consumer in an app like we can in a workspace, we are left with no solution.

[Anonymous]

What you have described is exactly what Apps is for.  They just have read only access, unless you tick the box that lets them have access to the underlying dataset.

If you give them app access only, all they get is read-only.  App users are always just consumers. No role to pick, because there are not other appropriate roles.  Roles only make sense in workspaces where developers are.

It seems like apps are what you want, but you are getting caught up on wanting to pick a role but roles make no sense here because there is only lowest possible permissions by default.

[omacoder]

Thanks. I'm getting caught up in the video from Jul of 2019 from 2 guys in a cube with the release of the read only role in workspaces and that we no longer need to use apps if we want people to just have read only access to the reports.

Also, apps won't work because I need 2 roles of an app:

1. reader role, which utilizes RLS, exactly like the workspace role
2. contributor role, which bypasses RLS, exactly like the workspace role, but they can share and use the underlying data set through an app

[Anonymous]

Your App should be for your readers, your workspace should be for your contributors.

The ability to "publish the app" allows you to hold back changes until you are ready to release them for the viewing audience.  This lets your developers make changes to the report (not the model) and discuss those changes, seek approval etc.  Once the changes are approved, you publish the app and only then do your readers get the new version.

Putting your users into a read-only role into the workspace, means they will always see the draft changes to your reports instead of the last "live" version.  The read-only role should be used by content approvers where you wish to restrict to read access.

[omacoder]

We would like to utilize apps so that the workspaces can be the "pre-prod" staging area.

However, seeing that an app doesn't allow a contributor role like the workspace does, App functionality just isn't going to work for our use case.

I need a way to bypass RLS in an app role, just like you can with a specific Workspace role. Until then, these consumers who need to consume reports cannot consume their content via an App because RLS is applied. These are regional managers consuming the conent who should have access to 100% of the rows, for this report.

[Anonymous · Accepted solution]

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.

[Anonymous]

To assign custom permissions rather than standard roles, click Customize permissions in the Roles section when adding or editing the user account.

To enable a permission for the user, toggle the box to the appropriate setting.

[Anonymous]

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.