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.