How to Create a Custom Field Similar to Versions (Managed via Project Admin Section)?

[Ryan Murphy]

I've been told I need to have a custom field that allows each project lead to manage it similar to how the Version field is currently set up; however, the Version field is already being used for something else.

The field needs to:

• Be managed on a project-by-project basis. Values in Project A should not be allowable in Project B.
• Be managed by the project lead via the project admin section, not the system admin.
• Allow the project lead to create new values.
• Allow the project lead to archive older values to prevent them from appearing in issues going forward.
• Allow anyone to pull up issues regardless of whether a value is active or archived (via the Issue Nagivator, for example).
• If a value needs to be deleted, allow a method to transfer all affected issues to a different value (or no value, if needed).

Please let me know if there's a way to do this. I'm not sure whether it involves writing some custom code or maybe using a plug in out there.

[Holger Schimanski · Accepted solution]

Project Specific Select Field plugin might be a solution for your problem.

@Ryan Guess you talking about this plugin? Yes, I dropped development and removed it from Marketplace a couple of time ago, but after getting requests from users I picked up development again. Now it is a commercial plugin and available for JIRA 5.1 and 6.0 (6.1 already in planning).

Cheers
Holger

[Ryan Murphy]

Thanks so much for keeping up with development. We managed to find your plugin few days after you reposted it, have tested it successfully with no problems and are working through convincing our administrators to purchase the license. Please keep up development!

[Ryan Murphy]

Sadly, no. I'm still stuck and having to use an alternate unpreferred solution for now.

I saw that there was plug-in that handled this logic but it appeared the developer stopped supporting it and it doesn't work with the most recent version of Jira. It would be great if someone would be able to pick it up and keep it up to date, but I can't hold my breath on it any longer.

I'm hoping someone out there has some suggestions that could work for my requirements.

[BentS]

Hi, Ryan. Did you find any solution to your question? I have the same requirement as you and the answer posted do not solve the case. Any ideas or plugins you found?

[Vidic Florjan]

Requirement 1: Be managed on a project-by-project basis. Values in Project A should not be allowable in Project B.

You can use Context option to change the project(s) and issue type(s) for which a given 'Default Value' and 'Options' will apply (https://confluence.atlassian.com/display/JIRA/Configuring+a+Custom+Field):

To add a new context:

1. Log in as a user with the JIRA Administrators global permission.

2. Choose the cog icon at top right of the screen, then choose Issues. Select Fields > Custom Fields to open the 'Custom Fields' page. Keyboard shortcut: g + g + start typing custom fields

3. Locate the relevant custom field and choose cog icon > Configure.

4. Click the Add new contextlink . The 'Add configuration scheme context' page will be displayed (see below).

   • Under 'Add configuration scheme context', enter a 'Label' and 'Description' for your new context — these are used for administrative purposes only and will not be shown to your end-users.
   • Under 'Choose applicable issue types', select the issue type(s) to which you want this Default Value and Options to apply. You can select Any issue types if you wish.
   • Under 'Choose applicable contexts', select the project(s) to which you want this Default Value and Options to apply. Note that this will apply to only issues with the selected issue type(s) as above.

A custom field can only have one context per JIRA project. So you cannot have multiple contexts for different issue types in the same project.

Requirements 2, 3, 4 and 5: Be managed by the project lead via the project admin section, not the system admin.

There are only two fields whose values you can originally edit in admin section: components and versions.

It is quite difficult and complicated to achieve these requests. I'm not sure if this is really neccesary.

If you really need these features you can try with:

a.) Script Runner and Behaviours plugin (programming skills are necessary)

Link to example of the Behaviours plugin for: "Add or remove options to single or multi-select fields":

https://jamieechlin.atlassian.net/wiki/display/JBHV/Miscellaneous+Behaviours+Examples#MiscellaneousBehavioursExamples-Addorremoveoptionstosingleormulti-selectfields

or

b.) use functions of other plugins like eFeed, table grid plugin for JIRA to get information of custom field options from jira database (you need to be experienced Jira user and the know jira's database structure)

Possible plan:
1. Prepare special project for "Change management" of custom field values

2. Create custom fields for change custom field options and relate them to screens of the project (for edit and delete options fill content of the drop down lists from the jira database)

3. Allow special users to use this project and edit values through transition postfunctions - one for create, one for edit, one for delete
(workflow: customers can request changes, special users (e.g. your project leads) can resolve requests).