Types of properties

Mattermost level and system level properties

The ones locked are Mattermost level.
The ones unlocked are added by the system admin.

Open

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.

Open

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

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 show

  • 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.

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.

i.e. This option would not be visible for system level select/status properties for a team admin/channel admin.

So if a system admin has not enabled this option on a system defined property, the team admin cannot enable it.
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 status or select property.

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.

Specificity takes priority while overriding

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.

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.