Is it possible to configure/generate a project key to identify version and component

[Steve Brackenbury]

It would be nice if we could have jira records with a "smart" key that not only identifies the project, but furthermore the version and/or component within the project.

Is there such a capability in Jira today? Is it being considered for the future?

[Nic Brough -Adaptavist- · Accepted solution]

Jira doesn't do this. A key is always simply project-sequence.

I've seen this done though - a simple derived or calcuated field can be coded to generate a secondary key in any format you want. You'll be able to search on it and so-on, but Jira won't really care how it's derived, it's going to carry on using project-sequence.

[Steve Brackenbury]

Thanks Nic.

Understand that Jira doesn't really care about the key, it manages the project-sequence.

I'm looking for an example of exactly how I would implement what you describe.

Where exactly would I configure the logic that would concatenate a projectkey+version+component?

Any guidance/direction or resource pointing much appreciated.

[Nic Brough -Adaptavist-]

You need a bit of code. Two basic routes spring to mind:

1. In earlier versions of Jira, I wrote a simple function that ran when issues were created or updated, it did the "business logic" to build the string we wanted, and then dumped it in a read-only custom field (these are off-the-shelf in Jira and allow search and sort without you doing any work on them)

2. In later versions, I moved to "derived" fields. These have the same logic, but are actually a *type* of field in themselves. The code causes Jira to create and maintain their data without you having to intervene and work out how to run the logic on each update. (An example might be the "resolution date" field in Jira - you don't do anything with that, Jira updates it automatically for you)

On the coding side, you need to write a plugin to do either of those. However, I'd seriously consider using the "script runner" plugin to do it, as that allows you to skip all the structural work and simply dive into the "business logic" (and has examples. Of derived fields :-) ) https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner

[Steve Brackenbury]

Thanks for the detail Nic. Will pursue this avenue. May be back to bug you once I've done a little more research :-)

...Steve