Changes to the custom field types code

For JIRA 3.3, 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.3 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

We removed all references to GenericValue objects in the CustomFieldType and replaced it with Issue. The issue object provides powerful accessors to the issue's parameters such as affects versions and components. If you still need the old GenericValue object, you can call getGenericValue on the issue object.

We've also added a new method to the interface.

    /**
     * Returns a list of indexers that will be used for the field. This will over-ride the anonymous searcher specified
     * by {@link AbstractCustomFieldSearcher#getRelatedIndexers()} and {@link AbstractCustomFieldSearcher#index(Document,
     * CustomField, Object)}
     *
     * @return List of instantiated and initialised {@link FieldIndexer} objects. Null if no related indexers.
     */
    List getRelatedIndexers(CustomField customField);

Through this method you can over-ride how this custom field will get indexed.

CustomFieldSearcher Interface over-haul

The CustomFieldSearcher interface now extends the new IssueSearcher interface. This allows you to write more flexible searchers as well as easily extend and reuse code from the default system searchers.

If you haven't developed your own custom searchers, then there's nothing you need to do. If you do have custom searchers but they extend AbstractCustomFieldSearcher then you shouldn't have to make any changes to the Java code as we have tried to keep this class backwards compatible. However, you should still recompile to make sure.

You will need to update all velocity pages used by the searcher. For the edit pages you'll need to use the new header (rather than the controlHeaders)

#searcherEditHeader ($customField.id $customField.name)

...

#searcherEditFooter ($customField.id $customField.description)

and for the view templates:

#searcherHeader ($customField)

...

#searcherFooter ($customField)

This change is in order to give the search templates greater flexibility (i.e. allow different rendering behaviour of the searcher from the standard edit screens.