Changes to the custom field types code

For JIRA 3.4, there has been further upgrades to the custom fields code. If you have written your own Custom Field Types of Custom Field Searchers, you'll want to read this document. We recommend that you ensure that your custom field types compile against the latest 3.4 build and verify this under a testing environment before putting it into production.

You can download the latest JIRA Development Kit from its confluence space.

CustomFieldType Interface changes

CustomFieldConfig and CustomFieldConfigItemType changed to FieldConfig and FieldConfigItemType

Note that the references to CustomFieldConfig and CustomFieldConfigItemType has become FieldConfig and FieldConfigItemType respectively. This change is to bring CustomFields and SystemFields closer so that, in the future, fields can be configured in uniform way.

com.atlassian.jira.issue.customfields.config.CustomFieldConfig;
com.atlassian.jira.issue.customfields.config.CustomFieldConfigItemType;

has become

com.atlassian.jira.issue.fields.config.FieldConfig;
com.atlassian.jira.issue.fields.config.FieldConfigItemType;

A straight replacement should do the trick.

isRenderable()

With the addition of renderers in JIRA 3.4 there has been a minor addition to the CustomFieldType interface. There is a now a method of the signature:

public boolean isRenderable();

There is a default implementation of this method in the AbstractCustomFieldType class that returns false. If you are extending any of the existing base classes, AbstractCustomFieldType, TextCFType, SelectCFType, then there are no changes needed to upgrade your CustomField Types.

If you are implementing the CustomFieldType interface then you will need to implement the isRenderable method in your class. To retain the functionallity that you always had the method should return false. With the introduction of renderable fields in JIRA 3.4 if you return true in the isRenderable method then you will be able to assign the custom field a renderer. This only really makes sense for text fields where you can use the power of the wiki syntax.

getChangelogString()

To better support logging of change history from custom fields there is now a method of the signature:

public String getChangelogString(CustomField field, Object value);

This method allows a custom field type to provide a string that can give a custom fields value meaning. The two examples that ship with JIRA are the ProjectPicker and VersionPicker custom fields. Both of these fields store the database id of the value (e.g. My Project is id 10000, so it stores 10000). The ProjectCFType object will return the value 'My Project' from this new method so that we can register in the change item bean that the string is 'My Project' and that the value is '10000'. The AbstractCustomFieldType object returns null for this method by default. If you are extending any of the existing base classes, AbstractCustomFieldType, TextCFType, SelectCFType, then there are no changes needed to upgrade your CustomField Types.