Preparing for JIRA 7.6

This page covers changes in JIRA 7.6 that can affect add-on compatibility and functionality. This includes changes to the JIRA platform and the JIRA applications (JIRA Core, JIRA Software, JIRA Service Desk).

As a rule, Atlassian makes every effort to inform add-on developers of known API changes as far in advance as possible. Where possible, we attach release targets. Unless otherwise indicated, every change on this page is expected to be released with the first public release of the JIRA Server 7.6 products. We also make release milestones available prior to the release:

  • For JIRA Server, the JIRA development team releases a number of EAP milestones prior to the final release, for customers and developers to keep abreast of upcoming changes. For more information on these releases, see JIRA EAP Releases.
  • For JIRA Cloud, the JIRA team releases updates to the JIRA Cloud products on a weekly basis. Add-ons that integrate with the JIRA Cloud products via Atlassian Connect should use the JIRA REST API, which is subject to the Atlassian REST API Policy.

We will update this page as development progresses, so please stay tuned for more updates. We also recommend following the JIRA news on Atlassian Developers blog for important announcements and helpful articles.


The risk level indicates the level of certainty we have that things will break if you are in the "Affected" column and you don't make the necessary changes.

Change. Platform/Application Risk level. Affects

Chage: Priority schemes (UI changes)

Platform/Application: JIRA Core, JIRA Software

Risk level: medium

Affects: Add-on developers using APIs to manage priorities in JIRA, and administrators.

With JIRA 7.6, we're introducing priority schemes that change the way priorities are managed. Now, by using priority schemes, you can associate different sets of priorities with your project.

This doesn't change your configuration until you create some schemes and make use of them. After the upgrade, all priorities are moved to the default priority scheme, which works like a global list of priorities (always includes all existing priorities). The default priority scheme can't be edited or deleted.

See Priority schemes – release notes.

Chage: Priority schemes (API changes)

 Platform/Application: JIRA Core, JIRA Software


Risk level: medium

Risk level: Add-on developers using APIs to manage priorities in JIRA.

Together with priority schemes, we've added and changed some APIs so that plugins can manage them.

See API changes for plugin developers.

Chage: API changes – experimental API

 Platform/Application: JIRA Service Desk

Risk level:low

Risk level: With an upcoming release of JIRA Service Desk, a number of the methods in our API will be moving out of the experimental state and in to standard API state. For most of these components the API will remain unchanged, but for some there will be adjustments which will represent a breaking change. 

See API changes – experimental API.

JIRA platform changes

All changes in JIRA platform are also relevant for JIRA Core and JIRA Software. 

Priority schemes – UI changes

For more information about managing priority schemes in the UI, see release notes.

Priority schemes – API changes for plugin developers

If you're a plugin developer, and want your plugin to manage priority schemes, take a look at this list of API changes. We've not only added new APIs that allow plugins to manage priority schemes, but we also changed the existing ones, which will most likely make your plugins incompatible. This is for priority schemes, the APIs for managing priorities don't change, but bear in mind that the current global list of priorities now becomes the default priority scheme, so your plugins might retrieve inaccurate data regarding priorities themselves. 

What's new?

We're adding these APIs to allow plugins to manage priority schemes. 


Method signature Javadoc

FieldConfigScheme createWithDefaultMapping(String name, String description, List<String> optionIds);


FieldConfigScheme updateWithDefaultMapping(FieldConfigScheme fieldConfigScheme, List<String> optionIds);


FieldConfig getFieldConfigForDefaultMapping(FieldConfigScheme fieldConfigScheme);

void delete(FieldConfigScheme fieldConfigScheme); Doc

FieldConfigScheme getScheme(Project project);


FieldConfigScheme getScheme(Long id);

List<FieldConfigScheme> getAllSchemes(); Doc
boolean isDefaultScheme(FieldConfigScheme fieldConfigScheme); Doc
FieldConfigScheme getDefaultScheme(); Doc
String getDefaultOption(IssueContext issueContext); Doc
String getDefaultOption(FieldConfig fieldConfig); Doc
void setDefaultOption(FieldConfig fieldConfig, String optionId); Doc
List<String> getOptions(IssueContext issueContext); Doc
List<String> getOptions(FieldConfig fieldConfig); Doc
void setOptions(FieldConfig fieldConfig, List<String> optionIds); Doc
void addOptionToDefault(String optionId); Doc
void removeOptionFromAllSchemes(String optionId); Doc
Collection<FieldConfigScheme> getAllRelatedSchemes(String optionId); Doc
void assignProject(@Nonnull FieldConfigScheme priorityFieldConfig, @Nonnull Project project); Doc
Set<Project> getProjectsWithScheme(@Nonnull FieldConfigScheme fieldConfigScheme); Doc
void unassignProject(@Nonnull FieldConfigScheme scheme, @Nonnull Project project); Doc

We're also adding new events for whenever a priority scheme is created, updated, or deleted.


Event Javadoc
com.atlassian.jira.event.issue.fields.config.manager.PrioritySchemeCreatedEvent Doc


com.atlassian.jira.event.issue.fields.config.manager.PrioritySchemeUpdatedEvent Doc

What's changing?

Some APIs also receive additional options, so that priorities are added or removed from priority schemes.

Classname - com.atlassian.jira.config.PriorityManager 

Method signature Change Javadoc
createPriority In addition to creating a priority, also adds this priority to the default priority scheme. Doc
removePriority In addition to removing a priority, also removes this priority from all priority schemes. Doc

What's deprecated?

These APIs are deprecated, and replaced by the new PrioritySchemeManager class.

Classname Method signature Replacement Javadoc
com.atlassian.jira.config.PriorityManager setDefaultPriority


#setDefaultOption(FieldConfig, String)




com.atlassian.jira.config.ConstantsManager getDefaultPriority


#getDefaultOption(com.atlassian.jira.issue.context.IssueContext), or






JIRA Service Desk changes

JIRA Service Desk has a number of elements of its API which are currently defined as experimental but that is about to change. With the 3.7.0 release a number of components were either deprecated for removal, or updated with details about how they will represent a breaking change in a future release. Well, those changes are coming now in the JIRA Service Desk 3.9.0 release. This release will also be moving the majority of the components in our API out of the experimental state and into a standard public API state. 

What's Changing?

A number of components will have breaking changes. The changes are relatively minor and revolve around changes to IDs that will be returning integers rather than longs. This helps us to align with the values that we are currently storing in the database and will stop us having to do a lot of unnecessary type conversion in the future. 


Breaking change

Old method signature

Old javadoc

New method signature

New javadoc


The getServiceDeskById method will require an integer rather than a long as the serviceDeskId.

Either<AnError, ServiceDesk> getServiceDeskById(ApplicationUser user, long serviceDeskId);

Either<AnError, ServiceDesk> getServiceDeskById(ApplicationUser user, int serviceDeskId);


The getPortalForId method will request and integer rather than a long as the portalId.

Either<AnError, Portal> getPortalForId(ApplicationUser user, longportalId);

Either<AnError, Portal> getPortalForId(ApplicationUser user, intportalId);


The return value for this method will return an integer rather than a long.

long getId()

int getId()

The return value for this method will return an integer rather than a long.

long getServiceDeskId()

int getServiceDeskId()


The return value for this method will return an integer rather than a long.

Optional<Long> queueId();

Optional<Integer> queueId();

The return value for this method will return an integer rather than a long.



QueueQuery Builder interface

The serviceDeskID interface will require an integer rather than a long as the serviceDeskId

Builder serviceDeskId(longserviceDeskId);

Builder serviceDeskId(intserviceDeskId);

The queueId interface will require an integer rather than a long as the queueId

Builder queueId(longqueueId);

Builder queueId(intqueueId);


The return values for this method will return an integer rather than a long



The return values for this method will return an integer rather than a long



QueueRequestQuery Builder interface

The serviceDeskID interface will require an integer rather than a long as the serviceDeskId

Builder serviceDeskId(longserviceDeskId);

Builder serviceDeskId(intserviceDeskId);

The queueId interface will require an integer rather than a long as the queueId

Builder queueId(longqueueId);

Builder queueId(intqueueId);


The getPortalId method will return an integer instead of a long.




The getId method will return an integer instead of a long.

long getId();

int getId();


The id method will return an integerinstead of a long.

Optional<Long> id();

Optional<Integer> id();

SlaInformationQuery Builder

The id interface will require an integer instead of a long.

Builder id(Long slaMetricId);

Builder id(Integer slaMetricId);


What's been removed?

As well as the breaking changes listed above, we've also removed a number of existing experimental API that were deprecated previously. This is being done to make the new public API state, both cleaner and more useable.What's been removed? 

The following classes have been removed:

  • CreateInternalCommentParameters

  • CreatePublicCommentParameters

  • ServiceDeskCommentParameters

  • ValidatedInternalCommentParameters

  • ValidatedPublicCommentParameters

  • RequestTypeUpdateParameters

  • RequestTypeQueryParameters

In addition, the following methods have been removed. Most of these have equivalents which can now be used as a direct replacement. The ones that don't have been deemed insufficient for making public, as the usage was not recommended.


Method signature

Old javadoc


New javadoc


Either<AnError, ValidatedPublicCommentParameters> validatePublicComment(@NonnullApplicationUser user, @NonnullCreatePublicCommentParameters commentInternalParameters);

#createServiceDeskComment(ApplicationUser, ServiceDeskCommentCreateParameters)

Either<AnError, ValidatedInternalCommentParameters> validateInternalComment(@NonnullApplicationUser user, @NonnullCreateInternalCommentParameters commentPublicParameters);

#createServiceDeskComment(ApplicationUser, ServiceDeskCommentCreateParameters)

Either<AnError, ServiceDeskComment> createPublicComment(@NonnullApplicationUser user, @NonnullValidatedPublicCommentParameters commentParameters);

#createServiceDeskComment(ApplicationUser, ServiceDeskCommentCreateParameters)

Either<AnError, ServiceDeskComment> createInternalComment(@NonnullApplicationUser user, @NonnullValidatedInternalCommentParameters commentParameters);

#createServiceDeskComment(ApplicationUser, ServiceDeskCommentCreateParameters)


<T> T inCustomerContext(Callable<T> callable);


voidinCustomerContext(Runnable runnable);


<T> T outOfCustomerContext(Callable<T> callable);


void outOfCustomerContext(Runnable runnable);



String getLicenseType();

This method is not applicable anymore. It will always be ABP


Either<AnError, CustomerRequest> getRequestForKey(@NullableApplicationUser user, @NonnullString issueKey);

#getCustomerRequests(ApplicationUser, CustomerRequestQuery)

Either<AnError, CustomerRequest> getRequestForIssue(@NullableApplicationUser user, @NonnullIssue issue);

#getCustomerRequests(ApplicationUser, CustomerRequestQuery)

RequestTypeUpdateParameters.Builder requestTypeUpdateParametersBuilder();


Either<AnError, CustomerRequest> updateRequestType(@NullableApplicationUser user, RequestTypeUpdateParameters requestTypeUpdateParameters);

#updateCustomerRequest(ApplicationUser, CustomerRequestUpdateParameters)

Either<AnError, CustomerRequest> getRequestForIssueOverrideSecurity(Issue issue);

#getCustomerRequests(ApplicationUser, CustomerRequestQuery)

Either<AnError, CustomerRequest> getRequestForKeyOverrideSecurity(String issueKey);

#getCustomerRequests(ApplicationUser, CustomerRequestQuery)


RequestTypeGroup withOrder(Option<Integer> order);

This deprecated and Experimental API has been removed.


Either<AnError, List<RequestType>> getRequestTypes(@NonnullApplicationUser user, @NonnullRequestTypeQueryParameters requestTypeQueryParameters);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

RequestTypeQueryParameters.Builder queryBuilder();


Either<AnError, RequestType> getRequestTypeForRequest(@NonnullApplicationUser user, @NonnullCustomerRequest customerRequest);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, RequestType> getRequestTypeForIssue(@NonnullApplicationUser user, @NonnullIssue issue);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, List<RequestType>> getAllRequestTypes(ApplicationUser user);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, RequestType> getRequestTypeForRequestOverrideSecurity(@NonnullCustomerRequest customerRequest);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, RequestType> getRequestTypeForIssueOverrideSecurity(@NonnullIssue issue);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, RequestType> createRequestType(longprojectId, intissueTypeId, String name, String description, longiconId, List<Integer> groupIds);

#createRequestType(ApplicationUser, RequestTypeCreateParameters)

Either<AnError, List<RequestType>> getRequestTypesForGroup(Integer groupId, Long projectId);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, List<RequestType>> getRequestTypesByGroup(Integer groupId, Integer serviceDeskId);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, RequestType> getRequestTypeByIdAndProjectId(Integer requestTypeId, Long projectId);

#getRequestTypes(ApplicationUser, RequestTypeQuery)

Either<AnError, RequestType> deleteRequestTypeByIdAndProjectId(Integer requestTypeId, Long projectId);

#deleteRequestType(ApplicationUser, RequestTypeDeleteParameters)

Either<AnError, RequestType> updateRequestTypeByIdAndProjectId(Integer requestTypeId, Long projectId, RequestType requestType);

#updateRequestType(ApplicationUser, RequestTypeUpdateParameters)


Callable<Unit> runnableToCallable(Runnable runnable) This deprecated and Experimental API has been removed.



Was this page helpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport