We couldn't load all Actvitity tabs. Refresh the page to try again.
If the problem persists, contact your Jira admin.
IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      One thing that is currently causing us problems is the "one size fits all" Notification Scheme's that are in JIRA. Although you can define varying scheme's per project, and using watches people can decide if they want to be notified about a certain issue ... People here want to be able to do similar but at a higher level - be the execption to the scheme's rule.

      For example:

      I set groupA to be notified whenever an issue is created in projectA. This is fine, however [without admin intervention (adding them to groupA or singularly), but with "overriding approval" (eg: 'tick here to allow users to override notifications on this project')] I would like to be able to have a user decide him/herself if they get the notifications for issue creation.

      The same applies to all the various issue notification options (eg: issue closing, assigning, work logging etc).

      This idea is extensible and leads to create a scalable (overridable) notification scheme which is managed by the end users (if the option is enabled) rather than needing and administration team to get involved in notifications when they should be focused on security and auditing.

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.

              • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

                NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

                One thing that is currently causing us problems is the "one size fits all" Notification Scheme's that are in JIRA. Although you can define varying scheme's per project, and using watches people can decide if they want to be notified about a certain issue ... People here want to be able to do similar but at a higher level - be the execption to the scheme's rule.

                For example:

                I set groupA to be notified whenever an issue is created in projectA. This is fine, however [without admin intervention (adding them to groupA or singularly), but with "overriding approval" (eg: 'tick here to allow users to override notifications on this project')] I would like to be able to have a user decide him/herself if they get the notifications for issue creation.

                The same applies to all the various issue notification options (eg: issue closing, assigning, work logging etc).

                This idea is extensible and leads to create a scalable (overridable) notification scheme which is managed by the end users (if the option is enabled) rather than needing and administration team to get involved in notifications when they should be focused on security and auditing.

                        Unassigned Unassigned
                        dhardiker Dan Hardiker
                        Votes:
                        112 Vote for this issue
                        Watchers:
                        80 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            Unassigned Unassigned
                            dhardiker Dan Hardiker
                            Votes:
                            112 Vote for this issue
                            Watchers:
                            80 Start watching this issue

                              Created:
                              Updated:
                              Resolved: