...
In this system incidents are directly tied to a specific team and channel. This could be an existing channel or a new one.
This can be implemented with existing permissions constructs without requiring extension of the Mattermost server. Further extension is talked about discussed below.
Public Incidents
Public incidents are incidents where anyone with access to the team the incident channel is created on can join the incident as a participant by joining the channel the incident is in. Anyone on the team can join the primary channel and become an incident participant. Just like public channels, public incidents appear for everyone in the team they are created in.
...
System + Team Admins | Incident Participant | Incident Observer | In Team, Public Incident | In Team, Private Incident | Not in Team | |
See incident in lists | Yes | Yes | Yes | Yes | No | No |
Join Incident | Yes | Yes | No | No | ||
View checklist items | Yes | Yes | Yes | Yes | No | No |
Modify Incident Properties | Yes | Yes | No | No | No | No |
Playbook Permissions
Team Based
Team based playbook permissions would associate playbooks to teams. If you have access to the team the playbook is on, you have access to the playbook. Playbooks are associated with one team.
Ownership Extension
The creator of the playbook would become the owner. Ownership would be able to be transferred and optionally there could be more than one owner. Primarily the owner would determine your ability to edit the playbook. Additionally features could be built on top of ownership for retrospective features and notifications that the playbook has been used.
Channel Based
Playbook permissions can follow a similar model as incident permissions. When a playbook is created, a channel is created with the playbook name on a specified team. Anyone with access to that channel can edit the playbook. The channel can be a public or private as above. This encourages orderly discussion about the playbook and allows for features like linking back the channel every time the playbook is used.
This allows us to leverage the advanced permissions system with little effort. For example if a customer wanted to “only allow users in the Security LDAP group to view and access security-related workflows unless others are explicitly added” they could do this with the advanced permissions features on that channel.
In addition you can also create a “draft” playbook that only the author can access that has no channel attached. Later the draft can be published for others to use.
...