Incrementing custom field with properties similar to project key?

[Michael Thompson]

I have an interesting challenge. We have a project to handle a multi-year project to move applications into Amazon AWS. In this project there are master issues for each application and environment, and each master contains anywhere from 5 to 25 subtasks. Each of these subtasks has a specific ID type (let's call them A, B, C for purposes of this question). Our Director would like to be able to set an incrementing value for all of these ID-linked subtasks.

For example, master ticket FOO-1 has 6 subtasks, two of each ID type. They should be coded A-1, A-2, B-1, B-2, C-1, C-2.  Master ticket FOO-2 has 5 subtasks, of types A and C. They should be A-3, A-4, A-5, C-3, C-4. Master ticket FOO-3 has 5 subtasks, all type B. They would be B-3 through B-7. And so forth.

What would be the easiest way to build something like this? Is it even possible?

[Mark Segall · Accepted solution]

Hi @Michael Thompson - It would help to understand the "why" behind the additional unique identifier when every issue already has a unique key.  What is the end goal for these identifiers?  Is it for reporting, some type of sorting, etc.?

It should be possible to do this, but having the extra context can help ensure we're going down the right path.

[Michael Thompson]

Thanks @Mark Segall I was trying to keep it succinct. :-) In the beginning the project was easy enough to manage with just a few issues, but after two years there have been many, many additions and specifications to the types of subtasks (created in AWS, migrated to AWS, pre-build work, post-build work, etc).

The goal is to sort these out for reporting purposes so that senior management can see the number or each type of subtask.

As I write this I'm thinking one option is actually to create multiple sub-task issue types, but if the management team wants more clarity that might not be an option.  But let me toss that back to them and see what they say, maybe I just solved my own problem!

[Mark Segall]

I typically only go with a new issue type when:

1. I need a separate workflow
2. Field requirements are dramatically different enough to warrant unique screen schemes

If your intent is for sorting/reporting, you could simply add a layer of metadata leveraging components or custom fields (or labels if the need is for a quick point-in-time grouping of issues)

[Michael Thompson]

Hmm, yes I agree with you, and I think that the problem I am having is a miscommunication on the needs. To avoid confusion, I am going to close out this question and get some clarity. I think my problem description is not correct.

Thank you Mark, for purposes of this thread I will go with your answer!