JIRA 3.5 Upgrade Guide

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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 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 permission

JIRA 3.5 introduces the global Bulk Change permission. This permission governs the ability to execute the bulk change operations:

  • Workflow Transition
  • Edit
  • Move
  • Delete

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 changes

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:

void createValues(CustomField field, Long issueId, String defaultValueMarker, PersistenceFieldType persistenceFieldType, Collection values, String parentKey);


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 Changes

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 Version object.

This was done to handle an improved version custom field which can be a mutli-select version custom field as well

Last modified on Jun 15, 2009

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.