Improve incident permissions

Release notes

Problem to solve

We've introduced incidents as an issue type. For a first pass, permissions were set to the same level as for issues, meaning any guests in a project can create an incident. While this is useful for certain projects/applications, it can also cause problems for others. Primarily, we're finding that guest users are creating incidents that project owners don't actually think should be incidents.

Intended users

User experience goal

  • Short-term: define a more acceptable permissions level for incident creation
  • Longer-term: explore more flexible ways for people to set permissions for certain actions in the incident management workflow, including for creating incidents.

WIP Proposal

Short-term

In the near-future, we've decided to increase the permissions level for creating an incident to Reporter. This will hopefully limit the number of "false incidents" that are being created for those teams using incidents. That work will happen in: #336624 (closed).

Longer-term

It's likely that, whichever permissions level we set incidents to (and the other incident management features generally), a single, hard-coded permissions level won't work for all teams. So, we should start working towards allowing people to define the permissions levels that work for them.

While it might be nice to introduce a fully flexible way for people to define permissions by role or by feature, introducing that concept within GitLab would likely require a very large re-working of our current model for handling roles/permissions.

With that in mind, we're exploring more of a MVC way of tying permissions for interacting with specific feature sets to targeted groups of users, called Teams. That could look like this:

Team page Editing team members Adding new team members
Permissions_by_team Edit_team Add_team_member

For the MVC:

  • We would introduce the concept of teams. People can add members to these pre-defined teams. Team members would have the ability to interact at a pre-defined permissions level with a designated feature set. (For example, the incident responders team would have a default role of developer and they would have that role for the incident management features only).
  • We would also introduce the ability to restrict access to those features to that team only (ie, everyone who isn't a team member would have read-only access to those features only).
  • The "teams" would initially be defined by us, not by the users. That would allow us to tie the permissions to specific feature sets. In the future, we could allow people to create their own teams, and tie those teams to specific features.
  • The permissions level assigned to team members would also not be editable for the first pass. But, in future, we could allow those permissions to be editable, as well. (Which could, perhaps, look like this.)
  • The functionality would live at the group level, and would cascade down to all projects within the group.

This approach would allow us to start iterating towards a more granular permissions model without needing to jump directly to a full re-working of our current roles/permissions models.

Further details

Permissions and Security

Documentation

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Figma file for exploring more granular permissions model

Edited by Amelia Bauerly