Reset issue numbering after a CSV import of tasks/subtasks?

[Nathan_Swartzendruber]

We're setting up a project that uses the CSV import-issue feature to create sets of tasks and subtasks for publishing-related projects. Since we follow the same steps each time, I'm creating a template in Excel to generate the CSV file.

To create sub-tasks, the CSV file is required to include "Issue ID" and "Parent ID" records, meaning that I have to choose the numbering for the tasks instead of letting Jira do it. I don't want to accidentally update existing issues, so I'm choosing a number far higher than our current issue count.

For catalog 133, the first Parent ID will be CAT-13300. That gives us 100 tasks/subtasks to assign (which should easily be enough for the way we're using Jira here) before we start catalog 134 (CAT-13400).

But after some successful testing of the CSV task import, I noticed that tasks added after the import follow the numbering of the import. Previously we were at (let's say) issue CAT-700. After the CSV import of a few test tasks (CAT-13300 to CAT-13310), new tasks are at that jump-forward number--CAT-13311, CAT-13312, CAT-13313--instead of continuing at CAT-701, CAT-702.

I'm concerned that, if this is how the numbering goes, that catalog tasks and other tasks might use up that 100-task buffer between catalogs 133 and 134. I hadn't expected Jira would jump from issue CAT-700 to CAT-13311.

• Is this what y'all see after using CSV imports to create new tasks?
• Is there a way to force Jira to continue numbering at CAT-701 instead of at the highest existing number?
• For those using CSV imports to create new tasks, are there other strategies you use around numbering?

Thanks!

[Nic Brough -Adaptavist- · Accepted solution]

You can't directly modify the starting point for the sequence.  As you've discovered, you can increment it by creating more issues (and then deleting).

But, you should never have a sequence counter lower than the highest numbered issue in the project.  Jira always uses the next sequence number, irrespective of if it's already there - when it is because you've hacked the number down below an existing issue, it fails in "interesting" ways.  It also messes up if you've moved issues out of the project.

[Joe Pitt]

You can't modify how JIRA numbers issues. 

[Nathan_Swartzendruber]

Creating new issues with a CSV import lets me set issue numbering and jumped overall issue numbering forward. So I have already modified how Jira numbers issues.

[Nathan_Swartzendruber]

I did a little more testing. In this example, assume that the Jira-created numbering was at CAT-700 and the CSV upload numbering was at CAT-13310.

1. I used the CSV upload to create ticket CAT-701
2. I used the Jira interface to create a new issue, which Jira logged as CAT-13311
3. I used the CSV upload to create ticket CAT-13315
4. I used the Jira interface to create a new issue, which Jira logged as CAT-13316
5. I used the CSV upload to create ticket CAT-705
6. I used the Jira interface to create a new issue, which Jira logged as CAT-13317

It looks like I can bump Jira issue numbering forward at-will, and Jira will continue issue numbering from whatever max is in the system. If I created CAT-900000, future issues would number sequentially from there, however many issues I created by CSV import at lower numbers in the meantime.

Jacking up the issue numbering isn't the solution I'd prefer, but maybe it's the only option.

[Vishwas]

@Nathan_Swartzendruber 

As @Joe Pitt rightly mentioned we can't control the issue numbering in JIRA.