[FEAT] Multitenancy: Add AuthorizedTenants to Workflow Definitions

[sfmskywalker]

We propose adding a list of AuthorizedTenants to workflow definitions. This feature will allow tenants to start a workflow they do not own. They will be able to view the workflow in read-only mode and initiate it, but they will not have the ability to modify it since they are not the owner tenant.

Potential Extensions

If implemented, we could further enhance the authorization model by adding more detailed permissions to workflow definitions. For instance, this could enable:

• Allowing tenants to contribute to the editing of a workflow owned by another tenant.
• Defining specific roles and permissions for different tenants, thereby creating a more flexible and robust authorization system.

Benefits

• Increased flexibility in workflow management.
• Enhanced collaboration across different tenants.
• More granular control over workflow permissions.

Use Cases

• Tenants needing to start workflows that are not in their ownership.
• Collaborative environments where multiple tenants contribute to workflow development.
• Scenarios requiring detailed access control over workflow definitions.

[glime-ai[bot]]

To address the proposal of adding a list of AuthorizedTenants to workflow definitions, it's important to consider the current capabilities and future plans for Elsa Workflows as outlined in the provided context.

As of the latest information available, Elsa Workflows does not natively support multi-tenancy, but it is a feature planned for future releases. This means that the ability to restrict or allow access to workflow definitions based on tenant IDs is not yet part of the core functionality. However, the suggestion to add a TenantId column to all tables is a workaround that could be implemented by users on their own, as mentioned in one of the GitHub issues.

The proposed extensions for more detailed permissions and roles for different tenants would indeed increase flexibility and collaboration, but they would require significant changes to the current authorization model within Elsa Workflows. This could be a complex feature to implement and might be considered for future versions, especially since there is already a mention of workflow migration to new versions via UI on the roadmap.

For the use cases described, such as tenants needing to start workflows they do not own or collaborative environments, the current version of Elsa Workflows would require custom development to support these scenarios. This could involve creating custom activities or middleware that handle tenant-specific logic and permissions.

In summary, while the proposal has merit and could provide significant benefits, it would require custom implementation until such features are natively supported in future releases of Elsa Workflows. Users interested in this functionality should monitor the project's roadmap and contribute to discussions and development to help shape these features.

This comment was generated by Glime.