Upgrading custom CustomFieldTypes in JIRA 3.2

Changes to the custom field types code

For JIRA 3.2, there has been incremental upgrades to the custom fields code. If you have written your own Custom Field Types, you'll want to read this document. We recommend that you ensure that your custom field types still compile against the latest 3.2 build and verify this under a testing environment before putting it into production. It is vital that at the time of the data upgrade, all of your custom field types are functioning correctly, or else they may not be upgraded correctly.

• CustomFieldType Interface changes
• Velocity template changes
• Abstract class changes
• CustomFieldType deal with CustomFieldConfig and not CustomField objects

CustomFieldType Interface changes

There has been some new methods added to the CustomFieldType interface. You may need to implement them if you didn't extend one of the existing concrete classes or AbstractCustomFieldType. The main change here is that FieldValidationException are now thrown instead of CustomFieldValidationException and the addition of two methods.

    /**
     * Return the String value object from the CustomFieldParams. The object may be a single String (e.g. TextCFType,
     * List of Strings (e.g. MultiSelectCFType) or CustomFieldParams of Strings (e.g. CascadingSelectCFType)
     *
     * @param parameters - CustomFieldParams containing String values
     * @return String value object from the CustomFieldParams
     */
    public Object getStringValueFromCustomFieldParams(CustomFieldParams parameters);

    /**
     * Returns a List of {@link CustomFieldConfigItemType} objects.
     * This opens up possibilities for configurable custom fields
     *
     * @return List of {@link CustomFieldConfigItemType}
     */
    public List getConfigurationItemTypes();

Velocity Template Changes

The parameters passed to velocity templates for view and editing custom fields have also significantly changed. To update your velcoity templates, you should change your headers to be:

#controlHeader ($action $customField.id $customField.name $fieldLayoutItem.required $displayParameters.noHeader)
...
#controlFooter ($action $fieldLayoutItem.fieldDescription $displayParameters.noHeader)

Abstract class changes

There has also been changes to the abstract CustomfFieldTypes with an addition of a GenericConfigManager dependency. You'll need to add this to all constructors of classes which extends them. You can use GenericConfigManager as an arbitrary data store.

CustomFieldType deal with CustomFieldConfig and not CustomField objects

Custom fields can now be configured differently per context. Thus the CustomFieldType now gets passed the CustomFieldConfig object (which is an instance of the configuration set) rather than just the CustomField themselves.