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; } } }

Custom field to automatically number requirements

Damian Le Gresl

We are trying to track our product requirements in JIRA, and have a project where each JIRA issue is a distinct feature. We now want to break down these features into numbered requirements that can be traced through development and test and are looking for a way to get them automatically numbered through a custom field.

So, if the parent feature is FEAT-123 we would like to create sub-tasks under this feature and have a custom field that is auto-populated with FEAT-123.1, FEAT-123.2, etc, so we would end up with:

FEAT-123

- FEAT-133 (with custom field value FEAT-123.1)

- FEAT-134 (with custom field value FEAT-123.2)

- FEAT-141 (with custom field value FEAT-123.3)

Is anyone aware of a custom field plugin that can achieve this, or can someone help us create a plugin to achieve this (we have little or no JIRA plugin development experience).

Alternatively is anyone else using JIRA to manage and auto-number requirements in a different way that removes the need to mess with custom fields?

Thanks!

Accepted answers

Damian Le Gresl

I have not received any further answers on this so we have decided to go with a simple <255 character text field that we will manually populate the requirement id. Not quite what I was hoping for, but I think we will be able to make it work.

All comments

Nic Brough -Adaptavist-

There is no way to do this. Jira takes the next free number for a new issue in a project and that is the end of the story. It uses this key in this format everywhere and simply does not have any way to support any other structure.

Having said that, you can add helpers:

I've seen fields which display (and allow search and sort) on the parent issue, so you see FEAT-123 for the parent and FEAT-123 / FEAT-456 for the child.

I've even modified that so that it *displays* as FEAT-123(456). Although the url for 456 is still FEAT-456, so it wasn't perfect, it did solve most of the problem. Later, I found an Apache wizard who persauded the Apache servers in front of Jira to rewrites/mangle incoming urls like jira/browse/FEAT-123(456) so that they resolved to the actual issue

Another approach I've seen was an auto-incrementing numeric field which the system generated on the sub-tasks.

Damian Le Gresl

Hi Nic, thanks for your quick response.

Just to clarify that I was not trying to change the JIRA issue auto-numbering system but to add a separate field that pulls the issue number of the parent and appends an auto-incrementing number and then stores it in a read-only field.

That said, it sounds like the solutions you mention go some way to what we want - can you recall where you saw these approaches (with links)?

Damian Le Gresl

Nic Brough -Adaptavist-

Sorry, I didn't see your comment earlier.

Links wouldn't work - the Jira installations in question are internal to the companies I was working for at the time. I admit that my modification was a simple tweak and recompile of code that my predecessor in the role had done.

Aviva

Hi,

I'm also looking for an "auto-incrementing numeric field" does such field exist?

How do I implement it?

Thanks,

Aviva

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

custom-field

jira

requirement