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.
...
...
Types of properties
We should support the following properties in Playbooks by default.
Implicit (these won’t be available as options)
Status and Assignee
Explicit (these would be available as options)
Text
Select
Multi-select
Person
Multi-person
Link
...
How do properties behave
Something created at higher levels will be locked at the lower levels.
Lower levels can change an object’s visibility, or decide to turn off “Allow changes to options”.
Menu dropdown for properties
...
Menu dropdown for properties when they are locked
...
| Info |
|---|
When allow new options is turned off at the higher level |
...
, users at the lower level can disable them. |
...
Adding select or multi-select options
A user can click the plus button to start adding a value.
...
Editing an option
Clicking any of the values directly would allow users to remote, edit or change the color of the options.
...
Visibility option
Visibility: Choose whether the property shows in user profiles. Available options are:
Always showAlways hide
This hides the property from the run for all users, with the option to expand and see the hidden properties.
Hide when empty (default)
This hides the property when its empty from the profile popovers with the option to expand and see the hidden properties. As soon as the value is filled, this property will be shown by default.
Always hide
This hides the property behind an accordion from the run for all users, with the option to expand and see the hidden properties.
Any new property that gets created has a Visibility option of: Hide when empty.
Here you go can see the option to show all properties, clicking on which would show all hidden properties aswell.
...
Allow modification to property values
Higher level user types can define whether the property values they define (For Status, Select and Multi-select) can be modified by others on the system.
...
Add, Edit, and Remove values.
Only the user role that has access to the property can enable or disable this option.
i.e. This option would not be visible for system level select/status properties for a team admin/channel admin.
...
If that option is disabled, we would not see any plus button.
For status property
Clicking on the plus button for a status value allow Team admins and Playbook admins as an example to modify what status values display on the playbook, if the option of “Allowing changes to properties” is turned on.
The user can click on the plus symbol at the top to define which column the new value should go under.
For example:
...
Specificity takes priority while overriding
So system level property options can be overriden by a team admin.
...
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.
...
Thus, the proposition for User profile attributes is to not have this option available.
...
Decisions made by the design team
Something created at higher levels will be locked at the lower levels.
Options can be changed if allow options is turned on.
Visibility can also be changed at all the lower levels and cannot be enforced.
Any changes happening at the lower levels are not cascading back up, rather only down.
Allow lower levels (team) to decide whether “Allow for new options” should be turned off.e=
Assignee field for task update
Update assignee field to support groups.
...
Considerations
We should have the ability to publish properties from the bottom up as well.
Add the ability to reset override.