|
That does look very cool. Thanks for the suggestion.
Anton You know, after some thought, I decided I don't really like the idea that much. Here's why.
If I know that commenting an issue means all watchers, reporter, and current assignee will receive an email, then I can rely on JIRA to send out the emails for me. However, if I can't know for sure if the person will receive the email because of some personal preference setting, then I will tend to use a real e-mail instead of adding a comment to the issue, which defeats the purpose of one central repository for information about an issue. Email threads about issues outside of JIRA are counter-productive. I even thought that the above preference setting could be limited to 'watched' issues, but then the same argument applies. If I add someone as a watcher, I want them to get the e-mail. Obviously, there's nothing I can do if the recipient is discarding emails based on some rule, but at least I know it was delivered. So, I think the only way this could work is if the project has no notification scheme. This way, JIRA will only send out notifications based on user preferences for projects which have been set up without a pre-set scheme. Anyway that's my .02 CDN. I totally agree with Neal and I would like to emphasize the use case mentioned in the last paragraph: Users that do not go to Jira every day might miss new issues assigned to them. So either we force them to go to Jira every day (not practical) or they can activate notifications. And yes, users should not be able to step out of notifications scheme individually.
I think admin could change indyvidually notification schema to any users.
My project leader don't like do get emails about issues. And I have to tell him, sorry JIRA send email to every one i our project using same 'notification schema'. Sounds bad.... Paweł, your project leader can have Outlook (or probably any email client) send those notifications to the trash as a client side rule in processing emails.
Neal thank you for your response.
I said to my project leader the same  He said "it's only patch" I think it would be nice to have such a functionality but it's ease to "patch" it, so it's not to much important. Maybe the solution is to go forward with the ability for users to customize their email preferences as long as the JIRA administrator has given them that (new) permission.
I do see the point of having a notification scheme be the end all and that if you allowed specific users to override that, then the "contract" is being broken in a way. I would just say, how about having the flexibility to allow for both? Create a new permission that can be assigned out to groups, specific users ... etc. The permission would be: "can override notification schemes". Some folks just don't care if you logged work on a specific task - in fact the use case I have here is some users only want to be notified if there has been a change to the description and a comment added. Having the flexibility to override the notification scheme would prevent a Jira admin from creating many different groups and notification schemes.
I think this is just goodness all around and putting in with a permission lock would give everyone what they need. 2 cents - Marcus Paweł, if you're still watching. You can easily set up 2 groups (or even roles) that are basically the same except one is for notifications and one is for permissions. So the project will have permissions based on members of a group called 'Working on Project A' and notifications will be sent out based on 'Team for Project A that want notifications'.
Users want the ability to control their environment. Having users receive a flood of emails and feel they have little control over that makes it difficult for me to get them to buy into JIRA.
What I'd like to see implemented is the ability when adding a group or user for notification to set a notification type of always, opt-in or opt-out. Selecting always would give the current behaviour. Opt-in would add the notification to the user's list of notifications that may be subscribed to. Opt-out would do the same but would also subscribe users by default. This gives the administrator total control over notifications if they want it, or they can delegate that to the users via opt-in/opt-out notifications. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Notifications Customisable by End Users
See http://www.bug-track.com/main/bugtrackingfeatures.jsp
I think it would be a great addition to the one size fits all notification scheme JIRA currently allows.