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.

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")

The fact that you cannot edit the values and the id's of a custom field renders them nearly useless for my purposes. I need to be able to run metrics reports off of the values and for some of my custom fields I need the ID's to be the same among several custom select lists.
I am trying Wim Deblauwe's database plugin and can control the IDs and values by keeping them in my own database table but each field's values cannot be made to be dependent on a value already in the form so I am stuck for now.

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!