|
You could manually impliment this by creating a service that clones or creates an issue at a given time or period.
http://www.atlassian.com/software/jira/docs/latest/services.html 
Don't think it would be that hard to do (if you have developer resources). Nick Just wanted to add another comment as to the usefulness of this feature. I work in a shop where we have regularly scheduled site updates for some of our clients that are handled by a pool of developers. It would be excellent if we were able to notify that group of developers that the weekly update was coming, and what that update would contain. We could then better track our developers' distribution of the recurring work amongst themselves, as well as make our hourly billing for our customer more clear.
this is needed.. you shouldn't need a developer to figure it out
A recurring due date would do it for me.
To notify the developers I have made a filter in which I subscribe for, checking once a week for the upcoming due dates/issues. That works. I am only missing the "recurring due date" I'm actually a bit surprised that this ticket has been open this long. We use JIRA to track production tasks and we currently clone them for weekly and monthly tasks. However, we also have standard daily tasks, and it becomes unwieldy to clone a bunch of daily tasks every day.
The way I would implement this is to allow a person to schedule a clone of a ticket or group of tickets. An additional functionality would be to allow some wildcards in the subject so that a date could be entered into the subject instead of "CLONE". I part solution I have been using to save myself from a cloning process is to use the com.atlassian.jira.service.services.file.FileService class with the com.atlassian.jira.service.util.handler.CreateIssueHandler handler. I just write my issues in Notepad in RFC822 format, and they are picked up every 1440 minutes from the directory specified.
Gareth.. sounds complex
 do you have maybe a wiki page describing? I've been looking in to trying to do this. I found a link saying that it could be done with use of a Jelly script.
Has anyone had any luck with implementing recurring tasks? Deleting the autoresponder message that inadvertently went on the issue.
Deleting my email autoresponder message that inadvertently went on the issue.
I think Michael Walton said it; "An additional functionality would be to allow some wildcards in the subject so that a date could be entered into the subject ".
That would be just great: Same request here. Allowance for recurring tasks would be great or even the creation
of new automatic clones with new due dates. Like every nth of every month Is there any news on this already? Any update on this one. This is a very useful for our projects as cloning is tedious process
I have a simple jelly script to automatically create a recurring task each week:
{script:xml}
<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.JiraTagLib"> <jira:Login username="jellyuser" password="xxxxx"> <jira:CreateIssue project-key="FRS" summary="Weekly Rollover" issueType="Retail General Request"/> </jira:Login> </JiraJelly>{script} which the Jelly service runs ok the first time, but on the second iteration writes the following to the log: <JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.JiraTagLib"><Error action="CreateIssueDetails"><TagContents>(CreateIssue(summary=Weekly Rollver)(issuetype=6)(project-key=FRS)(priority=1)(issueType=Retail General Request)(pid=10001))</TagContents><ExecutedAs>user=jellyuser</ExecutedAs><ErrorMessage>Duplicate Issue : Another issue for this project with the same values for "summary"</ErrorMessage></Error></JiraJelly> Why is it making the summary a unique field? I can manually create issues in the same project/issue type with the same summary. Is there a way to work around this issue? answer was ...
Use the duplicateSummary="ignore" on the CreateIssue tag to get around this. See: The guard is useful when using Jelly toimport issues to prevent importing the same issue more than once. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Recurring issues
What makes it even more exciting is that it effectively expands the uses for JIRA. In addition to issue tracking, at some level it can also work as a PM utility. I'd love that as it increases our reliance and usage of JIRA as well as expands functionality to other departments that don't have near this level of tracking and reporting.