|
|
|
[
Permlink
| « Hide
]
Neal Applebaum - 29/Aug/05 01:17 PM
Looks like JRA-5959 and some others...
Neal - I see from the others that this is an issue from other clients since February. This is a pretty critical feature for us and we are 2 weeks into a trial about ready to buy. But this 1 feature is holding us back. Do you have an idea when it will be implemented?
It's not crucial for me. I usually just copy the link and/or description when I want to email someone about an issue. You could also add the user as a watcher, and then comment on it - e.g. "FYI" -, which would generate an email automatically with FYI as the comment. I'll wait for Atlassin to respond, but I do find it curious that this would be such a major issue for you... Most of my users complain they get too many emails
A lot of the issues we track affect more than one person, so when we have resolution, we'd like to be able to email out to either the supervisor or another group to let them know it's resolved and what was done.
Today I'm copying pasting...a lot. Doesn't make sense when an "Email to" button would be easy to do. Also FYI we do not allow our users access into Jira so hyperlinks won't do them any good. I agree with Kevin, this is also an important issue for my team. We would like to be able to send update emails to our external users, because they cannot access JIRA directly they are not direct users. But users who log issues with us non the less. So if the notification scheme could somehow incorporate adding email addresses of non JIRA users that would be much appreciated.
Abisola, I think you can achieve this, to some degree, according to the documentation
Single Email Address is any email address that you wish to alert. A Single Email Address notification will only be sent if the issue is publically viewable since you can not perform a security check on only any email address. Publically viewable issues are issues which have a Permission scheme that gives the 'Browse Projects' permission to 'Anyone'(any non-logged-in users). The Single Email Address feature would be ideal if it wasn't only Adminstrators that could edit the Add Notification page. My general support staff do not have Admin rights in JIRA, which would make it impossible for them to include any non-logged-in users.
Hence, unfortunately I cannot use this feature to add external email addresses as I have more than one external user and this address would have to be added on an issue by issue basis. If I could have a field such as the "Single Email Address" avaliable to all users when the issue is initially created, it would solve my problem. Likewise, it would be extremely beneficial if we had an operation that would allow an individual, or multiples, to be selected to receive the issue. I reviewed the comments above regarding the single email address, and would this need to be done for each issue? If so, this would be pain.
Using JIRA as both a trouble ticket, help desk, and project management system (which is VERY nice), having a notification rule that sent email to a custom field that was filled in as part of the issue (not by the admin, as in the send to single email rule). Our current system has this feature, and it is pretty standard for most I think. Please raise this in priority.
JIRA should have a custom email_addr field anyway, that is tested for RFC compliance, much like a date or numeric field. The name of the field would be something like 'issue_email_addr' and would simply be an additional radio button in the notification rules with no value. One would specify this field in the screen and field configurations. If the field was non-null (filled in by the issue creator/updater/...) then notification would be triggered. Even if email_addr was a simple text field, this would still work. Like Abisola notes, this allows support staff to record the email address of the caller without needing an account for the caller. The nice thing about this is that one can configure, with notification schemes/rules, just when this external email address gets notified and for what. BTW, changing notification rules on the fly for support staff is a no-no anyway. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||