Hi Martin,

Please see JRA-25034, the fix for which will be available to Version 4.4.1

This fix appears to have broken our usage of the remote API, and the remote API does not appear to have any access to the key-value (id-text) pairs for Selection List-types of custom fields.
e.g. If I have a select list 'customField_123' and it allows these value to be selected:

If my issue, TICKET-550 has OptionB selected for this customField_123, I now see the selected value as '10014' with no indication of 'OptionB'.
I cannot get access to the list of id-text mappings for customField_123 via the remote API, which means I must manually identify, notice, synchronize, and maintain any and all changes to these lists separately from the JIRA configuration.
Whereas the RemoteIssue.customFieldValues used to contain RemoteCustomFieldValue instances that had the selected text value(s) (semantically very important), now they have the 'id' number of the selection (semantically useless without mapping) and no way to discover the current mapping to the text value(s) via the same remote API.

Really sloppy, guys!

Hi Viðar,

I have raised JRA-25348 to specifically address this issue. Can you please have a look at my comments there.

We have a custom field that was sadly created a long time ago as a select field but is essentially a text field with a custom view that is a select box. Unfortunately the JIRA 4.4 update process wipes out the data in this field, bringing havoc to our customers!

Can you please change the process so that if you don't find an id for the value, you simply leave the old custom field value instead of writing null and corrupting the instance.

We have released a new version that is compatible with JIRA 4.4. However, JIRA 4.4 does allow users to update even if the plugin does not support JIRA 4.4. That mean we have no way of ensuring that our customers don't break their system because of this issue.

Please help since our customers are upgrading to JIRA 4.4 with an incompatible version of our plugin and thus destroying their data.

Resolved! In JIRA 4.4, you can edit the options in a select list to your heart's content.

Only select and multi-select custom field types are effected by this change. Any custom fields of these types will continue to operate correctly, the database will be updated during the upgrade to 4.4. Third party custom field types that extend the select and multi-select custom field types may break, but that depends upon their implementation, for example if they provided different templates for viewing or editing these would need to be updated.

Plugins that provide custom field types that extend select and multi-select custom field types, can build a plugin that is compatible with both JIRA 4.3 and JIRA 4.4 but that may not be practical in some cases and it may be easier to have separate versions.

Does this feature mean that all custom fields implemented prior to JIRA 4.4 will break?
Will plugins that implement custom fields and upgrade to this new structure no longer be compatible to older JIRA versions (e.g., JIRA 4.3)?

@Iver,

Yes there is another 4.3 bug fix release before we release 4.4.
At this stage we do not yet have a 4.4 release date and we will update this issue when we are more certain of the release date.

Thanks for your interest in 4.4!

Cheers,
Roy

Do you have anything close to a release date for version 4.4 (with editing of cascading select and select fields implemented)? I'm desperately waiting for this release..... Looks like there is another bug fix release on the way before the release of 4.4???

The "recently updated" section on CAC gave it all away....
I echo the kudos for Trevor Campbell. This will cut the number of Jira restarts we have to do by 80% at least.

Ha Ha Roy - David beat you to this one and JRA-9 by minutes!

@David - well spotted

Thanks go to Trevor Campbell who took this on as a 20% project.

Looks like this really will NOT see it's 8th birthday:
http://confluence.atlassian.com/display/JIRA/JIRA+4.4+EAP+3+Release+Notes#JIRA4.4EAP3ReleaseNotes-EditableOptionsforCustomFields%28newinEAP3%29

I have a feeling my feelings were misplaced it seems. I had my hopes up in April last year while we had some JIRA brainiacs working on the issue. We spiked it, we evaluated the effort against other stuff we are doing and we stopped working on it.

As promised, I'm here for the 7th birthday party! Any bets being taken on reaching the great age of 8??

Paul Slade,
What's your feeling on this now?

I had to shutdown, run the SQL commands, and then carry out a 25 minute re-index.
All this to remove an apostrophe from a customer name.
@Paul, I sincerely hope Atlassian are getting this fixed in 4.3 if your suggestion is anything to go by.

The workaround requires JIRA showdown , which is not a viable solution most of the time. JIRA System Admin should be able to modify the customer field options real-time.

Workaround : http://confluence.atlassian.com/display/JIRA/Editing+a+custom+field+option

Adding my vote here as well. If there was at least the option when deleting a value to map those issues with said value to another in the list, it would satisfy my needs.

I have a feeling this will not see it's 7th birthday...

Aha, I miss the 6th birthday party, maybe we'll meet it's 7th birthday party.

I have implemented Gavin Lasnitzki's workaround posted above. Worked great! Thanks Gavin.

To anyone who trys his fix, be sure to reindex your jira after you roll it out.

I would still love to see an official fix for this.

Need this feature ASAP!

Belated birthday wishes JRA-2983.

Add me as a plus one for the 7th birthday party next year...

As a belated 6th birthday gift, I'm adding my vote and will join the many watchers to keep a close eye on you as you continue to age but not advance. Time for some remedial classes?

Nice Dan! - I had to add some balloons...

Dear JRA-2983,

Happy Birthday! Sorry I'm a little late this year, but I hope you had fun at your 6th birthday party with all your friends.

If you guys ever get around to fixing this issue, please consider internationalization while you're at it.

Cheers.

Applause to Neil! Atlassian, Let's rightfully focus on data integrity issues before more bells and whistles, please.

Hi JIRA folk,

This is very poor. I have an enterprise license, I expect an enterprise system.

(And a round of applause for that statement )

I can't bulk change earlier issues to new values as is suggested here. In a real world company you have auditors who come in and check old JIRAs and want to know why things aren't there any more. It would be absolutely unacceptable for a value to have been removed or changed from what it originally was.

I can't see a solution to this - correct me if I'm wrong.

Scott - I read your comments. Good breakdown of what's required to fix it. Sounds dead easy and is clearly something any half-capable developer could do.

Yes you have people voting on issues. Good system...BUT...if you have more people voting on glamour features like the, quite frankly, slow new UI you've got rather than on features that make JIRA viable for decent sized companies that have to deal with issues such as compliance, audit and regulation - then you're making a mistake.

Neil

Adding a new option then moving the affected issues to the new option tends to break anyone's filter that is using the original value.

I too vote for the archive option. We have a field that keeps growing in options. I cannot remove old options because I will loose my auditability for all issues with those options. The field will soon have so many options it will be unusable.

Hi Scott,
I looked at that last week and JQL does look very good. My immediate problem
is that the Database Values plug-in
(http://confluence.atlassian.com/display/JIRAEXT/Database+Values+JIRA+Plugin)
that I want to use to bring in my Support Identifier and Customer name and
contacts does not work with Jira 4.
Looking at the problem at a more strategic level I would very much like to
have single ids for a single component. That would make reporting easier and
making KnowledgeBase entries easier. I want to use wikidSmart semantics
(http://semanticweb.org/wiki/Wikidsmart) in the long term and having more than
one component with the same meaning is not conducive to making good
ontologies.

Is the uniqueness of an option dependent on the id of the custom field ID? Can
I manually change the IDs to be the same for options that I know are the same
semantically speaking?

Sincerely

Jan Carlin
Director of Support Services
Kaazing Corp.

Yes, being able to "archive" and edit options in a custom field would be extremely helpful.

For me, this is almost a showstopper.

Jan,

Does JIRA 4's JQL help at all? You can search for custom fields by value across multiple projects. You can also set up more complicated searches eg:

value in ("XYZ, "ABC")

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