In a first post about workflow properties we already covered how to set a property in transitions. The status properties (properties of workflow steps) are described in this article. Among other things, they are suitable for restricting permissions in certain statuses, for example, which users are allowed to write a comment and when.
If you know status properties, you might be able to save the money an app for Jira. A basic knowledge is therefore worthwhile.
In contrast to the transitions, there are various variants of the properties themselves for the statuses. This is due to the fact that it is basically only one, but multiplied depending on permission and group, user, role, and so forth.
One elementary syntax for the status properties
The use case of properties in transitions is to restrict the permissions granted in a Jira project by permission schemes. This should be emphasized, because the permissions can only be restricted, but not extended. So, for example, if commenting is already prevented for the project role “QA” in the schema, this cannot be subsequently allowed via the workflow.
With a few exceptions, every permission property that is set follows the same syntax. This is:
jira.permission[.subtasks].{permission}.{userscope}[.suffix]- The first part “jira.permission” is fixed.
- Optionally, you can then restrict to subtasks. If this parameter is used, the property does not apply to the task itself, but to the subtasks as long as the task resides in the status.
- In place of {permission} is the permission you want to restrict. For example “create”, “comment” or “resolve” can be entered.
- In the place of {userscope} is the scope of the setting, which can define the set of users. For example, “group” can be used to restrict to a single group, “userCF” to restrict to users from a custom user field, or “projectrole” to restrict to a role.
- The “property value” is then for example the group name or the ID of a role (see example below).
- If you want to restrict a permission more than once to the same scope, you still have to specify a suffix. This is only a simple numeric value.
- A complete list of possible values for {permission} and {userscope} can be found in the Atlassian documentation.
Status Property jira.permission.{permission}.denied
In order not to reduce a permission to a certain scope, but to prevent it altogether, “denied” can also be specified in place of {userscope}. As the word already suggests, a permission is then not given to anyone. The “Property Value” field is then left empty.
Status Property jira.issue.editable
At this point, the property “jira.issue.editable” with the values (property value) “true” or “false” should be mentioned. With this property an issue can be set as editable – which is usually the case anyway. Or editing can be prevented. The latter can also be achieved by specifying “jira.permission.edit.denied”. Therefore the property is basically redundant.
An example for further clarification
The image above shows an example of how the properties for a status could be stored in Jira.
jira.permission.edit.group.1=jira-admnistrators
jira.permission.edit.group.2=qa-exception-handlers
When a task is in this status, it can only be edited by members of two groups. They must either be in the group “jira-administrators”, “qa-exception-handlers” or both.
jira.permission.transition.reporter=
Furthermore, the issue can only leave the status if the transition is triggered by the reporter (author). Without this person, or a change of the field by a member of the above mentioned groups, this is not possible.
jira.permission.subtasks.transition.denied=
The transitions for any subtasks are prevented. So these, if present, are all stuck in their current status until the parent issue has left its status.
jira.permission.comment.userCF=11038
The only people who can leave comments on the issue are those selected in the field with ID 11038. This is a custom field.
Note that some properties require a numeric value (e.g. userCF, groupCF or projectRole), while other values (such as user or group) are specified as names, and others are left blank – as seen above with “reporter” or “denied”. As described in part 1 on workflow properties, the IDs can be read from the URL, for example, when editing roles, fields, etc.
Describing here in this post how to set each property with its value is beyond the limits of this post. Trying and investigating the possibilities is recommended. We are happy to help with further questions – find the contact form here.