-
Notifications
You must be signed in to change notification settings - Fork 485
Description
How are you running Flagsmith
- Self Hosted with Docker
- Self Hosted with Kubernetes
- SaaS at flagsmith.com
- Some other way (add details in description below)
Describe the bug
The /projects/<id>/my-permissions and /environments/<id>/my-permissions endpoints return permissions in this format:
{
"permissions": [],
"admin": false,
"tag_based_permissions": [
{
"permissions": [
"VIEW_ENVIRONMENT",
"APPROVE_CHANGE_REQUEST",
"CREATE_CHANGE_REQUEST"
],
"tags": [
9635,
9589
]
}
]
}
This association between permissions and tags is not correct. Each permission is should be associated with a set of tags that it's valid for, but this response groups all tags and permissions together. It's not possible to tell which tags are being used for which permission(s).
Authorisation is still being enforced correctly by the API, but these responses cause the frontend to show incorrect permissions to users.
Steps To Reproduce
- Assign a user "View Project" and "Create Feature" permissions. These will be their project-level
my-permissions:
{
"permissions": [
"VIEW_PROJECT",
"CREATE_PROJECT"
],
"admin": false,
"tag_based_permissions": []
}
The user can then create and modify features as normal.
- Assign the same user "Delete Feature" permissions for only a specific tag. Now, project-level
my-permissionsreturns:
{
"permissions": [],
"admin": false,
"tag_based_permissions": [
{
"permissions": [
"VIEW_PROJECT",
"DELETE_FEATURE",
"CREATE_FEATURE"
],
"tags": [
9589
]
}
]
}Now, the frontend no longer allows editing this feature (ignore the unrelated permissions being returned here):
Expected behavior
Represent associations between tags and permissions correctly in the project and environment-level my-permissions API. Render these permissions correctly in the frontend.
Screenshots
No response