How to Reproduce Projects and Maintain Issue Links

[Mindy Tran]

Hi - Do any of you manage reoccuring Jira projects that need to be reproduced in a new project year-after-year?

Background: I'm managing a Jira project that needs to be replicated next year with the same issues (need to update the start / due dates), and there are important issue links I want to maintain in the project.

Option 1: Clone the entire project so it maintains the issue links and make appropriate edits directly in Jira; however, this is not an out-of-box feature.  Is there another way I can clone an entire project?  Has anyone used an Atlassian App they can rec for this?

Option 2: Export the project via Excel; however, it only includes the outward link and not the inward link so it's difficult for us to see the appropriate linkage when review large #'s of issues.

Option 3: Any other suggestions?

Thanks in advance for taking the time to respond!

[dave_drexler]

Hi @Mindy Tran - I would try Option 2. I've had good luck with the Export/Import wizard - seems to work pretty well and reliably.  I'm not clear on what you mean by 'outward' and 'inward' links, though. Perhaps you can fix the problem with a search-and-replace in Excel?

[Mindy Tran]

Hi @dave_drexler - Thanks for the response!  To clarify when I export using the "Export Excel CSV (current field)" the CSV includes a "Outward Issue Link" column. Pls. see attached image.  

So if I'm reviewing the CVS Test-2, I can see that it is dependent on Test-1; however, if I am reviewing Test-1, I am not aware that Test-1 is required to be completed prior to Test-2.  

So next year if I'm reviewing the issues and may need to make some edits before the upload, I'm not aware of the outward / inward relationships between issues.  

I hope that context helps.  Thanks!

[dave_drexler]

Hi @Mindy Tran - sorry for being obtuse, but I'm still not entirely clear. Looks like you are not using the standard Issue Links 'Depends On/Is Depended On'? If your issues were set up that way, would it address the issue?

[Mindy Tran]

Hi @dave_drexler - Thanks again for taking the time to respond and seek to understand my requirements!

Since Jira allows you to have various issue linking types, we do utilize the Dependency link quite a bit ("depends on" / "is required to complete prior to"). So when we use the "Export to CSV (current field)" the CSV includes a "Outward Issue Link" column, as illustrated in my previous comment to you.  The problem is let's say we have 100+ issues, I would know that Test-200 depends on Test-100 from the Outward issue link column; however, when I finally review all my issues and review Test-100, the Excel will not show me the inward link (meaning that Test-100 is required to be completed prior to Test-200).

I hope that add'l context makes sense.  Thanks!

[Anne Saunders]

It's not sexy, but I start all of our projects from a CSV and import them. It makes it very easy to duplicate them. I use Epics, Stories, Sub-tasks, and Tests, and I have columns in my spreadsheet so Stories have an Epic link, Sub-tasks have a parent link, Tests have a "tests" issue link, and any issue can have one or more "relates to" issue links, depending on how many you make columns for. 

[Mindy Tran]

Hi @Anne Saunders - Thanks for taking the time to respond & for the recommendation!  Pls. take a look at my response to Dave Drexler's comment. 

Ideally, we'd like to export the current project issues to a CSV and do our review/ edits before uploading to a new Jira project; however, both outward / inward link relationships aren't depicted in the CSV for the original project export, so it's difficult make revisions when we don't have a holistic view of the relationships between issues.  

I hope that context helps.  Thanks!

[Anne Saunders]

If the inward link is a custom field, you can use the advanced issue search to add it as a column, then export your selected columns. You may need to perform to exports, one with the "complete" record, and one with your selected columns, then combine them in your spreadsheet program (e.g. by using a Vlookup on the issue key.) 

If the inward link is just a "flavor" of linked issue, that won't work as well, because while the issue key is retained for the linked issue, the relationship is not.

If all else fails, the JSON import and export is actually not that bad, and gives you access to a lot more information. The flipside of that is that it is far less human readable and human editable, on par with trying to manage XML records manually.

[Mindy Tran]

Hi @Anne Saunders  - Thank you for your response!  As a site admin, if you go to your Settings > Issues > Issue Linking, you'll see you can create different types of issue links that includes an outward link description & and inward link description.  The inward link is not a custom field.

Can you explain a bit more about JSON import & export?  In the External System Import, I see that you can upload a JSON file, but how do you export?  As you mentioned, it looks far less human readable and potentially difficult to edit.  Thank you.

[Anne Saunders]

I have NO idea why I got an email about this today, and not in December, but!

Full disclosure, I'm a hybrid BA/PM, so I pretty much only deal with the native functionality of Jira. Unfortunately, those fields don't seem to be usable in JQL, so you can't query for them or see the relationships without going into the actual issues and manually reviewing. 

I use a column in my spreadsheet (which I convert to a CSV) to link Test issues to the  issues they test, and I do that like this: 

That's creating the outward link ("Tests"), and the inward link ("Is Tested By") is created automatically by virtue of being the other half of the pair in the issue linking relationship we call "Test." I didn't pull those values out from Jira initially, though - just built my template to leverage them.

If you must get the data out of Jira initially, I think you'll need to use the API. Here's the documentation on the API and retrieving those issue links together with their identifiers. You can see that the JSON is at least as human-readable as XML, so really not bad, even for us non-dev types :) Once you have your nice, tidy base issues exported through the API, you'll be able to use the System > External System Import > JSON option to duplicate to your heart's content. 

When I need to get more in depth with JSON, or with the API, I tend to pull in a dev who just does the magic. That said, our juniors don't have any trouble working with the API, so you can likely get someone at your org to spend the couple hours with you to name and number all the fields you need exported and test a bit. Once you have it, it should be good to go.

[Mykenna Cepek]

Ugh. That sounds like a lot of administrative overhead!

Not sure if this would satisfy the customer use-case, but my first thought would be to propose continuing to use the same project, and find a way to de-scope the appropriate issues at year-end.

One example:  for a project that is Kanban (not Scrum), I'd suggest converting it to Scrum and using year-long Sprints. Then you can just close the Sprint. Everything Done disappears from the board, with only the unfinished / carried-over work remaining.

Another example:  for existing Scrum projects, understand exactly what constitutes the "year boundary", and use some other approach to identify and separate out "last years' issues". Examples:

• Use Quick Filters to differentiate last-years' issues from next-years' issues.
• Change the board Filter to select only next-years' issues, and create shared filter to use for locating last-years' issues.
• If the issues have no consistent way to filter as described above, then create a new custom field (maybe "Project Year"?) and bulk-set it at year-end on all the issues that are not carrying over. Then use that custom field with in the filters discussed above.

Some strong values for these approaches include:

• MUCH less administrative time (across multiple projects?!)
• The ability to maintain all issue links and issue Keys
• No need to modify other fields not handled well by export/import methods (e.g. dates)

[Mindy Tran]

Hi @Mykenna Cepek  - Thanks for taking the time to respond and share this recommendation!  I'm VERY intrigued, esp. if the rec allows for reduced administrative overhead; however, I wonder if the same challenges present itself in this situation.

In your example, let's say I have one comprehensive Scrum project and there's a Year Long sprint (aka Sprint 1).  In Sprint 1, there are issues that are linked to one another.

Next year, the expectation is to create a net new year-long sprint (aka Sprint 2) in the same project with the same linked issues.

How do I clone all the issues from Sprint 1 into Sprint 2, while also maintaining the linked issues?  Is the expectation to export to Excel CSV the issues from Sprint 1, make modifications, and import them to Sprint 2?  If so, the export wouldn't show the inward / outward link relationships as I explained to Dave Drexler's comment.

Again, I'm intrigued by this solution, but as you can see I have questions.  Looking forward to your response.  Thanks!

[Mykenna Cepek]

My recommendation aims to eliminate export/import and cloning.

Thus, any problems that occur during export or import (e.g. "fixing linked issue") would be irrelevant. Issues that were linked before year-end remain linked. They might not be visible on the board anymore, but they are still in Jira and would still show if a link was followed.

It could be that I'm missing an important (unstated) requirement -- for example: "At year end, a copy of every issue in the project not completed is created, and each copy is linked to the original issue". That requirement demands that some issues be copied/cloned at the end of each year.

My proposal involves questioning the need for that requirement, fostering a conversation about why issues need to be cloned (causing lots of overhead), especially when locating the original issue is still important.

My guess is that a LOT of information in each "original issue" needs to be carried over to each copy at year-end. So why make a copy? Just keep the original issue.

Clearly I have only a minimal understanding of your use-case. I'm limited by what you wrote here. I can think of many situations where my suggestion would not work.

[Mindy Tran]

Hi @Mykenna Cepek - I appreciate the clarification.  You're right, eliminating export / import cloning would definitely reduce administrative overheard.  I've shared this as a potential solution w. our small team of Jira Admins for their consideration.  Thank you again for taking the time to respond & share your feedback.

[Alex Adland]

If you have a copy of MS Project, look at Ceptah Bridge https://www.ceptah.com/,  I have one licence of CB for my copy of MS Project and I use CB to create and update project tasks and project dates in over 100+ different customer delivery projects that each start life with the same generic plan.  The settings in CB even allow you to specify issue security levels, maintain epic links and issue links with ease.

The export / import method via CSV is a right pain, but when I have used this method I add an Issue Id column to maintain the inward and outword links by replacing the issue key with the unique issue Id I had created in the new Issue Id column, and the same for epic links.

[Afifa Habchi]

I've got good results with scriptrunner (function: bulk clone issues) and

and bulke change Jira Plugin. it takes you 5 minutes.

[Mindy Tran]

Hi @Afifa Habchi - Thank you for the response.  So when you use the Script Runner app, are you able to clone all the issues in Project A into a new Project B while maintaining the same issue links in Project B?  

[Tiffany Vu]

Hi @Afifa Habchi  - thank you for your input - I work on Mindy's team and have some follow-up questions.

Background:

I am attempting to bulk clone issues that have a linked relationships.
For testing purposes, I am attempting to query and clone:

• Issues from the project = BON2022
• Issues with "depends on" OR "is required to complete prior to" relationships

Question:

I am running into an error when attempting to perform ScriptRunner's bulk clone issue function. Do you know what may be causing this?

Here is the JQL query I used in ScriptRunner:

• issuefunction in linkedIssuesOf(project = BON2022, 'is required to complete prior to') or issuefunction in linkedIssuesOf(project = BON2022, 'depends on')

The query was validated (green check shows, 25 issues were found).
After I press "run," I receive the following error:

• Failed to get metadata for create issue request. Response status: 400

Any ideas or feedback would be greatly appreciated!

[Afifa Habchi]

Hi Tiffany,

I've also got the same error message as you. After saving the jql query above as a filter under the name name CLONEFILTER and sharing it with all users, I went to script runner Built-in Scripts and wrote the following jql query:

filter=CLONEFILTER

and clone the issues. It works and creates the clones in my target project but unfortunately without any Links.

[Tereza Červinková]

We created our own app - needed the same project 40x per year.

One more thing that went on my mind was maybe create one model project, clone it forever? 

[Mindy Tran]

Hi Tereza - Thanks for taking the time to respond.  

When you clone your project 40x per year, does your project include issue links that are maintained when you clone the project?

[Jules]

Hi Mindy, not sure this is helpful - I do a similar thing with Epics and use this free app (Clone Epic Template for Jira). It clones an entire Epic including all child tasks (stories and sub-tasks). Can't be sure on maintaining the dates, you'd need to test that. Worth a try though as it's a free app.

 

[Mindy Tran]

Hi @Jules - Thanks for taking the time to respond & for recommending the Clone Epic Template for Jira app.  I just enabled the app and am testing it in sandbox.  This app is definitely handy if you have a very straightforward project.  There are significant pros & cons to this app, but this is definitely handy.  Thanks!

[Carmen Nadeau]

Hi @Mindy Tran ,

You could use this addon for recurring issues. I've been using it for the last 5 years and I find it really useful, it is available for DC and Cloud. 

https://marketplace.atlassian.com/apps/37456/the-scheduler?hosting=datacenter&tab=overview

Carmen

[Marlene Kegel - codefortynine]

Hi @Mindy Tran

I'm Marlene from codefortynine.

If you're heading for solution #2 you can have a look at the project clone feature of our app Deep Clone for Jira. 

With our app you can clone entire company-managed projects along with issues. The cloning process is pretty simple and can be handled by every Jira users who has the required permissions.

• After installation, go to the Bulk Clone menu
• Select the project you want to clone as "Source Project"
• Select "Clone project" as "Target Project"
• Select a name and key for the new project and clone the project
• Configure the Bulk Clone to clone the issues into the newly created project

It's also possible to create the project manually and Bulk Clone and move the issues into the newly create project.

You can also configure which links are created between the original issues and clones and much more.

[Mindy Tran]

@Marlene Kegel - codefortynine  - Thank you for sharing this recommendation.  I look forward to exploring this app. 

A couple of quick questions...  If I select to move forward w. the Deep Clone for Jira app...

Is there a way to restrict the usage of this app to only the site admins?  And if so, if we only have 10 site admins, can we be priced for just the site admins rather than the # of users in our Jira instance (ex. +100 users)?

Thanks in advance for the clarification!

[Marlene Kegel - codefortynine]

You're welcome, @Mindy Tran.

Yes, there are several ways to configure permissions and access for Deep Clone for Jira. You can read more about that topic in our documentation. 

Payment is handled by Atlassian and apps are billed based on the number of users in your Atlassian product. In our documentation you can read more about how to calculate pricing for your instance.