Issue Details (XML | Word | Printable)

Key: JRA-3791
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: joe dane
Votes: 41
Watchers: 19
Operations

If you were logged in you would be able to see more operations.
JIRA

notification scripting

Created: 19/May/04 09:05 PM   Updated: 19/Sep/08 11:32 AM
Component/s: Email integration, Events / Listeners
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Duplicate
 
Part
 
Reference

Participants: Adrian Bridgett, Jeff Turner [Atlassian], Jeremy, joe dane, Jordan Dea-Mattson, Mika Mannermaa and Peter Burkholder
Since last comment: 3 weeks, 2 days ago
Labels:


 Description  « Hide
the notification scheme stuff is very cool, but could be better.

on several occasions now, I've wanted something where a notification would be sent in certain situations, but I'm unable to express the situations using a scheme. in particular, although I can trigger a notification on issue create, I can't say "trigger on issue create, if the issue is in component X, and was not created by user Y".

it's hard to see a simple way of enabling this from the GUI.

here's one possibility. allow the list of notification triggers to be edited. instead of having a single "issue created" trigger, with some number of notifications attached to it, allow any number of "issue created" triggers. each trigger could have an optional attribute, which is a boolean valued expression in some simple language. the notifications for the trigger would fire if the expression evaluated to true in the context of the issue in question.

so, for example, you could have some number of primitive operators:

component C <-- true if the current issue is in component C
reporter R <-- etc.
beforetime T <-- true if the issue was created before time T

and some boolean connectives, and you're done. when an issue is created, JIRA looks for all "issue created" triggers, executes their condition expressions in the context of the current issue, and fires the notifications if the condition is true. or better, the "issue created" trigger type could just be incorportated into the expression.

there are probably other places in JIRA that could use this sort of thing. listeners, for example, could be configured to fire only for a certain project.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Jeremy added a comment - 03/Feb/05 02:24 AM
I agree - I think the issue created notification is just too generic.

I tried to create a similar workaround by:

(1) Creating JIRA users just for group notifications (and use a distribution list as their e-mail address), such as billing-notifications, operations-notifications, etc for different departments.

(2) I added each of those users to just one Issue Security Level (such as "billing", "operations", etc).

(3) But when users enter new issues and assign that issue to one of the security levels above, the notification goes out to all my custom users even though only one has Issue Security Level permission to view the issue.

Hope that makes sense, but it was an ugly hack that still didn't work - your recommendation would be outstanding! I see a lot of other open notification issues that have not been responded to, so evidently, notifications aren't very high on the priority list yet.


Jeff Turner [Atlassian] added a comment - 10/Feb/05 01:47 AM
Notifications in general do not respect permissions. This bug is being tracked in JRA-5743.

At the moment, I think the only workaround within JIRA is to write one's own workflow post-function on the 'create issue' transition. For instance, Vincent Massol did this here:

http://blogs.codehaus.org/people/vmassol/archives/000842_writing_a_jira_3_plugin.html


Mika Mannermaa added a comment - 17/Oct/05 07:33 AM
A small but critical change to generic notifications system would be the ability to filter that only issues which are greater or equal in severity are send. Of course it is easy to see, that other operators like equal, not equal and lesser than can be added as well. This would help especially in cases where only critical issues should generate email to a specific address for futher processing, but of course an interim solution is to make custom notification java class.

Adrian Bridgett added a comment - 19/Jun/08 07:59 AM
Another vote - same reasons as Mika - in particular we'd like high importance issues to trigger external alerts. Currently we would have to filter externally.

Peter Burkholder added a comment - 12/Aug/08 04:28 PM
This has been request by my customers as well - esp. component-based notification. (JA-282)

Jordan Dea-Mattson added a comment - 19/Sep/08 11:02 AM - edited
The ability to tailor notifications so that folks see just what they need to see, no more and no less, is critical. Right now, I am fighting a constant feast or famine battle with the "JIRA Flood" (or jiralood if you want JIRAlang) with our team.

If we dial things up, folks start getting flooded with emails. If we dial it back, issues start getting missed.

This issue has been around for over 4 years. The last Atlassian comment on it was over three years ago. What does it take for this one to get attention?

The recent functionality in 3.13 was a breath of fresh air. Really delivering critical functionality. But there are more issues which need to be addressed. Please look for them and get them on the road map. It would be great if you started laying out roadmaps for the next 24 months or so (with the further out they get, the more fuzzy they get).