JIRA 4.3 : JIRA 3.5 Upgrade Guide
This page last changed on Jun 14, 2009 by alui.
JIRA 3.5 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.5 (release notes) from JIRA 3.4.3. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here. JIRA 3.5 Jira Service extension
In JIRA 3.5 the getName() and setName(String name) methods was added to the com.atlassian.jira.service.JiraService interface. This method should return and set the name of the service respectively. The name of the service can be used to identify a service uniquely. (Fixed made due to JRA-8352 bug) Therefore, if you have implemented this interface, you will need to implement these methods and recompile your service(s) before deploying it into JIRA 3.5. If you have extended a JIRA class instead, e.g. com.atlassian.jira.service.AbstractService or com.atlassian.jira.service.JiraServiceContainer you do not need to modify your custom services. Introduction of global Bulk Change permissionJIRA 3.5 introduces the global Bulk Change permission. This permission governs the ability to execute the bulk change operations:
An upgrade task has been added to grant the new Bulk Change permission to all groups with the global JIRA Users permission. The JIRA documentation includes further details on this new permission.
CustomFieldPersister changesCustomFieldPersister is used to store custom field values to database. The methods of this class has been refactored to remove the redundant parameter, defaultValueMarker. For example, the create values method went from: void createValues(CustomField field, Long issueId, String defaultValueMarker, PersistenceFieldType persistenceFieldType, Collection values, String parentKey); to: void createValues(CustomField field, Long issueId, PersistenceFieldType persistenceFieldType, Collection values, String parentKey); You will need to update and recompile any CustomFieldType that you wrote to use this new interface. VersionCFType ChangesThis affects plugin writers who uses the version custom field VersionCFType. The change is that previously the Transport Object type was a single Version object, but it is now a collection that contains a single Version object. This was done to handle an improved version custom field which can be a mutli-select version custom field as well |
![]() |
Document generated by Confluence on Mar 27, 2011 18:42 |