The current roles/permissions do not provide enough granularity for controlling access to components, metrics, scorecards, fields, teams, and templates.
We need another role in between `Full User` and `Product Admin` that allows for non-view permissions (create, update, delete) of these objects.
Any `Full User` can currently go in and change anything, even for components/metrics/etc that they do not own. Releasing this tool into our organization would quickly result in it becoming the "wild west" and we would never be able to trust or rely on the accuracy or standardization of the data.
This problem is further exacerbated by the lack of any audit log for objects...e.g user changed title of component X, user removed link from component y.
Thanks for the update.
We're unable to use config as code unfortunately, primarily because Gitlab Self-Hosted isn't supported.
We're looking at rolling our own version using the GraphQL API and the sullivtr/graphql Terraform provider, but that wouldn't gain us the "Managed components" status.
A potential alternative would be if there was a way to set/configure a component status to "managed", which would effectively remove the create/edit/delete operations for users in the UI. Perhaps another feature request for that, if easier than implementing a "read only" role.
@Josh Campbell what about at the API level? I see you have scopes, but can these actually be assigned to API callers? Will you add claims for access control to services/teams etc?
We're exploring options for implementing a more robust set of permissions policies for Compass objects (scorecards, components, custom fields, etc.). If you're interested in chatting about this, schedule a Zoom call using this link:
https://www.getclockwise.com/c/awilkes-atlassian-com/compass-permissions-exploration
Alastair