Documentation for JIRA 6.3 EAP developer (EAP) releases only. Not using this? See below:
(JIRA 6.2.x documentation | JIRA OnDemand documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

26 August 2011

JIRA 5.0 EAP 3 (a.k.a 5.0 milestone 3 or 'm3') is a public development release leading up to JIRA 5.0. An Early Access Preview (EAP) release is a snapshot of our work in progress, primarily focused on allowing JIRA users to see the new features in advance and provide us with some useful feedback. It also gives plugin developers an opportunity to test and fix their plugins in advance of an official release. For all production use and testing of JIRA, please use the latest official release.

While development work on JIRA 5.0 commenced relatively recently, we want your involvement from the earliest days. Please provide feedback here.

A lot of the features in JIRA 5.0 focus on making JIRA easier to use and manage. With JIRA 5.0, administrators can manage shared filters and dashboards that were created by other people and issues can be copied between different JIRA sites.

There are a large number of improvements for the JIRA developer community (and more to come in future EAPs). In JIRA 5.0 EAP 3, new REST APIs have been added to create issues, a stable JIRA API is undergoing refinement and every block area on the 'View Issue' page is now a Web Panel.

Highlights of JIRA 5.0 EAP 3:

Thank you for your interest in JIRA 5.0 EAP 3
Download EAP

Upgrading to JIRA 5.0 EAP 3

Icon

JIRA EAP releases are available here. When upgrading, please follow the JIRA 5.0 Upgrade Notes.

Do not use in production

Icon
  • EAP releases are not safe — EAP releases are snapshots of the ongoing JIRA development process. As such:
    • While we try to keep these releases stable, they have not undergone the same degree of testing as a full release.
    • Features in development releases may be incomplete, or may change or be removed before the next full release.
  • No upgrade path — Because EAP releases represent work in progress, we can not provide a supported upgrade path between EAP releases, or from any EAP to the eventual final release. Thus, any data you store in a JIRA EAP release may not be able to be migrated to a future JIRA release.

Highlights of JIRA 5.0 EAP 3

 

Manage Other Users' Shared Dashboards (new since EAP 2)

JIRA administrators have the ability to manage other people's shared dashboards. This is especially helpful in situations where a user has left an organisation, but the shared dashboards they owned continue to be used by others within the organisation.

You can access this feature by selecting 'Administration' > 'Users' > 'Shared Dashboards' (or using the keyboard shortcut 'g' + 'g' + start typing 'shared dashboards'). On the 'Shared Dashboards' page, you can search for any shared dashboards, or use the cog icon to change the owner of a dashboard to another user or delete a dashboard:

^Top

 

Manage Other Users' Shared Filters

JIRA also gives administrators the ability to manage other people's shared filters. Like Shared Dashboards (above), this is also useful in situations where a user has left an organisation, but the shared filters they owned continue to be used by others within the organisation.

You can access this feature by selecting 'Administration' > 'Users' > 'Shared Filters' (or using the keyboard shortcut 'g' + 'g' + start typing 'shared filters').

On the 'Shared Filters' page, you can search for any shared filter, or use the cog icon to change the owner of a filter to another user or delete a filter:

^Top

 

Activity Stream API (new since EAP 2)

We are expanding the Activity Stream features introduced in JIRA 4.4 with a new Activity Stream API in JIRA 5.0 that makes it easy for any application to post activities into JIRA's activity streams.

Refer to the Plugin Developer Notes for JIRA 5.0 for more details.

^Top

 

REST API Improvements (improved since EAP 2)

JIRA's REST API is undergoing a significant number of changes and improvements to provide the following:

  • Create new issues.
  • Retrieve metadata for creating new issues.
  • Retrieve metadata for editing existing issues.
  • Delete existing issues and their subtasks.
  • Create remote issue links.

(info) Please also note that the we have changed the api-version name component of URLs for JIRA's REST API calls from '2.0.alpha1' to simply '2'.

Refer to the Plugin Developer Notes for JIRA 5.0 for more details.

^Top

 

Java API Improvements

JIRA's Java API is undergoing a significant number of changes and improvements to provide the following:

  • More stability and reliability with future versions of JIRA.
  • Removal of deprecated OSUser classes.
  • Removal of deprecated portlets (replaced by gadgets in JIRA 4.0) and their related APIs.

Please see the Plugin Developer Notes for JIRA 5.0 for more details.

(info) Please also be aware that the JIRA's Java API is likely to undergo a rapid number of changes from one JIRA 5.0 EAP release to the next.

^Top

 

Performance Improvements (improved since EAP 2)

Lucene 3.2 is now fully integrated into JIRA. Initial benchmarking shows performance improvements across a number of JIRA features.

The 'Activity' tabs on the 'View Issue' page are now loaded in the background when this page is first viewed, allowing the information on these tabs to be displayed more rapidly.

^Top

 

New Plugin to Try Out — Remote Issue Copying

This new JIRA 5.0-compatible feature, currently undergoing development as a plugin, allows you to copy issues from one JIRA site to another.

Once you have an Application Link established between your JIRA site and another, a new issue action 'Remote Copy' will appear in the view issue page. You can limit this action to a particular user group, but by default everyone can use it.

You will be prompted to map field values by field names for JIRA's built-in (system) fields and/or to configure default values for required fields.
(info) You will require the appropriate permissions to set the field value on the target site.

Custom fields are generally supported, although so far, we have only provided a mapper for the SelectCFType custom field type. Supporting more custom fields is a matter of writing more mappers (which we intend to make pluggable for the final JIRA 5.0 release).

The Remote Issue Copy feature is currently available as a plugin that needs to be installed on each JIRA server you wish to copy issues between. You also need to configure the following before you can copy issues between your JIRA sites:

  1. An Application Link from the source JIRA site to the target JIRA site — see Adding an Application Link.
  2. A Project Link from the source JIRA Project to the target JIRA Project — Adding Project Links between Applications.

(warning) The Remote Issue Copying plugin is not yet bundled with JIRA. However, you can download it from from the following link:

^Top

Other Enhancements and Fixes

For a list of more issues resolved in JIRA 5.0 so far, click here.

^Top

  • No labels

6 Comments

  1. Does the Remote Copy delete the original issue? I'd guess that's a separate step.
    Is there a Bulk Remote Copy operation?

    1. For now it's single issue copy (not move), so it retains the original issue (does not delete), and there is not a bulk copy operation in this version.

  2. Bulk (filtered) and Scheduled?

    1. If you're asking about whether remote copy is possible to do in a bulk manner while applying a filter, and can be scheduled - right now the plugin does a single issue copy.  We've certainly thought about the use case of bulk move from one server to another - but again, this focuses on creating a solid technical prototype for server-to-server copying of JIRA issues.  The plugin will go through a lot of UX work and changes in the future.

  3. Will the Remote Copy feature be designed so that users of JIRA Studio can copy images from Studio to a locally-hosted instance when moving from the hosted to local model?  What about the other direction?

    This would be great because the current process requires getting technical support, and coordinating a schedule several days (or even weeks) in advance.  We actually finished this migration recently.  But something like this would have come in handy.

    1. Good question.  Remote Copy is designed for copying issues versus an entire JIRA instance or JIRA project configuration.  Taking the existing JIRA Studio importer/exporter that technical support uses and turning it into something customer facing is a separate effort.