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

10 August 2011

JIRA 5.0 EAP 2 (a.k.a 5.0 milestone 2 or 'm2') 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.

(info) Please note that JIRA 5.0 EAP 1 was not released to the public.

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 filters that were created by other people.

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

Highlights of JIRA 5.0 EAP 2:

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

Upgrading to JIRA 5.0 EAP 2

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 2

 

Manage Other Users' Shared Filters

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

As the first step toward this, EAP 2 provides the ability for JIRA administrators to search for any shared filters:

^Top

 

JIRA 5.0 API Improvements

For plugin developers, JIRA's API is undergoing a significant number of changes and improvements to provide the following:

  • More stability and reliability with future versions of JIRA.
  • A more functional REST API with the ability to create new issues in JIRA 5.0 EAP 2.
  • 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 JIRA's API is likely to undergo a rapid number of changes from one JIRA 5.0 EAP release to the next.

^Top

 

Performance Improvements

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

^Top

Other Enhancements and Fixes

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

^Top

  • No labels

7 Comments

  1. It's great to see the shared filters functionality arriving in Jira. However, I'm wondering if it can be taken a step further?

    At the moment it appears only administrators can can manage the shared filters.

    In our case, we have many teams who'd like to allow members of their team to manage shared filters, not just administrators.

    The functionality that would be required here is the ability to designate multiple users and/or groups as having ownership of a filter.

    If you want to be really really useful about it, you would allow filters to be versioned, so one user could roll back a change to filter if another user inadvertently modified it with detrimental results.

    To complement this you could also have a filter audit log to show the changes to the filter over time.

    1. Thanks, David - great feedback.  With this feature for controlling ownership of filters, we're pushing to get something out there and see how broadly it's used.  While it's been a key feature request, the focus of the requests have been around the use case of administration controls - i.e. when one employee leaves and you want someone else to own their filters, there was no way to transfer ownership (sounds like you may already be familiar with that use case).

      We have designed the approach to ownership across multiple users - we agree that's the next natural step for this feature, but haven't slated it for a specific release.  

      1. Hi, Bryan.

        First, i am very glad to see this improvement.

        While, in our company, there must have a JIRA administrator in one team.  And, most of them are part-time job. But they indicate this job is so pettiness, and , at last most of team cannot use JIRA smoothly. 

        You can say, it is because all of the administrators job by couple of versions, many of schemes, maintenance of users/groups/roles, etc. It's horrible.

        So, i mean, can user themselves to accomplish this dashboard/filter's transfer job? And, certainly, if the people when one employee leaves forgot it. let admin do it.

  2. I really do appreciate this approach!

    (...)the focus of the requests have been around the use case of administration controls - i.e. when one employee leaves and you want someone else to own their filters (...)

    After some former employees have left our company we do have many orphaned shared filters and dashboards. Currently we have no other possibility to either accept those leftovers and create new duplicate entities, or to login in the former employees account and delete the filters/dashboards.

    As the first step toward this, EAP 2 provides the ability for JIRA administrators to search for any shared filters

    So if I am right search is just the first usecase and will be expanded to other usecases like edit, delete and maybe others? Great! While I am currently looking forward to upgrade to JIRA 4.4., you keep me (once again) curious for the latest version. Keep on the great work!

    1. Search is just the way the admin finds the shared filter to administer.  Currently the admin can delete and change the owner of shared filters.  There are permission checks done to ensure that any potential new owner can see the shared filter (or dashboard) according to it sharing rules. 

      Interestingly we are going to ship this feature in JIRA 4.4.1.  So you may not need to wait as long as you think :)  I am glad to see we are keeping you curious.

      paul

  3. Anonymous

    We have been searching JIRA to try to find out if there was the functionality planned in a future release to add the ability to designate multiple users and/or groups as having ownership of a filter. (just like David above).  What we have to do here at Expedia, is to have people help to put together filters and subsequently dashboards and then we have to ask our internal JIRA support team to change the ownership to another person to continue the maintenance of their dashboards.  If there is ever a need for a lot of dashboard re-design, the admins then have to re-assign it back to another person, do the re-design, and then assign back to the ultimate end user.  This re-assignment is a pain and takes time to complete as our JIRA admin queue is quite large.  One way our users are able to circumvent this is they give out their login/passwords to others for JIRA help and this is not a best practice behavior  It would be beneficial and help Expedia to be able to utilize JIRA more effectively if we could give edit capabilities of dashboards and filters to more than one person.  it makes sense as many tools do this.  In Outlook you can provide read access to others as well as edit access.  You can do the same in SharePoint, etc.  Seems logical that this tool should have this feature too.

    Please let me know if this is handled in a release and apologies, but i could not find it anywhere.

    1. Anonymous from Expedia - 

      Thanks for the feedback:

      There are existing feature requests for similar features on our public issue tracking system:

      JRA-20234 - A new sharing permission for "editing" filters and dashboards should be created Resolved

      JRA-17783 - Allow shared filters and dashboards to be edited by a group Open

      So I would recommend watching those issues for updates (and commenting if you like).  We don't have a target release for those features at this point, but your use case definitely makes sense to us.