Types of properties
Property Level | Description | Visibility |
|---|---|---|
Mattermost level | These are defined by “Mattermost” like status and assignee which are essential for a product like Playbooks to function. | If the system admin is unable to change these properties, and even unable to link them to AD/LDAP, these should be hidden to avoid confusion. |
System level | These are custom properties defined by the system admin in addition to “Mattermost” level properties that are then propagated down to the object (i.e. Playbooks, Boards). | These would be visible at all configuration levels below, though locked at any level below the system console. At most the user can change the property values of these if allowed by the system admin. |
Team level | These are custom properties defined by the team admin in addition to “Mattermost” and System level properties that are then propagated down to the object (i.e. Playbooks, Boards) of that respective team. | These would be visible at all configuration levels below, though locked at any level below the system console. At most the user can change the property values of these if allowed by the system admin. |
Object level | These are custom properties defined by the object admin in addition to “Mattermost”, System level, and Team Level properties living on the object. | These would also be visible at the object level. |
Mattermost level and system level properties
The ones locked are Mattermost level.
The ones unlocked are added by the system admin.
Team Level Properties
The ones locked are the mattermost+system level properties, and the one unlocked (Incident Type) is a property added at the team level.
object level
The ones locked are the mattermost+system+team level properties, and the one unlocked (Severity) is a property added at the object level.
Allow modification to property values
Higher level user types can define whether the property values they define (particularly for Select and Multi-select) can be modified by others on the system.
This is with the “Allow changes to options” menu toggle on the property itself.
This allows people at the lower levels to:
Add, Edit, and Remove values.
Only the user role that has access to the property can enable or disable this option.
So if a system admin has enabled this option for all users.
A team admin cannot restrict it at this own team.
He can however create a property at his team level and restrict it.
So once enabled, even if the property is locked, a person should be able to click on the plus icon to add more options to the Select property.
Clicking on the plus would allow Team admins and Playbook admins as an example to modify what values display on the playbook.
Specificity takes priority
So system level property options can be overriden by a team admin.
And a team admin level property options can be overridden by an object owner.
i.e.
If a system admin sets a status value as:
In progress and Complete
Yet the team admin goes and updates that to:
Triage, In progress, Resolution, and Complete
All Playbooks in that will respect that override.
And if a playbook owner at the object level updates this to include:
Triage, In progress, Mitigation, Resolution, and Complete
All runs created by that playbook in that will respect that override.
Exceptions for “Allow new options”
This permissions model and infrastructure probably works for various levels of objects i.e. Boards, Playbooks, Channels, etc, but it doesn’t work for User Profile Attributes.
For example, if we allow Team A to override a property value to be “Red, Green and Blue”.
And if Team B overrides it to “Yellow, Green, Black”.
We would have a conflict at the user’s settings if the user belongs to both teams, and we’ll have to figure out what to show.
Thus, the proposition for User profile attributes is to not have this option available.