Can we keep issue ID when we move issue from one project to another project?

Can we keep issue ID when we move issue from one project to another project?

10 answers

1 accepted

1 vote
Accepted answer

Issue id (the 6 digit unique id in database) remains the same but the issue key will change.

Issue key is created by project key followed by '-' followed by the next unique number in the project.

can we keep the Issue Key?

As Jobin already said, no.

The Issue key is always <project>-<sequence>, so if you move an issue into another project, there is no choice but to change the key. The old key remains in history and is searchable.

At the same time, you can still refer to the old issue key in urls and it should automatically redirect to the new key.

Instead of moving, you can export your issue information and then import it and map the key to the sequence you want. You'll want to know what your pcounter is set to and make some decisions on continuity based on that.

I'm wondering why the 'issue key' should change every time a move action has been executed.
It is a unique ID within JIRA right, so doesn't really matter if it changed or not?

Yes, it does.

An issue is shown as belonging to a project by having a key of format <project key><sequence>. You change project, you must change key to match.

That is totally separate from the issue ID, which is in the Jira database and does not change.

The fact that the issue can be found within a specific project should be sufficient enough to indicate that it belongs to that project right? Why does it need to be indicated within the key, in my opinion this makes it less flexible. The purpose of a key is that it needs to be unique and ideally shouldn’t contain any information referring to a project.

Within our company we have different JIRA projects which we (after we refined the issue) merge with a master project. Because JIRA only shows the issue key this get changed every time we do a move action. And it gets even worst, when an issue has been refined we move it to the master project and finds out that we missed a big architectural issue so it gets moved back to its original project. Well, you can guess…the ID change again…

So is there a way to always show the issue ID?

No. Because an issue without the project key in it won't look like it's in the project.

Here's a really simple example. I've got three projects in my dev system, and around 30 issues. Projects are Weebl, Bob and Chris. 10021 is an issue id. Which project is it in?

If you think you need an id without the project then you're mostly wrong (I've used several systems that don't include some form od grouping identifier and they're simply awful for most humans, to the point where they're all bodged to insert the missing helper data, even if it's saying "starts with 1 means project X, start with 2 means y, and so-on)

A good compromise for your situation would indeed be to show the issue ID and you should be able to do it with a simple custom field plugin. But your users are going to continue using the project key as it's basically better for them.

We have many clients and our helpdesk will issue them a corresponding issue # when they open a new issue. That original project key has the corresponding project # for that client. Over time, that project # can change as projects expire and new ones are created. Given that the client would have the original issue #, we were hoping we could move issues to their new project but keep the old #.

Ultimately, we stopped putting the project # and use a more generic data modeling approach so we could keep our project key consistent and we just change the project number in the name of the project rather than in the key.

"I've got three projects in my dev system, and around 30 issues. Projects are Weebl, Bob and Chris. 10021 is an issue id. Which project is it in?"

From a clean development perspective, does it really matter? an ID is unique identifier and you can use in this case JIRA to search up which project it is reffering to. From a security perspective, I'm not sure if you want to have your key referring to a specific ID.

But let's agree to disagree on this :)

You mentioned something about "simple custom field plugin.". Can you give me more info about this? Are talking about the "custom field" of JIRA? If yes, which field type are you talking about?

Cheers, Chee-Hong

But the point here is that you simply can't answer the question, so a non-informational issue id instantly fails. Now imagine a system with several million issues and thousands of projects. From a human point of view, it ABSOLUTELY matters that you can get grouping information from the issue id. 1013312312 vs 22341987 is utterly useless, but OPS-123456 vs DEV-123456 is immediately clear.

So, I'm sure we can agree that a project-less ID in a system is really unhelpful.

Yes, a custom field plugin can be used to expose the database ID of the issue. Won't be used by your humans of course, they prefer useful friendly IDs with projects (or other information) in them, but you can do it. I used to use the Jira Toolkit's velocity field to expose it (until I found out no-one ever used it). Those won't work now, so you'll have to find/write a workaround (I think the message fields from the toolkit or a spot of javascript will do it quite easily. If not, then a calculated field from the script runner plugin will do it too)

It was convenient in an environment where issues potentially get assigned to a large array of folks and the project # they needed to bill to was also in the issue key - i.e. DEV99214-16 & they have to bill to project 99214.

“But the point here is that you simply can't answer the question, so a non-informational issue id instantly fails.”

Not answering a question doesn’t mean that a non-informational issue ID instantly fails. I do understand where you are going and understand what you see as an advantage.

Let me ask you a question then:

OPS-123456 vs. DEV-123456, what is so clear about this? If we talked OPS-123456, would you know exactly what this issue is about? If we take your scenario into consideration where you have thousands of projects and probably numerous of project leaders would even know what OPS, DEV, BLA, FOO, BAR means?
The only thing these “prefixes” are good for is to categorise them in high level, but this can be done with help of JQL as well.
So your given example is utterly useless as well…

1 important characteristics of an ID is that it should be 1) unique and 2) completely agnostic. Look around you: bank account number, social number, passport number etc., none of them “represents” anything that can be referred back to you as an entity and that is an advantage!

You're ignoring the context of the question I asked. Given 12345, can you tell me what project this is in?

No. So a non-informational id fails.

In human terms, generally, yes, most people DO know what project shortcodes mean. Let me rephrase this from a human point again, as you seem to be missing what I'm getting at (which is how humans use Jira). One place I worked at recently had around 700 projects. Many project chose shortcodes that were generally informative about the project and it's place in the organisation, and short snappy codes were "big" generalised projects. I'd bet around 90% of people in IT would see a shortcode of "Ops" and take a guess at "Operations". More to the point, they also narrow the decision process - rather than have absolutely no idea where 12345 is lying, your project leads WILL know that Ops-123, Change-123, Release-123 all refer to specific projects, and that when they run into Zyz-123, their decision tree goes from "random guess out of 700 projects" to 3 clear options - "It's a project I know, it's a project I don't know and either need to, or can ignore".

As for your examples - also badly chosen. In the UK, I can tell you all sorts of things about someone if you give me their "social number" (I'm guessing that's a reference to the US social security number - here the closest one is an NI number which shows age and part of the name), a driving licence number, passport number, bank account number, and several others.

I completely agree with you that an ID should be unique. It is in Jira, even when it changes. They do not need to be immutable though, and they certainly don't need to be agnostic. Agnostic numbers are, in reality, a very bad idea to give to humans, because we get them wrong, and there's no cross check in an agnostic number. Fine for computers, but awful for humans.

You are comparing different things.

Obviously a number like 123456 doesn’t mean anything. (duh)
So in that context, non-informational ID clearly it fails, but my point was about the usage of ID’s in general.

I don’t have to know in which project 123456 lies in but I look it up in JIRA but simple type it in the search bar. If you ask you a question about OPS-123456 (or 123456) you will most likely have no idea what the issue is about, only that it has something to do with Operations. So context-wise it is as useless as using 123456 unless you look it up.

This is how people will use JIRA. We talk about an issue 123456, I look it up and see that it’s in project X and it’s about Y. If I want an overview of ALL the issues for project X, I can simple use JQL to retrieve the data.

In your case, we talk about issue OPS-123456, the only thing you know at that point is that is as something to do with Operations, but what?! So eventually you’ll have to look it up as well.

Your response about social number isn’t valid because (I assume) you are talking about using an agnostic number and cross reference it with other systems to retrieve information. The point is that each individual number (social ID, driver license etc.) should be meaningless by itself. It would be a serious problem if you driver license was like: NicBrough-12345. I wouldn’t feel save… When we talk about getting a non-informational ID and cross reference it to retrieve data, don’t we have JIRA for that? ;-)

I'm not sure what is "different things" here. You've got a useless unique ID that people have to actively look up before they can do anything useful with it, against a unique ID that has some informational content that humans can use.

You're wasting a lot of time with the low-information ID, and it really is of minimal use. As I said before, it works fine with the computers, but is really awful for humans. All the systems I know of that use such IDs are referred to as "legacy" by the IT teams that use them because they're being replaced with systems that have more human-friendly ones.

This is how people use Jira: they refer to issue-IDs with a project and issue sequence. They simply don't use the database ID. They won't because it tells them nothing. Ops-123 is useful. 12345 is not.

Again, think of the users who have 700 projects. Ops-123 tells them something, it gives them common ground with the rest of the user base. XYZ-123 tells them something, even if it's "I don't know about that". 12345 is useless and requires them to waste time looking it up.

Please, think about the way humans work.

“against a unique ID that has some informational content that humans can use”
What is so useful about OPS-123456?

In terms of thinking about how humans work, if I was walking up to you and ask the following:
“Hey, I got a question about issue OPS-123456”, and you didn’t had a computer in sight, what can you tell me about this issue? I bet not much, until you use some tool (software) to look it up. OPS-123456 at itself tells you nothing about the content of the ticket.

If we talk about seeing it through the eyes of an user, then can imagine if we don’t use for example binary code (as a developer to develop) or use IP addresses (as a normal user) to visit a website.
But when we talk about unique ID’s, I wouldn’t care whether it has an “informational” prefix or not.

But again, lets agree to disagree on this matter ;-)

Yes, everywhere I've worked, people are able to use Ops-123456 without referring to a system to look it up. It already tells me "it's the Ops project", which instantly puts the user in a position where many of them do not need to look it up. A random number does not do this. They do NOT memorise arbitrary and uninformative numbers.

Humans simply do not work that way, they work better, faster, more effectively and WITHOUT needing a lookup when given informational IDs.

It's not a case of disagreeing about it. The facts are in front of you - informational IDs work better for humans than arbitrary ones. (Obviously, the computers don't care)

I’m amazed with the fact that you are telling me that “people are able to use Ops-123456 without referring to a system to look it up

If I had a project called OPS with over 123456 issues in it, I wouldn’t know each issue by heart, only that it has something to do with project Operations. You have been working with extreme smart people then…

You're misunderstanding. I work with people who have picked up a handful of issues as being important. The project identifier often means they can identify them from memory. They can NOT tell the difference between 456234 and 455324, but if you say ops-456 and dev-455 very easily because they're relevant and have useful information.

Again, the low-informational id absolutely requires someone to look it up because it's useless in human terms. The prefixed one lets them make a decision and triggers a memory instantly.

The only difference that I see is that the issues ops-456 and dev-455 are not from the same project. That is the only information I can retrieve by looking at the ID.

I would need to have more context to decide whether 1 issue is more important than the other one. In other words, a look up is necessary…

No, it's not. That's the point, the project key in it gives the user enough information to filter for "I know what that is". Raw numbers do not.

It doesn't matter how often you deny it, it's really simple - informational IDs are better for humans than abstract random ones.

“Informational ID are better for humans than abstract random ones”.

I agree that Informational characters are better for humans than abstract random ones. Take DNS and IDE’s that does the translation for you into binary code etc.

The purpose of IDs is to create some form of uniqueness within (most of the time) a database. IDs shouldn’t contain additional information due to security, scalability etc.

I'm glad you finally get the point I made at first - informational IDs are more useful, and abstract ones should be hidden from humans because they're useless.

Informational characters of course are useful, but not for IDs.

ID’s should be unique and NOT change when it gets moved. Otherwise it’s not unique anymore. Now I don’t care whether it’s an issue key or not, what we human can see is changing and that’s not always desired.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,708 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you