JIRA 3.2 Upgrade Guide

This page contains information you need to know when upgrading to JIRA 3.2. The general upgrade instructions can be found here.

  1. If you have written any Custom Field Type plugins please refer to this document
  2. If you have created any Workflow plugins (custom Validators or Post Functions) please read this document.
  3. If you have any custom file based workflows (workflows not created through JIRA's Workflow Editor) please read this document.
  4. If you wish issues that are associated with the default system workflow and are closed to be bulk editable - please read this.

Notifications now respect permissions

In 3.2, JIRA respects the permission scheme and security levels when sending notifications (see JRA-5743. People who won't be able to see an update online won't get a notification email.

This has one important effect: if you have a project where:

  • the notification scheme specifies that a raw email address (eg. developers@mycompany.com) should be notified, and
  • 'Browse' permission has not been granted to 'Anyone' (eg. it is granted to 'jira-users'
    then that email address ('developers@mycompany.com' in our example) won't be mailed. As JIRA cannot verify that the recipient(s) of the email address have the 'browse' permission, it makes the conservative assumption that they are not.

This can be fixed by creating a user (eg. 'developers') for the email address, making it a member of a group that has 'Browse' permission, and adding it as a recipient of notifications. The raw email address should then be removed from the notification scheme, as it serves no purpose.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport