nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Moving an issue creates gap in Issue id

vikramjit singh1

After moving the JIRA issue from one project to another the current JIRA ids is not reused. And if that issue happens to be the last/latest issue on the list the next issue created will be given id 1 more than the current one.

For example: If we move issue with id=003 to other project and then create a new issue in the project then the id=003 is not re-used. The new issue is allotted id=004 & id=003 is forever lost. So, now list of issues will be like – 0001, 0002, 0004.

Is this the desired behavior?

Accepted answers

Andy Nguyen

Hi Vikramjit,

This is by design. Before explaining further, I just want to clarify the terms as follows:

I believe the issue ids that you mentioned are actually issue numbers (starting from 1 and incrementing by 1). Issue Number is part of Issue Key, which consists of Project Key and Issue Number.
To differentiate, you can look into table jiraissue in your JIRA database, where ID column specifies issue ids while issuenum column specifies issue numbers.

Now if you look into table project in your JIRA database, you will see a pcounter column which tells the last Issue Number that has been used in a project. JIRA will base on the values in this column to determine the Issue Number of the next issue to be created in a specific project. For example, if the current value is 7, then the next issue to be created will have Issue Number 8.

So, if you move Issue 7 from project A to project B (e.g. A-7 -> B-1), the next issue to be created in project A will still have Issue Number 8, not 7. Indeed, if you directly access the URL of A-7, you will be redirected to B-1. This is to make sure that, in case the old Issue Key is needed (the issue might be linked to other resources before being moved), it can still be found and mapped correctly to the new Issue Key.

To conclude, this is by design and, even though you can manually reset the pcounter for one or more projects, this is not recommended and may cause data integrity problems. Thus, we suggest that you just leave everything as is since it's not a bug here.

Cheers,

Andy

All comments

Andy Nguyen

Hi Vikramjit,

This is by design. Before explaining further, I just want to clarify the terms as follows:

I believe the issue ids that you mentioned are actually issue numbers (starting from 1 and incrementing by 1). Issue Number is part of Issue Key, which consists of Project Key and Issue Number.
To differentiate, you can look into table jiraissue in your JIRA database, where ID column specifies issue ids while issuenum column specifies issue numbers.

Cheers,

Andy

Nic Brough -Adaptavist-

The use of leading 0s in the numbers also made me thing the question was about database ids because Jira Key numbers do NOT have leading 0s. To add more support to what Andy has said, there's really no problem here - you can't have the same numbers in the new project because that causes data issues (not least the problem that you could easily run into duplicates) and there is actually no problem here because the old issue IDs redirect and the new ones are sane.

vikramjit Singh3

Hi Andy, Your answer make sense, thanks for the same. We have two or more similar projects where we clone the issue & then move it from one project to another. Thus, we may never need to refer to the cloned issue id. Is there a better way of cloning issue other than the one used by us (i mean, can we directly clone/create an issue from one project to another with all the settings and attachments available in the cloned one)?

Andy Nguyen

Hi Vikramjit,

Not that I'm aware of. Even if you use Clone And Move JIRA Plugin, it will only help you speed up the process by automatically moving the cloned issue. The pcounter of the source project still increments by 1, which means the original issue key is reserved, not ignored.

We may not need to refer to the original issue key, but JIRA needs it for applinks purposes as I mentioned earlier. You can refer to https://jira.atlassian.com/browse/JRA-37831 for more details. Considering that, I'm afraid we can do no better here.