Rate this page:
5 December 2016
Atlassian is proud to present JIRA Software 7.3 RC02. This public development release is part of our Early Access Program (EAP) leading up to the official JIRA Software 7.3 release. We are making these EAP and Release Candidate milestones publicly available so that developers can start assessing the impact of the changes that we are making.
For the full list of changes for JIRA 7.3, read the developer change management guide: Preparing for JIRA 7.3. If you are new to JIRA, you should also read our Java API Policy for JIRA and the Atlassian REST API policy.
Before you install/upgrade: Atlassian does not support upgrades both 'from' and 'to' EAP releases. EAP releases should not be used in production environments as they are not officially supported. For all production use and testing of JIRA, please use the latest official release instead.
We want your feedback!
To provide feedback, create an issue in our issue tracker with the following details:
We released rich text editing as an opt-in labs feature in JIRA Software 7.2, and now we're pleased to announce that rich text editing has graduated to the default editing experience in JIRA Software. This means when you upgrade or install JIRA Software 7.3, the rich text editor will be turned on by default. This gives your users the option to either use Visual mode (what you see is what you get) or Text mode (wiki markdown). We've retained the ability for administrators to disable rich text editing if they wish, this will disable it for the entire instance, and all your users.
To disable the rich text editor, select > System, and select Rich text editor from the sidebar.
We've added API's for the rich text editor, and our developers have written some tutorials on how you can create an add-on to work with the rich text editor, from basic use cases to more advanced use cases. Check out the tutorials to get yourself up to speed.
We've extended the project administrators permission, so that project administrators can now edit their projects workflow under certain conditions:
The project admins will not be able to edit the workflow to the same extent as a JIRA administrator. The restrictions are:
This feature is enabled by default. When you upgrade to JIRA Core 7.3, all your project administrators will have access to this feature immediately. To edit a workflow, a project administrator should select Project settings in their project's sidebar, and select an issue type. This will present the workflow, and Edit will be available.
We've added two features that relate to starting JIRA:
Now when you install or upgrade a JIRA instance, you need to actively select to start JIRA. Previously, once JIRA ran the installation/upgrade, it would start JIRA automatically, before asking you if you'd like to launch JIRA in a browser. Now, there's an additional step where JIRA will ask if you want to start JIRA, and if you choose to start it, it will ask if you want to launch JIRA in a browser, This change was required to allow us to work with Amazon Web Services (AWS) to provide a Quick Start guide using CloudFormation templates to allow you to deploy JIRA Software Data Center in an AWS environment.
We've added a feature that allows you to start a JIRA instance with all user installed and custom add-ons disabled, or with a specified list of these add-ons disabled:
(or for Windows users)
or ( for Windows users)
This feature is designed to help with upgrades and installation issues whereby an add-on failing during JIRA startup stops your JIRA instance from starting. You'll be able to disable the add-ons, start JIRA and manually remove the add-on through the add-on manager. The parameters are designed to be specified at system startup when JIRA is started using the start-jira.sh script (or start-jira.bat for Windows), for example:
./bin/start-jira.sh --disable-all-addons --disable-addons=com.atlassian.test.plugin
If a customer does not use start-jira.sh for starting JIRA but still wishes to use this feature, they can use these features by adding the following JVM parameter to the invocation of the servlet container that's running JIRA:
To disable multiple plugins, use a colon separated list of plugins. Regex/wildcards are not permitted, the full key of the plugin must be provided, for example:
-Datlassian.plugins.startup.options= "--disable-all-addons --disable-addons=com.atlassian.test.plugin:com.atlassian.another.test.plugin"
The parameters do not persist i.e. when you shut JIRA down and start it up again, the parameters are removed and JIRA will attempt to start all your add-ons as per a normal start up.
Around October 2016 we launched an add-on that would allow our JIRA Software Data Center offering to support SAML single sign-on. We've worked hard to bundle this with JIRA Software so that it works out of the box. From JIRA Software 7.3 you can now link your instance to your existing supported Identity Provider (IdP) and provide your users with a single sign-on experience. This reduces the number of passwords a user needs to remember, and provides extra security for your instance.
We're pleased to announce that we've implemented a zero downtime "upgrade mode" in JIRA Software Data Center, which allows you to run your nodes in a clustered environment when they are on different versions of JIRA Software. This allows you to upgrade the JIRA instance on one node, while your other node/s provides uninterrupted service to your users. Once you have upgraded your node and started JIRA Software, it will be added back to the cluster and immediately be available to users. You can then proceed in upgrading your other node/s. To check out the process, select > Applications, and select JIRA upgrades from the sidebar.
Note that this feature is NOT compatible with a JIRA Service Desk Data Center AWS deployment. AWS provides different functionality to upgrade your nodes.
All of the changes in the JIRA Core 7.3 RC01 are also in the JIRA Software RC01 unless otherwise stated below. Read the JIRA Core 7.3 release candidate (RC02) release notes for details.
We don't support upgrading to or from EAP releases, and you should never use an EAP release in production. If you do intend to upgrade an instance to an EAP release, you should review all applicable upgrades notes for the production releases, and upgrade in the specified order:
Rate this page: