Upgrading To JIRA 7
Compatibility with JIRA 7
ScriptRunner releases 4.2.x and above are compatible with JIRA 7, not below.
|Your scripts will fail if you upgrade without modifications.|
You will need to make some changes to your scripts to make them work with JIRA 7’s API. There is a guide to the major areas of change below.
|Use the script registry to quickly review all your code.|
Upgrades and staging Environments
If you do not have a staging environment you should invest the time it takes to create one. You should be able to reliably clone your production instance to the staging environment, so you can test plugins and upgrades.
A good strategy to follow is to
make changes now to remove all deprecated code, while you are using JIRA 6.3 or 6.4. Deprecations are shown with a yellow warning. If you do that your code has the best chance of working unchanged with JIRA 7.
once the deprecated code has been fixed, upgrade your staging instance to JIRA 7
use the script registry to make sure you don’t have any type checking errors, and test
if you need to make changes, record what they are
when you upgrade your production instance, if you are using inline scripts, you will need to make the same changes. For files, you can update your scripts directory, e.g. by merging from a branch
Removal of ComponentManager methods
ComponentManager methods have been removed. Typically these have been used to get at JIRA managers and services, even though they have been deprecated for several years.
Where previously you used any of these constructs:
import com.atlassian.jira.ComponentManager import com.atlassian.jira.bc.project.ProjectService def commentManager = ComponentManager.instance.commentManager // or def commentManager = ComponentManager.getInstance().getCommentManager() // or def commentManager = ComponentManager.getCommentManager() // getting some other type of service def projectService = ComponentManager.getInstance().getComponentInstanceOfType(ProjectService)
now you should use:
import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.bc.project.ProjectService def commentManager = ComponentAccessor.commentManager def projectService = ComponentAccessor.getComponent(ProjectService)
User replaced with ApplicationUser
Most methods that took or return a
User have been replaced with a
You will notice this if you have statically typed a
In this case the solution is to use dynamic typing (and remove the redundant
import com.atlassian.jira.component.ComponentAccessor def authContext = ComponentAccessor.jiraAuthenticationContext def user = authContext.getLoggedInUser()
The method that you pass the user object to will also have been changed to use an
ApplicationUser. In future, refrain from static typing objects (except for fields).
All methods that returned a GenericValue have been removed.
issue.priority would have returned a GenericValue, and you should have been using
In JIRA 7,
issue.priority returns a
Priority object, and getPriorityObject() has been deprecated.
So if you have done nothing since JIRA 4, your code may now be perfectly correct. If you have have attempted to keep up with the deprecations, you should now revert back to getPriority().
An exception would be if you were expecting a GenericValue, eg:
issue.priority.get("name") == "High"
This will no longer work, you should change it to:
issue.priority.name == "High"
Some methods on
com.atlassian.jira.issue.MutableIssue appear to have been capricously renamed, at least in RC3. It’s possible that this is a mistake and it will be rectified by the final release.
setComponents(Collection<org.ofbiz.core.entity.GenericValue> components) has been removed, and
setComponentObjects(Collection<ProjectComponent> components) has been renamed to
validateCreateProject where you specify all the parameters has been replaced by:
ProjectService.CreateProjectValidationResult validateCreateProject(ApplicationUser user, @Nonnull ProjectCreationData data)