Feature Request: More granular permissions

[MS]

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.

[Josh Campbell]

Hey MS thanks for the feedback we really appreciate it! I've added you as a +1 to a backlog ticket we have for an audit log. I don't have an ETA for you on that but it's on our radar.

Have you checked out our config as code feature by chance? Managed components can only be updated by modifying a `compass.yaml` file in a component's repository effectively limiting edit access of a component to the repository owners. It is not a read-only user account role like you're asking but it's worth looking into if you haven't yet!

I've captured your ask for a read-only role, as well. I'd love to know if you check out config as code :)

[MS]

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.

[Jack Ukleja]

@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?