WIP: More granular feature level permissions

[dabeeeenster]

Overview

Where larger teams are working on a single Flagsmith Project, it would be useful for them to be able to assign RBAC privieldges based on a subset of Flags within the Project.

Potential Solution

The current proposed solution involves leveraging the tags that already exist within the platform. We would add the ability, when modifying the permissions for a group in an environment, to add a subset of tags that that permission / those permissions apply to. For example, you may have a group of users that should only have the 'Update feature state' permission against a subset of tags. One UI option to illustrate this is to add the ability to add tags below each permission, as per the following screenshot.

Detailed Example

TBC

Issues/Open Questions

• Who defines what tag a Flag is associated with?
• Would this require a new concept of 'Roles'? Currently we only have the concept of groups which means that users will likely belong to more than one group.
• Is there a way we can allow existing customers to migrate?
• Should we have a setting against the project which enables these tag-based permissions for the project?
• Should we only allow the management of tag based permissions for a group? This seems to make sense since customers that want to use permissions on such a granular level are likely using groups exclusively anyway.

Other Possible Approaches

Environment / Feature Combination Level Permissions

The tags approach makes the management of the permissions slightly simpler, however, it may not be the best solution for creating the most granular permissions. Another option here would be to allow admins to create permissions for groups (& users?) against a combination of a feature and an environment. The UI management of these permissions would be challenging but it would likely allow admins to create more granular permissions as needed.

[matthewelwell]

Some thoughts based on a conversation with @gagantrivedi .

1. Initial idea was to have 'tag based permission' be opt-in and, if enabled, the Update Feature State permission at the environment would be ignored. There would be View / Edit / Delete permissions on each tag. This is deemed to not be a viable solution as it would be hard to apply these permissions to individual environments, since the tags live at the project level.
2. Second idea (which is as per the screenshot in the description) is to add tags to a role. These tags could be added to environment / project roles such that the permissions are only given to features with those tags applied.

Next steps: start implementing option (2) above and see where it gets us :)

[dabeeeenster]

Yep agree - leveraging roles seems the right path here

[gagantrivedi]

I will set up some time with @novakzaballa to go through the backend implementation done here: 78e559c

[novakzaballa]

Since there is not too much information about the behavior of this feature in the final implementation, I have the following assumptions:

1. If a role has one or more tags linked, then and only in that case, the feature permissions(Update feature state and delete), associated with that role, only apply to features having those tags. In other words, adding a tag to a role restricts the feature permissions to features having the same tag.
2. In any other case, the permissions work as before these changes. For example, a user with update_feature_state and/or delete_feature permissions, or belonging to a group with these permissions, should be able to update/delete the feature regardless of whether the feature is tagged. The same applies if the user has a role with these permissions and no tags associated.

Since these points are not met, I created the following issues.

#4288
#4287

CC: @matthewelwell @gagantrivedi @kyle-ssg

[matthewelwell]

As discussed on a call with @gagantrivedi , @novakzaballa and @kyle-ssg we have decided on a few outcomes:

1. Roles with a tag should only be able to include permissions that factor in tags on their target entity, i.e. those in the constants defined here and here. This means that, when a tag is added to a role, the FE should disable any other permissions to prevent them from being added. The API should reject the creation of any role with a tag that has unsupported permissions. The API should return this information in the response to the /<entity>/permissions/ endpoints (where entity=projects|environments).
2. We will need to extend the functionality to also support 3 new permissions: CREATE_CHANGE_REQUEST, APPROVE_CHANGE_REQUEST and MANAGE_SEGMENT_OVERRIDES.

Another topic was discussed was around the security of tag-based permissions. The issue arises due to the fact that anyone with the CREATE_FEATURE permission can add any tag to any feature. An immediate solution to this is to encourage customers to restrict the CREATE_FEATURE permission to project admins for example. Some discussion points regarding a more permanent solution:

1. Add the ability to assign tags to groups (or maybe roles but this would likely spark confusion with the rest of the behaviour discussed in this issue) so that only users in that group can add those tags
2. Add rules to tags to allow them to only be added to features with a given naming convention (an extension to this could be to automatically tag features with a given naming convention).

[kyle-ssg]

I believe this can be closed