periodic tasks in jira

[Deleted user]

For confluence I'm happy with the JobModule and TriggerModule types. What is the right way to implement periodic task in jira? I would like to extends the list of jobs and triggers in jira.

Thanks in advance,

Lars

[Jobin Kuruvilla [Adaptavist] · Accepted solution]

There are 2 options in JIRA. Run as a service as Radu suggested.

http://www.j-tricks.com/1/post/2010/11/jira-service.html

Or run a scheduled task. Service run at regular intervals but not at specified times. This is where scheduled tasks are important.

http://www.j-tricks.com/1/post/2011/05/scheduled-tasks-in-jira.html

[Deleted user]

I've tried a setup for a scheduled job as described in the j-tricks link. Unfortunately it does not work in jira 5. First I had to add key attributes to the job and trigger elements to get it compiling. After playing around with the configuration I finally ended up with a configuration which is taken from a confluence 3.5 plugin

<job key="sapPluginJob"
         name="SAP Plugin Job"
         class="net.bigpoint.jira.sapplugin.implementation.jobs.SapPluginJob">
    </job>

    <trigger
            key="sapPluginJobTrigger"
            name="SAP Plugin Job Trigger"
            class="net.bigpoint.jira.sapplugin.implementation.jobs.SapPluginJobTrigger">
        <job key="sapPluginJob"/>
        <managed editable="true"
                 keepingHistory="true"
                 canRunAdhoc="true"
                 canDisable="true"/>
        <schedule cron-expression="0 30 5 * * ?"/>
    </trigger>

For some reason jira still refuses to enable the plugin modules without any error logs. It just remains disabled:

DEBUG admin 702x2614x1 - 127.0.0.1 /rest/plugins/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Enabling pluginSettingsFactory
DEBUG admin 702x2614x1 - 127.0.0.1 /rest/plugins/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Enabling pluginConfiguration
DEBUG admin 702x2614x1 - 127.0.0.1 /rest/plugins/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Plugin module 'SAP Plugin Job' is explicitly disabled (or so by default), so not re-enabling.
DEBUG admin 702x2614x1 - 127.0.0.1 /rest/plugins/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Plugin module 'SAP Plugin Job Trigger' is explicitly disabled (or so by default), so not re-enabling.
DEBUG admin 702x2614x1 - 127.0.0.1 /rest/plugins/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Enabling configurationScript
DEBUG admin 702x2614x1 - 127.0.0.1 /rest/plugins/1.0/ [atlassian.plugin.manager.DefaultPluginManager] Enabling restApi

[Deleted user]

I've tried to add the configuration to atlassian-plugin.xml instead of scheduler-config.xml. But unfortunately that would not solve my problem. The plugin should run out of the box without any complicated configuration stuff.

After digging in the developers documentation I've found another interesting approach https://developer.atlassian.com/display/DOCS/Plugin%20Tutorial%20-%20Scheduling%20Events%20via%20SAL maybe that will do the job ...

[Jobin Kuruvilla [Adaptavist]]

Actually, it worked for me in JIRA5. Scheduling events via SAL should work as well.

[Radu Dumitriu]

Common, guys. You can start a thread on the plugin startup and stop it on the shutdown.

http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/BundleActivator.html

There are plenty of options

[Deleted user]

@Jobin: I guess there is no relation to the jira version since I've just misplaced the job configuration. SAL works fine for me now.

[Royce Wong]

I am using JIRA 6.2.2 In Scheduling Events via SAL Tutorial (https://developer.atlassian.com/docs/atlassian-platform-common-components/shared-access-layer/scheduling-events-via-sal-tutorial), it doesn't seem it support cron expression, does it? What if I want to schedule a job to run daily @ 2 a.m.? Do I have to use plugin v1 method as described in JTricks: http://www.j-tricks.com/tutorials/scheduled-tasks-in-jira?

[Prakhar Srivastav]

Hi @Jobin Kuruvilla

With scheduler XML file not available in JIRA , has the Quartz method to schedule task has been phased out?

I am also trying to schedule a task with SAL but getting the following exception :

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'RecurringIssueJobImpl': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.atlassian.example.scheduling.api.RecurringIssueJobImpl]: No default constructor found; nested exception is java.lang.NoSuchMethodException: com.atlassian.example.scheduling.api.RecurringIssueJobImpl.<init>()
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:883)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:839)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
	at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
	at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.atlassian.example.scheduling.api.RecurringIssueJobImpl]: No default constructor found; nested exception is java.lang.NoSuchMethodException: com.atlassian.example.scheduling.api.RecurringIssueJobImpl.<init>()
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:58)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:877)
	... 20 more
Caused by: java.lang.NoSuchMethodException: com.atlassian.example.scheduling.api.RecurringIssueJobImpl.<init>()
	at java.lang.Class.getConstructor0(Class.java:3082)
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:54)
	... 21 more
2016-06-03 18:13:33,274 UpmAsynchronousTaskManager:thread-3 INFO admin 1084x148x1 1ekbet7 0:0:0:0:0:0:0:1 /rest/plugins/1.0/ [atlassian.plugin.manager.PluginEnabler] Plugin 'com.atlassian.example.scheduling' is now DISABLED

I am following below tutorial :

https://developer.atlassian.com/docs/atlassian-platform-common-components/shared-access-layer/scheduling-events-via-sal-tutorial

Please help.

Regards

Prakhar

[Larry Talley]

I have done something a little bit similar, that is, setup a JIRA project to help humans manage periodic tasks such as software license renewals or SSL certificate renewals.

We have been using this for about two years, but, today I am reproducing it in another JIRA instance, so I thought I would document this for the community. Comments/improvements are welcome!

I create a project "Periodic Tasks".

I create a status "Inactive" which allows periodic tasks to be disabled but stay in the system. The status "Closed" would probably work just as well, but, we liked Inactive better. I also created a simple workflow that allows these issues to be inactivated and activated. I am not documenting the workflow here because I think it adds little value, I think "Closed" and "Reopened" would work just as well.

Add "Periodic Task Issue Type Scheme" with Issue Types "Task" and "Sub-task".

Associate "Periodic Task Issue Type Scheme" with project "Periodic Tasks".

Add components "Hardware maintenance/support renewal", "Software License or Support Renewal", "SSL Certificate Renewal", "Periodic Manual Review", "Business-related Annual Tasks", etc., etc.

Added a "Select List" custom field "Frequency" with drop-down values "Daily", "Weekly", "Biweekly", "Monthly", "Quarterly", "Annually".

Added a "Select List" custom field "Lead Time Requirement" with values "None", "1 day", "2 days", "3 days", "7 days", "14 days", "30 days", "60 days", "90 days". Add a description to "Lead Time Requirement" that states "Required lead time to ensure successful task completion. When the task due date is within this range the assignee will get reminders via email."

In our case these two custom fields, "Frequency" and "Lead Time Requirement", happen to have contexts set so that they only appear in project "Periodic Tasks", and I left them on the "Default Screen".

I don't currently have customized Screens or Screen Schemes for this project.

The meat of my implementation is in a filters and subscription.

Here is the relevant filters:

"Alert: Periodic Task due within Lead Time Requirement and no recent update":

Description:

A periodic task is due within the specified lead time requirement and there has been no recent (within 7 days) update to the issue. If you make any update to the issue this alert will be suppressed for 7 days.

JQL Query: project = PT and resolution = Unresolved and status != Inactive and updated <= "-1w" and assignee = currentUser() and (due < now() or ("Lead Time Requirement" = "90 days" and due < "90d") or ("Lead Time Requirement" = "60 days" and due < "60d") or ("Lead Time Requirement" = "30 days" and due < "30d") or ("Lead Time Requirement" = "14 days" and due < "14d") or ("Lead Time Requirement" = "7 days" and due < "7d") or ("Lead Time Requirement" = "3 days" and due < "3d") or ("Lead Time Requirement" = "2 days" and due < "2d") or ("Lead Time Requirement" = "1 day" and due < "1d"))

Sorted by: Key descending

I subscribe group "jira-users" to this filter.

This doesn't provide any automatic recurring issues, but, it does help humans manage periodic tasks.

[Scott Mercer]

Nice. That's a creative solution, Larry.

[Claus Nielsen]

See this:

https://marketplace.atlassian.com/plugins/com.codedoers.jira.repeating-issues

[Radu Dumitriu]

implement com.atlassian.jira.service.JiraService

or

extend com.atlassian.jira.service.AbstractService

and declare it as a component in atlassian-plugin.xml

[neha]

I have created some schedulers using following Link.
https://developer.atlassian.com/server/framework/atlassian-sdk/scheduling-events-via-sal-tutorial/

Now I need to run it one of it every Midnight, one every Monday and one to every Month end .  i tried to use following url mentioned approach but it didnt work .

 http://www.j-tricks.com/1/post/2011/05/scheduled-tasks-in-jira.html

Could somebody please suggest some ideas to set the scheduler interval to 1 week, or one month. I want my scheduler to run every Monday or every month end .

Thanks !!

[Gebsun]

On JIRA Cloud there is a plugin available https://marketplace.atlassian.com/plugins/com.gebsun.atlassian.rtasks

Cheers, Gebsun

[Martin Cleaver]

There is also https://marketplace.atlassian.com/plugins/pl.com.tt.jira.plugin.theschedulerprobut per https://bitbucket.org/apdc/the-scheduler/issue/28/can-i-make-thescheduler-re-open-anit won't reopen an existing issue.

[MattS]

For our internal use at ServiceRocket we implemented an add-on that uses issues as templates for the periodic task issues. The same issues also contain the frequency configuration. It's not available as a commercial product but please let us know if you'd be interested in that.

[Goran Rasic]

Warren,

I found something similar for a different purpose ..

here a Jelly script to change the ticket status automatically for all filter results .. you would need to

adjust the logic for your need..

https://confluence.atlassian.com/display/JIRACOM/Automating+issue+timeouts

-Goran..

[Warren McInnes]

Thank you guys, but have a look at the script runner's escalation service. I have used it to transition my tasks from inactive to active when they become relevant.

Regards,

Warren

[Warren McInnes]

What is the purpose of the frequency customfield? is would be nice if we could transition from inactive to active when the frequency field becomes relevant?

Could you also dive a brief overview of the workflow you use for this?

Thanks in advance

Warren

[Larry Talley]

Frequency was meant to accomodate tasks that might be monthly or even daily, but, in practice, we only use this project for annual tasks.

We use a very simple workflow with 3 status values, "Not Due", "Inactive", "Due". We don't really get much value from this workflow, we just use it to make an issue "Inactive" if the issues is going to be dormant for a while, but we don't actually want to delete it. We don't actually change the "Due" and "Not Due" in practice. I had intended to use Jelly scripts to change those based on due date and lead time, but, with the capability we have with filters and subscriptions, it never seemed like the workflow added enough value to be worth the work.

So the filters and subscriptions do all the useful work in our implementation.