2014 年 7 月 28 日から 2014 年 8 月 1 日
JIRA Agile 6.5
Enhanced reports now production-ready
Over the past few releases, we have progressively introduced enhanced reports via Labs. We're proud to announce that these reports have graduated from Labs in this upgrade, and are now production-ready. Read about the new reports below.
Enhanced reports will not work on Internet Explorer 8
The enhanced reports introduced in this upgrade will not work on Internet Explorer 8 (note, support for Internet Explorer 8 in Atlassian OnDemand ended on 1 March 2014).
In particular, please note that while the Release Burndown and Epic Burndown are new reports, the enhanced Control Chart replaces the existing Control Chart. If you use Internet Explorer 8 , you will not be able to use the Control Chart after this upgrade .
Release Burndown and Epic Burndown: More informative forecasts
We have redesigned forecasts in the release burndown and epic burndown reports. It's now easier to distinguish predicted sprints from completed sprints. A new dialog provides you with more information about the predicted work for your release or epic.
Assignees shown on boards in Plan mode
Boards now show the assignees for issues (Plan mode only), making it easier for you to understand the workload of each team member:
- For issues: the assignee's profile picture is shown on the card.
- For sprints: the sprint header displays the profile pictures for the assignees of all issues in the sprint. A handy tooltip for each picture shows a summary of the work assigned to the user.
- Control chart only shows Swimlanes configuration if your board uses JQL swimlanes — Swimlanes configuration is only valid if your board uses JQL swimlanes, so this change prevents users getting confused by incorrectly configuring the chart.
- Clicking a card automatically opens the issue detail view — Previously, clicking a card would select it, but not open the issue detail view. You can still select a card without opening the issue view by using cmd/shift-click.
- Data table in Release/Epic burndown now shows work completed before first sprint — If issues are completed before the first sprint, the data table will now show information about the issues.
JIRA Service Desk 2.0-OD-02
The menus have been streamlined in this version.
- The People tab is now the second menu from the left.
- We've added the Settings tab to group all the settings for your service desk together. The name and the introduction of a Customer Portal is now defined in the Portal settings section. The configuration of request types is managed in the Request types section.
- Look&Feel has been renamed to Theme and branding.
One place to access multiple Customer Portals
If you have multiple service desk projects running, your customers currently need to visit each Customer Portal by using different URLs. With this version of JIRA Service Desk, they only need to remember one URL and they can see the list of all the Customer Portals they have access to in one place.
The URL to the list of portals is: servicedesk/customer/portals
If an issue's status is Waiting for support, when you respond to customers, the status will automatically change from Waiting for support to Waiting for customer.
Note: Customers will receive separate notification emails when a comment auto-transitions an issue, that is one for the comment and one for the status change.
JIRA 管理者は SLA データの管理方法をさらに２つ選べるようになりました。
- Set whether project administrators can create new SLA metric names: When new SLA metric names are created for a service desk, they are stored as SLA custom fields in JIRA. You can set whether project administrators can create new metric names now. If the setting is disabled, they can only select from existing metric names.
- Clean up unused custom fields: You can find out if there are SLA custom fields that are not used by any SLA metrics and clean them up with one simple click.
We've built more help information into the user interface of JIRA Service Desk. When help is turned on, you can click See how and learn about the functionalities on a screen in more detail.
Control agent resources with dedicated agents
You now have much more control over your agents, so you can fine-tune your build performance requirements, and the costs associated with elastic agents. You can specify the activities a particular agent should perform, or that a particular job must run on a specific agent – for example, where the agent is configured for code signing, or has a particular license that must be available.
Clone existing deployment projects
You can now clone an existing deployment project. The new, cloned project:
- will use the same plan, branch and artifacts as the original project
- will contain copies of all the original environments and their settings
- will use a copy of the version naming scheme, starting at the same number as the cloned project.
Improved integration with Atlassian Stash
For those who use Atlassian Stash to manage Git repositories, or who want to, we've simplified and extended the integration with Stash. We now use repository events published by Stash (versions 3.1 and later) to trigger actions in Bamboo, with almost no need for configuration. You don't have to configure repository polling for new commits anymore, or set up dedicated web hooks in your Stash instance – simply create an application link between Bamboo and Stash to scale Git:
- Stash tells Bamboo when to build
- Stash tells Bamboo when to update plan branches, to match changes in repository branches
- Bamboo notifies Stash automatically about build results
- Deployments now appear in the activity streams for agents and builds.
- There is now greater stability and better performance of the build queue for those running Bamboo at large scale.
- You can now edit the name of a Bamboo project. When you do, all plans in the project are correctly updated with the new name.
There are no functional changes in this upgrade.