The Add or remove watchers post function automatically adds watchers to the current, parent, selected or any issue returned by a parser expression. The list of watchers to be added or removed can be configured.
You can retrieve users from various sources such as an existing field, project role, or group.
Configuration
Use cases and examples
Use case | JWT feature | Workflow function | Use case description | Complexity |
---|---|---|---|---|
Add a comment with links to attachments that were just added | Add comment | A comment will be added to the current issue with links to the attachments included recently. | BEGINNER | |
Add a sub-task's summary and key to the description of its parent | Update fields | When a sub-task is created, its summary, issue key and date, and time of creation will be added to the description of the parent issue. | BEGINNER | |
Add comment when rejecting an issue | Add comment | When an issue is rejected, a comment will be added to the current issue mentioning the reporter. | BEGINNER | |
Add formatted comments automatically | Add comment | Add a formatted comment to the current issue. It would be convenient in case that you need to create a table or highlight some important points in the comment. | BEGINNER | |
Add three days skipping weekends automatically to a Date Picker | Add three days to a Date Picker field from the current date. | BEGINNER | ||
Add watchers from another field | ||||
Alert the assignee of an important issue | Send email | Send an email to the current assignee only if the priority is set to "Highest" or "High". | BEGINNER | |
Alert the assignee of important issues | Add comment | Add a comment to an issue mentioning the assignee. The comment will only be added, if the issue priority is set to "High" or "Highest" to ensure that the assignee will only be alerted for the important issue | BEGINNER | |
Alert the reporter | Add comment | Add a simple comment to an issue mentioning the reporter. This use case might come in handy if you don't want to use extra events in your notification schemes to notify specific users - like the reporter. | BEGINNER | |
Assign an issue to the project lead, if the issue is unassigned on creation | Update fields | When an issue is created without an assignee selected, the issue will be assigned to the project lead of the project. | BEGINNER | |
Assign an issue to the user who last commented on it | Update fields | Assign the issue to the user who last commented on the issue. | BEGINNER | |
Assign important issues to the project lead | Update fields | Automatically assign and issue to the project lead. Issues will only be re-assigned if the priority of the issue is set to Highest to make sure that only important issues are being escalated. | BEGINNER | |
Automatically create a version when starting the release | ||||
Automatically link an issue to an external one | ||||
Automatically log work on a Jira issue | ||||
Auto-transition when related issues are in a specific status | Transition issue | Automatically transition issue, if all linked issues are in specific status. | INTERMEDIATE | |
Block a transition based on issue links | Evaluate issue links and hide transitions based on the outcome. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | ADVANCED | ||
Block a transition based on sprint information | Make sure that an issue is not in an active sprint. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
Block a transition based on the day of the week | Block transitions on weekends or any other day of the week. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
Block a transition if a predefined field value has not been changed | Evaluate a Date Picker field and block the transition if it has not been updated. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
Block a transition if some issues under an epic are not in a certain status | Check whether an epic has all issues under it in a certain status. This is particularly important if you want to block an epic as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
Block a transition if the type of the attached files is incorrect | Evaluate the type of files in the Attachments field. This use case is valid for both conditions and validators . The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
Check current issue status | Check whether the current issue is in a particular status. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
Check for at least one component | Require a at least one component. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
Check for unresolved sub-tasks | Check whether the current issue has any unresolved sub-tasks. This is particularly important if you want to block a parent issue as long as work is still being done on related sub-tasks. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
Check if an attachment was added recently | Make sure that the current user has uploaded a attachment during a definite period of time. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | BEGINNER | ||
Check parent issue type | Check whether the parent of the current issue is of a certain issue type. This is particularly important if you want to reuse a workflow for multiple sub-task issue types but only want a transition to be available if the sub-task belongs to a certain user story or a bug. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
Check the number of times that a field has changed | Check the number of times that a field has changed. This use case is valid for both conditions and validators. The only difference is that you can specify an additional error message when using a validator. | INTERMEDIATE | ||
Copy field values from epic to issues under it after creation | Update fields Transition issue | Copy the values of the fields defined in the Update fields post-function to the issues under the epic after their creation. | BEGINNER | |
Copy labels of a sub-task to the parent issue upon closing | Update fields | When a sub-task is closed, the labels of the sub-task will be added to the Labels field of the parent issue. | BEGINNER |
If you still have questions, feel free to refer to our support team.