Support Basic Permissions

Description

Public & Private Playbooks

Playbooks may be created as public or private. Private playbooks are initially only visible to the creator, who may configure the playbook and add other users to manage the playbook. Public playbooks remain visible to all members of the team. Any playbook a user can see, they can edit, delete, invite other users to manage, or use to start an incident.

Playbooks have a configuration setting defining whether their incidents are public or private.

A configuration setting at the team level allows team administrators to restrict the ability to create playbooks to only team administrators. It defaults to true. When enabled, non-team-administrators may manage existing playbooks, but not create new ones.

Examples
  • Amy creates a private playbook in the core team that defaults to public incidents to organize a Mattermost server release. She invites Linda and Elisabeth to the playbook, allowing them to edit the template and manage who else can edit that template.

  • Daniel creates a public playbook in the private-core team that defaults to private incidents to organize a security response around an incident.

  • Paul creates a public playbook in the private-core team that defaults to public incidents to organize a customer support response escalation.

Public & Private Incidents

Incidents created without selecting a playbook now default to public, but can be made private by making the corresponding incident channel private from the channel header dropdown.

When creating an incident and selecting a playbook, there is no explicit option to choose if an incident is public or private: it always follows the playbook configuration.

Private incidents are invisible to non-participants: they do not appear in the RHS when active, nor anywhere in the backstage. Private incidents cannot be made public within the user interface (since there is no UI to make private channels public.)

Examples
  • As a member of the release playbook, Amy can start a public incident to track the upcoming Mattermost server release.

  • I can create a public incident, then choose to make it private to restrict access to other team members.

Refreshed RHS

Incidents are prioritized in the RHS, delineating incidents in which I am the commander, a participant, or a non-participant.

Examples
  • While on SET rotation, I am the commander of two incidents. When I open the RHS, they are emphasized.

  • I am also involved in a private security incident. After the incidents I command, it comes next.

  • All other public incidents on the team appear in the RHS.

  • We may want to surface incidents from other teams here, so that I don’t forget about context when I’m switching between teams.

QA Test Steps

None

Mana

None

Assignee

Jesse Hallam

QA Assignee

None

Reporter

Jesse Hallam

Fix versions

Mattermost Team

Workflows

Sprint

None

QA Testing Areas

None

GitHub Issue

None

Components

Epic Name

Basic Permissions
Configure