search

microsoft / coe-starter-kit

Other
743 stars 219 forks source link

[CoE Starter Kit - Feature]: Set permissions of flows in solutions #3661

Open fredrikhr opened 2 years ago

fredrikhr commented 2 years ago

Is your feature request related to a problem? Please describe.

When opening the Set Flow Permissions app, the app tells me

Flows in Solutions can only be deleted or assigned new owners. They cannot have other permission types edited programmatically

Describe the solution you'd like

Since I am totally able to modify permissions of a flow via APIs in Dynamics 365 CRM, I'd like the app to be able to this for me. The Web UI distinguishes between two permission types (other than being the owner)

Describe alternatives you've considered

By applying my own customization to the Process entity, I have created a view All Modern Flows. When opening this view by using the link https://<coe-environment-url>/main.aspx?forceUCI=1&pagetype=entitylist&etn=workflow I am able to select a flow and use the Share command from the command bar.

Additional context?

The Dynamics 365 CRM Web API supports the unbound action ModifyAccess which can be used to modify permissions for flows stored in Dataverse (i.e. flows in solutions), given that you have the entity id of the workflow and the entity of the team or systemuser you want to assign permissions to.

I have determined that the following enum values in the AccessRights type declared by the Dynamics 365 CRM OData CSDL map to the Web UI permissions on the flow details page:

The ModifyAccess action takes two parameters:

  1. Target: The target entity as an OData entity-reference.
  2. PrincipalAccess: A mscrm.PrincipalAccess complex type value, i.e. represented in JSON as an object with two properties:
    • Principal: An OData entity-reference to a systemuser or team entity
    • AccessMask: An AccessRights enum value as described above. This is treated as a flags value, i.e. comma-separating multiple enum values is allowed, e.g. ReadAccess,WriteAccess
Jenefer-Monroe commented 2 years ago

You have tested this against flows that are part of a solution? If so we can put this on the feature backlog

manuelap-msft commented 2 years ago

PS: Have you also tested this cross-environment, so changing permissions of a solution flow in a different environment?

fredrikhr commented 2 years ago

You have tested this against flows that are part of a solution? If so we can put this on the feature backlog

@Jenefer-Monroe, is it possible to have a workflow entity in Dynamics 365 CRM that is not part of a solution (wouldn't that always be part of the Default solution automatically)?

PS: Have you also tested this cross-environment, so changing permissions of a solution flow in a different environment?

@manuelap-msft You'd have to invoke the ModifyAccess action in the environment in which the workflow entity is stored.

So I guess if we talk about implementation you'd need to use the legacy CDS connector (IIRC it can talk across different environments?) to do this. From the PowerAutomate management Get flows action you get the environment, by asking PowerAutomate about that environment you get the Dynamics 365 Instance URL. From the PowerAutomate flow information you can then search the workflows table for an entity where the workflowidunique attribute equals the PowerAutomate flow Id (annoyingly called the name of the Flow).

I am unsure whether the legacy CDS connector has the capability to invoke the ModifyAccess action. If not you'd have to either augment the PowerAutomate management connector or create a custom connector to invoke the onBehalfOfTokenBundle endpoint https://api.flow.microsoft.com/providers/microsoft.Flow/environments/<environment-id>/users/me/onBehalfOfTokenBundle?api-version=2016-11-01 and subsequently use the Http connector to invoke the Dynamics 365 API.

manuelap-msft commented 2 years ago

Thanks for the feedback - we'll add this to our backlog!

We are not going to add further dependency on the Dataverse (legacy) connector as it has been marked as deprecated. We're waiting for the current Dataverse connector to support environment selection (querying cross-environment) and once that is available, we'll re-evaluate this ask!

PS: Thanks for the very detailed investigation and information here, this is very helpful when we'll look at implementing the feature - we'll already be halfway there :)

fredrikhr commented 2 years ago

The onBehalfOfTokenBundle endpoint I am referring to is a PowerAutomate Web API endpoint that is used by the PowerAutomate Web Portal to obtain access to PowerApps, APIM, Graph and Dataverse on behalf of the user so that the Web Portal can do these modifications. The process I am describing is essentially what the Web Portal does internally when you click on Edit Owners in the Web Portal.

If you can, maybe you can ask whoever owns the PowerAutomate connector to add this action to their backlog?

FWIW, waiting for cross-env capabilities on the modern Dataverse connector make sense to me, as well as choosing not to do any new feature work that relies on the legacy connector.

Jenefer-Monroe commented 2 years ago

Appreciate your detailed work here. It's very helpful!