A custom field - that's sorta single select and sorta text...

[James Mason]

Feels like a classic case of not quite wanting either of two mutually exclusive alternatives...

• I want a custom field with a drop down of standard alternatives.
• I don't want to preclude the field from containing - or being set to - values other than those presently established in the drop down list.
• I want to be able to change the contents of the drop down list over time - to contain the values that are the most sensible possibilities (essentially a subset of the actual values that the field could take on).

I've seen a lot of discussion that seems to splash around this idea - but I'm still kind of perplexed as to whether it's possible.

The application is a set of release versions, but:

• The version set needs to be maintainable across MANY projects (shouldn't require per-project maintenance).
• Ideally, the drop down list would contain the small number of release versions of current interest - without precluding other settings (we have 20+ years of version history).
• Over time, we should be able to change the subset of versions present in the drop-down - even though existing issues may have values no longer present on the drop down list.

Under the covers - this feels like a simple text field or text value.  Just don't have enough Jira knowledge to understand if it can be prettied up with convenient defaults.

[Earl McCutcheon]

Hi James,

Thanks for reaching out and that is an interesting idea, but as you noted "a classic case of not quite wanting either of two mutually exclusive alternatives" makes it a highly complex design to try to implement as its going to against the base design principles of how a project is structured.

Fundamentally, Jira is set up so that a Project is a grouping of issues that have direct relation to the overall goal elements within that project the issue is part of, releases are considered one of those direct goals.  The issues within that project are then sub categorized into cross functional groupings of various entities that do cross projects to act as links between related items, such as Issue links or issue hierarchies for a high level example, like the Issue type mappings between "Epic >> Story >> Subtask" the Epic level is designed to be cross project oriented item spanning a long period of time with a broad rang of items included, the story is designed to narrow that down further as a project specific focus area, then the sub task is even more granulized as a dedicated portion of the parent Story directly tied to it as a specific task.

While there are elements that do meed some of the criteria you are looking for, as and example the first grouping of questions you had:

• I want a custom field with a drop down of standard alternatives.
• I don't want to preclude the field from containing - or being set to - values other than those presently established in the drop down list.
• I want to be able to change the contents of the drop down list over time - to contain the values that are the most sensible possibilities (essentially a subset of the actual values that the field could take on).

All the checkpoints for this behavior you can be achieved by creating  custom field of type "labels".  A labels field will allow for a dropdown list of suggestions based on most recent:

With an option to start typing to narrow the results or create a new custom label for the field ad-hoc:

The way that I am reading your layout conceptually, where you would cross this field type over to something similar of a version management field gets pretty hard to track quite quickly, as everything becomes basically one big giant project where any issue can be part of any release across any product with no seperation between the items other than the field options,  at which point just creating one project for every needed action would be a much more simple solution and just using the versions fields in a single giant project of everything, and just defining the Product in the version naming  conventions, However I would not recomend doing something like this at all because it would be a mess to manage.

To take a different approach to this though there are some add-ons that can help out.  First I would recomend checking out Portfolio for Jira  which is a tool made by Atlassian for roadmaping issues and the structural layout and a general overview to look at can be found here: "Epics, Stories, Themes, and Initiatives" that goes into some detail on how the issues can be rearranged into additional groupings for more broad issue management options and this tool does have a direct "Cross Project Release" mapping that it implements, a little different than how you specified but would try to bring the idea in line with the current expectations of the releases in Jira.

Then off the top of my head two third party apps that have similar yet different approaches to Portfolio and can alter the behavior to provide additional cross project functionality around the releases would be  "Structure for Jira"  OR "Zapi" that I would say check out as well to see if they can be utilized to your needs.

Regards,
Earl