JIRA 3.5 Upgrade Guide
This 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.
When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below.
JIRA 3.5 Jira Service extension
- If you have implemented a custom JIRA service you need to be aware of the following API change.
In JIRA 3.5 the
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.JiraServiceContainer you do not need to modify your custom services.
Introduction of global Bulk Change permission
JIRA 3.5 introduces the global Bulk Change permission. This permission governs the ability to execute the bulk change operations:
- Workflow Transition
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.
The decision to grant the Bulk Change permission should be considered carefully - the permission permits a user to modify a collection of accessible issues at once. For example, in JIRA installations configured to run in 'Public' mode (anybody can sign up and create issues), a user could comment on all accessible issues with the Bulk Change and Add Comments permission. Undoing such modifications may not be possible through the JIRA UI and may require changes made directly against the database.
CustomFieldPersister 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:
You will need to update and recompile any
CustomFieldType that you wrote to use this new interface.
This 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
This was done to handle an improved version custom field which can be a mutli-select version custom field as well