30 October 2017
Atlassian is proud to present JIRA Core 7.6 EAP Release Candidate. This public development release is part of our Early Access Program (EAP) leading up to the official JIRA Core 7.6 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.6, read the developer change management guide: Preparing for JIRA 7.6. If you are new to JIRA, you should also read our Java API Policy for JIRA and the Atlassian REST API policy.
No two projects are the same, and no two teams tackle a problem in the same way. With that in mind, we've introduced a new approach to priorities to accommodate the diversity of teams working with JIRA. Now, you can choose different sets of priorities for each of your projects by using priority schemes.
A priority scheme works like a mapping that lets you associate a subset of priorities with particular projects. You can use it to achieve the following goals:
A single priority scheme can be used across multiple projects so that a group of similar projects can share the same priorities. It's also easier to add or remove priorities for these projects because all you need to modify is a single priority scheme. Whether you want two schemes with ten priorities each, or ten schemes with a smaller number of priorities--we'll leave that one for you to decide.
To create priority schemes, or to associate them with your projects, go to > Issues, and choose Priority schemes. You need to be a JIRA administrator to get there. The page where priority schemes live looks similar to the one below.
Project priorities are in the final stage, and that's exactly how they're going to look like when we release them with JIRA 7.6.
Because of differences between JIRA Service Desk and JIRA platform, we couldn't introduce priority schemes for JSD projects in this release. These projects will use the default priority scheme, which works like a global list of priorities--you can still add and remove priorities, like in earlier versions, but you can't restrict them to specific projects. If you're using both JIRA Core and JIRA Service Desk, you can manage priority schemes only for Core projects; the JSD ones will be hidden on the Priority schemes page.
Until now, the only way to order your subtasks was to move them up and down by using arrows. We're perfectly aware how difficult that was, so we've introduced a small improvement that allows you to drag your subtasks and drop them anywhere on the list. Regardless of whether you usually create 3 or 33 subtasks under your stories, it'll be easier now to reorder them.
JMX (Java Management Extensions API) monitoring brings live monitoring of your JIRA instance, including such metrics as the number of issues, all active users, and many others. JMX uses objects called MBeans (Managed Beans) to expose data and resources from your application. It might be useful to determine what causes performance issues, and where JIRA is struggling with a lot of data. We've introduced several metrics, but they're not collected by default. First, you'll need to enable JMX monitoring in JIRA, and then connect to it over JConsole.
To enable and use JMX monitoring:
Connect to JIRA over JConsole.
To monitor locally:
See Using JConsole for more information on local monitoring.
To monitor remotely:
Add the following properties to your / file. The port can be any port that is not in use.
set CATALINA_OPTS=-Dcom.sun.management.jmxremote %CATALINA_OPTS% set CATALINA_OPTS=-Dcom.sun.management.jmxremote.port=8099 %CATALINA_OPTS%
Decide how you will secure your remote connection. See Remote Monitoring and Management for more information.
Although it is possible to disable authentication, we do not recommend doing this on a production system.
See Using JConsole for more information on remote monitoring.
After connecting to JIRA over JConsole, you'll find all of the following metrics in the property.
|dashboard.view.count||The number of times all dashboards were viewed by users.|
|entity.attachments.total||The number of attachments.|
|entity.components.total||The number of components.|
|entity.customfields.total||The number of custom fields.|
|entity.filters.total||The number of filters.|
|entity.groups.total||The number of user groups.|
|entity.issues.total||The number of issues.|
|entity.users.total||The number of users.|
|entity.versions.total||The number of versions created.|
|issue.assigned.count||The number of times issues were assigned or reassigned to users (counts each action).|
|issue.created.count||The number of issues that you created after installing this JIRA instance.|
|issue.link.count||The total number of issue links.|
|issue.search.count||The number of times you searched for issues.|
|issue.updated.count||The number of times you updated issues (each update after adding or changing some information).|
|issue.worklogged.count||The number of times you logged work on issues.|
|jira.license||The types of licenses you have, the number of active users, and the maximum number of users available for each license type.|
|web.requests||The number of requests (invocation.count), and the total response time (total.elapsed.time).|