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.

Summary

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.

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. 

 Classname - com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

Method signatures:

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

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

1
2
FieldConfig getFieldConfigForDefaultMapping(
  FieldConfigScheme fieldConfigScheme
);

1
2
void delete(
  FieldConfigScheme fieldConfigScheme
);

1
2
FieldConfigScheme getScheme(
  Project project
);

1
2
FieldConfigScheme getScheme(
  Long id
);

1
2
List<FieldConfigScheme> getAllSchemes();

1
2
boolean isDefaultScheme(
  FieldConfigScheme fieldConfigScheme
);

1
2
FieldConfigScheme getDefaultScheme();

1
2
String getDefaultOption(
  IssueContext issueContext
);

1
2
String getDefaultOption(
	FieldConfig fieldConfig
);

1
2
void setDefaultOption(
  FieldConfig fieldConfig,
  String optionId
);

1
2
List<String> getOptions(
  IssueContext issueContext
);

1
2
List<String> getOptions(
  FieldConfig fieldConfig
);

1
2
void setOptions(
  FieldConfig fieldConfig,
  List<String> optionIds
);

1
2
void addOptionToDefault(
  String optionId
);

1
2
void removeOptionFromAllSchemes(
  String optionId
);

1
2
Collection<FieldConfigScheme> getAllRelatedSchemes(
  String optionId
);

1
2
void assignProject(
  @Nonnull FieldConfigScheme priorityFieldConfig,
  @Nonnull Project project
);

1
2
Set<Project> getProjectsWithScheme(
  @Nonnull FieldConfigScheme fieldConfigScheme
);

1
2
void unassignProject(
  @Nonnull FieldConfigScheme scheme,
  @Nonnull Project project
);

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

Classname - com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

1
2
com
  .atlassian
  .jira
  .event
  .issue
  .fields
  .config
  .manager
  .PrioritySchemeCreatedEvent

1
2
com
  .atlassian
  .jira
  .event
  .issue
  .fields
  .config
  .manager
  .PrioritySchemeDeletedEvent

1
2
com
  .atlassian
  .jira
  .event
  .issue
  .fields
  .config
  .manager
  .PrioritySchemeUpdatedEvent

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 

What's deprecated?

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

com.atlassian.jira.config.PriorityManager

Method signatures:

• setDefaultPriority
  Replacement: 

  com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager 

  #setDefaultOption(FieldConfig, String)

  Javadoc

• getDefaultPriority
  Replacement: 

  com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

  #getDefaultOption(IssueContext)

  Javadoc

com.atlassian.jira.config.ConstantsManager

Method signatures:

• getDefaultPriority
  Replacement: 

  com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

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

  com.atlassian.jira.issue.fields.config.manager.PrioritySchemeManager

  #getDefaultOption(com.atlassian.jira.issue.fields.config.FieldConfig)

  Javadoc

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. 

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.