Table of Contents |
---|
Info | ||
---|---|---|
| ||
You will need the following JIRA plugins: Level: BASIC | INTERMEDIATE | ADVANCED |
Problem
Solution
Step 1
Step 2
.....
Table of Contents |
---|
Info | ||
---|---|---|
| ||
Power Scripts™ for Jira (server) Level: BASIC |
Problem
An issue should not be able to close if any of the child or linked issues is not closed.
Solution
One will need to add a SIL™ condition on the close transition which will verify the statuses of all dependencies (child and linked issues). If any of the dependencies is not already closed the condition will return false.
Determine which dependencies need to restrict the transition
For the sake of this exercise we will consider that all subtasks need to be closed in order to let an issue to be closed.
Add a new condition
Log in as an administrator and navigate to Administration-> Workflows and edit "Close Issue" transition on your Jira workflow.
Press "Add a new condition" link.
Select (k) SIL™ Condition and then press Add.
Writing the SIL™ code
The page Add Parameters To Condition appears. In the SIL™ code edit area insert the following code:
Code Block |
---|
// get all subtasks
string s_tasks=subtasks(key);
// process each subtask
for(string s in s_tasks)
// if subtasks' status is not closed the transition cannot be available and therefore return false
if(%s%.status != "Closed")
return false;
// if not failed yet then the transition should be available
return true; |
The page should look like this:
It is recommended to give the program a easy identifiable name in the Name field, press CHECK to verify the code and then Add to save the condition.
After saving the conditions of "Create Issue" should look like following:
Info | ||
---|---|---|
| ||
All you have to do now is to publish your workflow. See more at Activating Workflow section on Atlassian Documentation. |
See also
- Disabling inline edits in Jira
- Forbidding users to create some issue types
- Hide fields from users not in a project role
- Limit Number of Characters in Text Field
- Lock an issue - a better variant (Live Fields)
- Locking Issues
- Making an issue read-only
- Require User to Log Work Before Transitioning Issue
- Restrict issue type availability by user
- Restrict workflow based on status of dependencies
- Validator for component lead