Since: 2.5.8 Jira hosting: Cloud
Since: 2.5.8 Jira hosting: Cloud
Why The Scheduler needs the ADMIN scope? The "admin" scope is required while accessing Jira workflow resources, so The Scheduler needs it to provide ability to set initial issue status of recurring tasks. Here you can read more about scopes: https://developer.atlassian.com/cloud/jira/platform/scopes/ |
Set issue status on scheduled issue creation - now you can change the status in which issue will be created!
If you use kanban boards, this will save you lots of nerves - just set status from your 1st board column eg. "Selected for Development", when the time comes, issue will be placed in correct column.
With ability to set issue status, you can use The Scheduler as a templating too, and create tasks 'In progress', when you start working on task.
This feature requires you to manually update the app, if you don’t see this feature, ask your Jira Administrator to update app. |
On the 2nd step of the wizard, you will see new field “Initial issue status”, by default it will be set to the first status after issue was created - nothing changes. But if you would like to set the issue in other status, then just expand the dropdown to see available statuses. The Scheduler check into which status issue can be transitioned from 1st state. Eg. if you have advanced workflow and you want to move issue from 1st status to some x status, which is not available after create - it won’t be visible.
Feature not available in next-gen projects. When apps get access to workflows, then we will do our best to implement this feature. Looks like there are some ‘In the works’ changes related to workflows, we are monitoring the situation: https://www.atlassian.com/software/jira/whats-new/next-gen#intheworks |
Here is an example, where issues can be transitioned to any status. As you can see all statuses are available:
(In dropdown list you can see some icons next to status, don’t worry if you don’t see any. It can be easily set by Jira Administrator in administration section “Statuses” for each status)
In the preview of Scheduled Issue, you will see the status in which issue will be created, it’s a good practice, to include info about it in description or name of SI, to warn other users of the app about it
When issue gets created, it should be created in desired status “Selected for Development”
Remember that within each project, each issue type might have different workflow, so available statuses in dropdown might change.
If you use conditions and validators on workflow transitions eg. you don’t specify required field (e.g because it is not presented on create issue screen) app will fail to transition issue, but issue will be created. We decided it is more important to “create task on time” with default status, than not create it at all. If transition fails, it will trigger a notification of incomplete execution, make sure to set fallback recipient: Scheduler Notifications |
This feature is also available in subtasks, so if you would like to schedule issue with subtasks, you can set different statuses for each of them.
Setting initial status on scheduled issues, makes The Scheduler a great tool for templating repetitive tasks, which can be triggered manually.