FAQ

Why can't I define a Trigger that is more frequent than an hour?

As of now, trigger definitions cannot be set to be more often than every hour. This is because we tried hard to find of a valid use-case that would require you to create a recurring JIRA issue more often than every hour and we couldn't come up with any. If, however, you believe you have such a use-case and you absolutely need The Scheduler to create issues more often than our imposed limit, please let us know and we'll drop that limit for you.

Why am I getting "Timeout" alert every now and then?

If you open one of The Scheduler pages in JIRA (like "Scheduled Issues" tab panel) and leave it open for
1 hour, you'll notice a warning alert asking you to refresh the page. This is because The Scheduler uses so-called JWT tokens to authenticate the communication between its server and your browser, and this token has a validity limit. Unfortunately, as of now, we cannot automatically extend its lifespan, which means that you will need to refresh the page after 1 hour of inactivity. We're hoping that Atlassian will soon provide us with a way of "refreshing" the token under-the-hood, so that we could do it in the background and hence do not need you to refresh the page. As soon as it's possible, we'll get rid of that alert!

Why each of the issues created by your add-on have "The Scheduler" set as "creator"?

A catchy eye may have noticed that each JIRA Issue created by The Scheduler has "The Scheduler" user set as an creator. This is because in JIRA Cloud each add-on is given its own "add-on user" and, until recently, add-ons could perform certain actions in JIRA only on behalf of this particular user. This has actually changed during the last Atlassian Summit, when the "Act-as" functionality has been provided to JIRA Cloud developers, allowing the add-ons to "impersonate" other users in JIRA. However, this functionality was not available yet when we started the development process of "The Scheduler for JIRA Cloud", and hence, our add-on creates each and every issue on "The Scheduler" users behalf. The nice side-effect of this behavior is that you can easily find issues created by The Scheduler with a JQL statement.

That being said, we're aiming to implement the "act-as" functionality in our add-on some time after the initial release, which would allow you to modify the issue creator.

Why The Scheduler user does not have "Administer Project" and "Create Issue" permission?

This could be noticed in next-gen projects or with new Service Desk projects, when new permission schemes are generated. It is related to role created for apps: atlassian-addons-project-access. Here you can see the details: https://community.atlassian.com/t5/Jira-questions/Project-Role-atlassian-addons-project-access-has-been-added-to/qaq-p/421651

Make sure this role is included in both of mentioned permission, or specify system user "The Scheduler"

Open

What are application scopes?

Scopes allow The Scheduler to request a particular level of access to an Atlassian product. At the moment, the app uses following scopes: READ, PROJECT_ADMIN, ADMIN. Here you can read more about scopes: https://developer.atlassian.com/cloud/jira/platform/scopes/

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.