On behalf of a customer from SAC

Editing of drop down custom fields value should be enabled. For now if we have to rename a custom field value we have to do lots of tricks.

Regards,
Nawaz Quadri

Hi,

The edit-textarea.vm has the number of rows changed (to view more text at a time). This is unrelated to this issue (it got included by mistake). The cascadingUtil-min.js was not updated, but I do not think it is used. I only did some quick testing.

So you basically used cascading select fields and created two new top-level options? Nice hack However, there is also a cascadingUtil-min.js file that didn't appear to be get updated in the zip file but may need to be. Also, the edit-textarea.vm field that was included in the attached zip file doesn't seem to differ from original 13.3.2 one - some mistake?

~Matt

Hi,

Here is a partial solution to this problem. It is based on a suggestion in a linked issue.

I have updated the select, multi-select and cascade-select to support "disabled" and "removed" options.

To install, extract the files from enhanced-custom-fields.zip into your jira directory. These replace the standard versions.

The new versions support 2 special "options". These are "Disabled" and "Removed".
Once these templates are installed, you can disable options by creating a "Disabled" option and moving options under it. To remove options, create a "Removed" option and move options below it.

See enhanced-custom-fields-screenshot, where "A" and "B" are active, "C" and "D" are disabled and "E" is removed.

I agree that this is a must have. My company recently implemented JIRA as our issue tracker and this limitation has bitten me several times. Please fix this issue!

If I had to do this for a client, I'd be using the JIRA CLI in some form. Of course, the API as it stands doesn't have a method to add a value to a system select field, or a dynamic search filter, or the other things. But what I'd do is write an RPC plugin to give you those methods, and then do it from the CLI. That's about 8 hours, a bit more for a more generic API. It could be written as an action plugin too, but that takes me longer to test these days.

Perhaps one of the developers would be kind enough to use some of their 20% time on this issue. I'm sure it's not as exciting as some of the other work out there, but would definitely be appreciated by the user community.

I agree completely with the previous two comments as well: I can understand that it may not be feasible to re-engineer the infrastructure surrounding select-list fields. But an option to automate changes to values would be preferable to five years of inaction on the issue.

Agree with Osis - If the permanent fix is too painful for Atlassian, then at least give us a tool to make the administrative overhead of renames less painful for us.

But it would be a simple 2 hour temporary fix to add some automated updater for the changed values, without ever needing to touch the storage mechanism, wouldn't it? Basically the same thing that we have to do now manually (add new value -> find issues with old value -> bulk change to new value -> delete old value from list, rinse & repeat for every changed value), but simplified & automated so that a user only has to click "Edit", enter new value, and "OK". That would save a lot of hassle (especially since admins sometimes don't have edit rights in all projects and/or can access all security levels) for the users, and would be a nice "while you wait for the full rewrite" courtesy tempfix.

Guys,

Just to give you an update on why this is not a simple 2 hour fix for us. Note - I stopped developing on JIRA a while ago (in management now - eek!), but will do my best.

Currently we store these values in the database as 'values', not as ids that refer to values. That means when you say customfield = 'Big' it stores 'Big' in the database, and not the id of '1'.

To fix this, we'd need to:

• change the datamodel for storing these values in the database
• change the code that you use at the UI end for interacting with these values
• change the searches so that you can search for the values (do the value to id translation & back again)
• change the remote API & XML view on these issues
• change the 'change history' to work with new values
• write an upgrade task to change the values to ids
• write an upgrade task to go through all the existing values in the database and migrate to ids.

Look - I agree with you - I can completely understand that this issue would piss me off if I had to do it every day. Please continue to make noise on this. We haven't made any plans for JIRA 4.1 yet, but initial thoughts are around the customer experience, and smaller improvements. Brian Lane (JIRA Product Manager) reads every comment.

I agree with the past five years' worth of comments. That this issue has not yet been fixed is staggering.

Unfortunately when you are transparent with your customers, they get to see what has been prioritised, and what hasn't. Unfortunately we can't please all the people all the time, but at least with Atlassian you get to vote, you get to interact with the developers, and you get to see how things are progressing. I don't know of any other company that has been running a public issue tracker for 5 years, and I'd guarantee that other companies also have open issues, but with them you don't get to see what they are.

I shouldn't be using this as an excuse - you as our customers expect and deserve better. However, I hate it when our transparency gets used against us, especially as when our competitors don't have the same level of openness.

I agree with the past five years' worth of comments. That this issue has not yet been fixed is staggering.

I'd love to have the ability to rename a list option from 'foo' to 'bar' without having to create a new 'bar' option, open all closed issues under 'foo', reclassify all 'foo' issues to the brand new category of 'bar', and then close all the issues I just re-opened (thus resetting their closed date).

This is a critical blocker for me, and is led me to strongly consider abandoning Jira in favour of a different issue tracker. The fortnight of work involved in moving our Jira database over to the new system is nothing compared to the pain I foresee in my life if I'm so foolish as to try to rename the 'foo' option.

Hi Team,

We are very desperately waiting for this to resolve.

Thanks
~Subodh

This issue detracts from an otherwise excellent product.

Is there needed some kind of major rewrite? I don't understand why it looks like big problem here for many years.
In our production environment it is going very fast to be blocker issue.

Should be nice to see it in 3.x

This seems like such a basic feature, and yet it sits here for 5 years? Kind of disappointing.

Added my vote as well.

Arthur hi - and thanks.

1st of all - thanks for trying to resolve this.

however in my experience updating DB directly casues some anonmalies in indexing and allocated values for issues / options.

moreover - Re-indexing - at least on our system - takes ~ 20-30 Minutes To complete each time

none the less - i'll try doing so in our non Prodcution system and see how it goes.

would expect Atlassisan to resolve this though anyway - as the community can contribute only up to a certain point...

I succeeded by updating database data with sql , steps below maybe can help you:
1.update customfieldoption set customvalue='new value' where customvalue='old value';
2.update customfieldvalue set stringvalue='new value' where stringvalue='old value';
3.restart JIRA, jira load these options in memory
4. reindex

Version 4.x , What long time!

I'm trying to modify database data to resolve this problem.

Hello,

While we are unable to commit to this for our next major release, I am very aware of the situation when it comes to renaming various items in JIRA. Not only this issue, but there are several other high requested issues involving the ability to rename various objects within JIRA.

Our next major release (4.0) is quite full already with work, but renaming (in general) is something we will be investigating for a potential 4.x

Regards,

Brian Lane
JIRA Product Manager

We use V3.6.5 Enterprise Edition and use over 100 Custom Fields of all shapes and sizes with some lists having more than 200 Items...

Ability to:
Rename / Hide / Merge Options - just like with Versions and Component handling should have been there out of the box.

Only acceptable workaround ( which is not implemented as well ) - is the ability to Update all issues disregarding their status - but this is also not the case.

I'm deeply disappointed that Atlassian Chooses to overlook this High profile "improvement"/"Bug Fix" for more than 5 Years now...

up to a degree in which i cannot recommend my CEO to upgrade the Enterprise version we got to 3.13.1 - despite its numerous enhancements over 3.6.5... - please set a Fix Version for this for the long ver due 4.0 version...

on that note - ability to provide Custom Field Options Editing by Non Admin Group / permissions would be appreciated as well!

I'm excited for the 5 year anniversary of this request.

Someone earlier wondered if there was a way to "hide" options. There is a way to do just that. Add a dummy value as an option (e.g. --INACTIVE--), re-order the options so that anything you want hidden is below the dummy value, and then modify the edit-select Velocity macro to display the currently selected option plus options above the dummy value.

It's not bullet-proof because it only takes care of editing/creating issues through the UI, but it's probably good enough for most situations. You can do the same thing for multi-select fields too.

I am out of the office until Thursday, September 25th. I will respond to your email after I return.

Thank you,
Margaret Votava

I'm also looking forward to this issue being addressed.

Does it really make sense that you can't rename an option, but have to create a new one and bulk change all existing issues that use the old option to use the new one?

Thanks,
Mike

I am a bit bamboozled that one cannot edit these values.

Then again having looked at how they're being used, it becomes clear why it's an issue:

<select>
	<option value="opt1">opt1</option>
	<option value="opt2">opt2</option>
	<option value="opt3">opt3</option>
</select>

(this is a pseudocode representation of the HTML source of an issue form with a custom select list property)

So there's no sense of a key/label with these values: the label is the value. Which means one cannot change the label because that's also changing the underlying data.

That's kind of a school boy error, innit?

I can't believe that JIRA Project Managers (PM) consider this capability to be so insignificant to the point that it's not wordy ramification. Application users pick and choose software based of easy of use and seamless operation. There is nothing seamless or easy of use it you make a mistake in a custom field and can NOT edited it, and must delete the entry just to recreate it again. To say nothing about all of the meticulous work needed it to properly correct any previously created entries with the modified entry.

Take note and fix this issue, after all it has been around for four years now.

Please get this fixed. Its senseless when I have X amount of archive releases so unfeasible to unarchive all of them just so I can edit a custom field.

This really needs to be fixed. I just had the QA team tell me the text on some values for a custom field needs to be edited for clarity and I have to tell them it's not possible. It seems like it would just be code to update the customfieldoption table plus any other places that store a copy (like work history - the changeitem table).

Any chance this will get looked at?

A possible workaround:

If you put your options in a database (you can manually just create a table in the JIRA database you already use), then you can use this plugin in stead of the build-in custom field. If you define a proper primary key in your table, then you can edit the database and all is well.
Ofcourse, you need to manually edit the database which is not as straight forward as editing things though the normal JIRA webinterface.

Absolutely this should be an high priority feature.

It is unbelievable that editing is not possible. This ia absolute basic functionality. Imagine there is a list of customers where it is possible to select multiple for one issue. Now the name of the customer changes (DaimlerChrysler gets Daimler). There is no way to migrate this name change in Jira, because it is used in multi-select fileds in different combinations.

The ability to edit a multi-tier select option custom field for us is completely vital. The process for changing a select option now involves an 8 or 9 step procedure, including:

• Adding new option in select list (this bit's easy)
• Filtering on all tickets with the old custom field AND closed
• Bulk reopening that filter AND changing select custom field on reopen window
• Filtering on new custom field
• Bulk resolving that filter (!)
• Bulk closing that filter
• Filtering on old custom field
• Bulk changing tickets with old custom field to new custom field
• Delete old custom field (if appropriate).

The problem with this procedure is:

• The resolution is only configurable on a bulk basis - you can't maintain the resolution on closed tickets !
• All the resolution dates are reset

This needs to be pushed into the roadmap, its inclusion is invaluable.

I absolutly agree with Stig, added my vote.

BTW: Why are bulk operations possible only on certain fields, not all fields including custom fields?

It would greatly improve the JIRA functionality if editing options was implemented. I hope this will be in the roadmap soon.

I would suggest it to work something like this: when finished editing an option (i.e. fixing a typo) JIRA should offer the choice of automatically applying the change to all issues having this option.

Something similar for deleting an option: having the choice of removing the option from all existing issues or just leaving them as is would be more convenient than only being forced to remove the option from all issues.

Just added my vote as well.

I add my vote, this is much needed !

We also need this enhancement! There needs to be a way to delete options from a drop-down or make an option unavailable. Please add to road map.

I add my vote.

We need this too.

It is a workaround to create a new option and move all issues to it by mass change. But it would be more comfortable to edit the options directly.

Thanks,

Irene

How can i move this issue in the road map?

Regards

It's actually in the top 35 most voted on issues!

Please add it to the road map.

Cesare,

Unfortunately this issue is not currently on the road map, so I am not able to provide an implementation date.

Hi Guys,

I think that one of the biggest problem in jira is related to this issue. We have a production environment where the option in every option list is increasing day by day and many of these options are currently not used but we cannot delete them.....

Are there any news about this improvement?

Best Regards
Cesare

I wonder if there is a simple way to "hide" an option from a select-list custom field. this would enable to retain values on issues that are already closed with a specific option value that we dont want to display any more in the select custom field. For example a "release name" custom field acting similarly to how the version field acts, once the version is closed the option doesn't show up any more in the select menu for "fix at" but it is not removed from the database... Once the release has ben "released" the name doesnt appear anymore as an option in the custom field.

Just wanted to do the same as Nyree, i. e. replace existing options with an option which also includes an icon using <img src=...>. On my test-system I also reached the point where I rated this task as too complex, especially as you will break any existing filters which rely on the fields value.

I think the main problem is that model and view are combined when defining options. I. e. if you want to change the look (e. g. color or icon) of your option you will also directly modify the model. I suggest to have something like two values to specify for list options: the key (in model) and the view to use (with HTML and such). In old systems both would be equal.

For separating model and view on existing systems I found a solution as documented in JRA-5703 which requires editing of view-rawtext.vm.

Hi Magali,

Unfortuantely I do not have a date for the implementation of this feature. For more information on the way Atlassian schedules improvements please see:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

Anton

any news on this improvement ?

Hi all,

indeed, it would be great to be able to edit the names given to the options in the custom fields ...
Thanks in advance for adding this option soon

Magali

Another case using the Enterprise Edition, Version 3.2:

We created a new custom field called severity with the same options as priority (excluding the images).

Issues were created, worked on and closed.

We then found that we wanted the image to appear next to the severity text as per priority.

To do this we had to explictly:

1. Add new options to the custom field with the image source,
2. Bulk change all open issues (pointing at the new option) AND
3. Reopen, select the new option and then close issues
4. Delete the old values

Just to have the new 'label' take effect.
I must say it was very time consuming.

For example, our orginal blocker option in the severity custom field hhad to be replaced with:

<img src="/images/icons/priority_blocker.gif"/> Blocker

The other options became:
<img src="/images/icons/priority_critical.gif"/> Critical
<img src="/images/icons/priority_major.gif"/> Major
<img src="/images/icons/priority_minor.gif"/> Minor
<img src="/images/icons/priority_trivial.gif"/> Trivial

Take a look at this issue also: JRA-1337