Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-14568

Profile option should let me specify to automatically Watch anything I Vote for, Edit, Report, or Comment on

    • Icon: Suggestion Suggestion
    • Resolution: Duplicate
    • None
    • None
    • 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.

      I would like it if we had an option in our profiles to specify that I automatically want to Watch any issue that I vote for, edit, report, or post a comment on.

      P.S. This form is confusing. I don't understand some of the questions. And why am I supposed to be making estimates and putting in labels and specifying how many developers will work on it?

            [JRASERVER-14568] Profile option should let me specify to automatically Watch anything I Vote for, Edit, Report, or Comment on

            Setting component to extensions since the features is available as a plugin in JIRA Toolkit

            Chris Mountford added a comment - Setting component to extensions since the features is available as a plugin in JIRA Toolkit

            I'm putting this same comment here and on JRA-14667, since I'm not sure where you want me to comment now.

            I think JRA-2644 may be opposite to mine.

            Though part of the confusion is the other issue is discussing pieces of the JIRA that I, as an end-user of secondlife's JIRA, never see or use (I submit bugs & watch them, but I'm not an employee of secondlife, developer, nor administrator of their JIRA).

            Bits of JRA-2644 sound like mine...but parts of it, or comments discussing the issue, seem to be in express contradiction to my issue.

            My issue is that an end user should have control over what issues are "auto-watched". It's an opt-in perspective. I'm trying to, by default get MORE notification. Once something is watched, by whatever means, exactly what the end user receives, what notifications, etc, I leave up to the JIRA administrators.

            JRA-2644 is about administrators imposing notifications on end-users, and perhaps allowing the end-users to maybe opt-out. Opt-out, vs my desire of opt-in.

            Commenter Neal Applebaum seems to think it's about people being able to watch, but NOT receive emails. That is not at all what I'm requesting, I'm just requesting that the end-user be able to opt-in to an auto-watch based on various criteria (voting, editing, reporting, commenting), and once they watch something, they get whatever emails the JIRA wants to send.

            I guess maybe my issue is a duplicate IF you guys implement JRA-2644's opt-out feature, AND the implementers of the secondlife JIRA are able to create some kind of policy (can they?) that says all participants auto-watch unless they opt-out?

            Just bear in mind, I'm talking about the end-user perspective. In the case of the secondlife JIRA, secondlife/Linden Labs would not be upset if I chose to not watch any of my issues (though I'm sure they prefer that I do). However, as an end-user, I DO care to watch certain issues, and I want the JIRA to make it easier for me to be able to choose to do that...by being able to opt-in to an auto-watch based on various criteria (voting, editing, reporting, commenting).

            So, if you feel you understand my issue fully...are you confident I'm a duplicate of JRA-2644, because I can't tell.

            Jason Kulas added a comment - I'm putting this same comment here and on JRA-14667 , since I'm not sure where you want me to comment now. I think JRA-2644 may be opposite to mine. Though part of the confusion is the other issue is discussing pieces of the JIRA that I, as an end-user of secondlife's JIRA, never see or use (I submit bugs & watch them, but I'm not an employee of secondlife, developer, nor administrator of their JIRA). Bits of JRA-2644 sound like mine...but parts of it, or comments discussing the issue, seem to be in express contradiction to my issue. My issue is that an end user should have control over what issues are "auto-watched". It's an opt-in perspective. I'm trying to, by default get MORE notification. Once something is watched, by whatever means, exactly what the end user receives, what notifications, etc, I leave up to the JIRA administrators. JRA-2644 is about administrators imposing notifications on end-users, and perhaps allowing the end-users to maybe opt-out. Opt-out, vs my desire of opt-in. Commenter Neal Applebaum seems to think it's about people being able to watch, but NOT receive emails. That is not at all what I'm requesting, I'm just requesting that the end-user be able to opt-in to an auto-watch based on various criteria (voting, editing, reporting, commenting), and once they watch something, they get whatever emails the JIRA wants to send. I guess maybe my issue is a duplicate IF you guys implement JRA-2644 's opt-out feature, AND the implementers of the secondlife JIRA are able to create some kind of policy (can they?) that says all participants auto-watch unless they opt-out? Just bear in mind, I'm talking about the end-user perspective. In the case of the secondlife JIRA, secondlife/Linden Labs would not be upset if I chose to not watch any of my issues (though I'm sure they prefer that I do). However, as an end-user, I DO care to watch certain issues, and I want the JIRA to make it easier for me to be able to choose to do that...by being able to opt-in to an auto-watch based on various criteria (voting, editing, reporting, commenting). So, if you feel you understand my issue fully...are you confident I'm a duplicate of JRA-2644 , because I can't tell.

            AntonA added a comment -

            Hi Jason,

            I believe this feature request is the same as JRA-5976 and therefore I will resolve this issue as a duplicate.

            Please vote for JRA-5976 and add yourself as a watcher to that issue.

            For more information on the way new feature and improvement requests are implemented please see:
            http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

            P.S. This form is confusing. I don't understand some of the questions. And why am I supposed to be making estimates and putting in labels and specifying how many developers will work on it?

            Neal is right. These fields are used internally and therefore you can leave them blank when you are filing a new issue here.

            Cheers,
            Anton

            AntonA added a comment - Hi Jason, I believe this feature request is the same as JRA-5976 and therefore I will resolve this issue as a duplicate. Please vote for JRA-5976 and add yourself as a watcher to that issue. For more information on the way new feature and improvement requests are implemented please see: http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements P.S. This form is confusing. I don't understand some of the questions. And why am I supposed to be making estimates and putting in labels and specifying how many developers will work on it? Neal is right. These fields are used internally and therefore you can leave them blank when you are filing a new issue here. Cheers, Anton

            Ironic, isn't it?

            Atlassian has chosen not to implement field level security, so you see the fields that are intended only for their internal developers.

            Neal Applebaum added a comment - Ironic, isn't it? Atlassian has chosen not to implement field level security, so you see the fields that are intended only for their internal developers.

              Unassigned Unassigned
              cc481a94694e Jason Kulas
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: