|
This would also allow for a simple form of JIRA replication - where email notifications from one JIRA instance end up in a POP box, which triggers the creation of identical issues in another.
We do have the following scenario: one of our team is actually attaching a document to the issue once it is resolved. This document explains stuff related to the issue to end-users.
This team does not want the end user to actually access Jira but still register them to be able to notify. Problem currently is: the resolution of the issue does not send the "resolution document" as well. In our case, it would be great to be able to:
With some customization, the upcoming version 3.2 should be able to fullfil these requirements.
You will be able to create a custom screen for the transition and then with the use of a custom mail listener send the recipients an email with the attachment. Stay tuned. Hi Nick,
nice to hear that. As you are already improving the handling of attachments, are there any plans to include permissions per attachments (JRA-3893) in the next release as well? This is related to this issue insofar as the notifications for new attachments (and - if configured - the attachments themselves) should only be sent to the people who also have the permission to see them. Kind regards Axel,
We are busy trying to get the next release out soon and unfortunately JRA-3893 will not be part of this. There has been some work done towards field level security, though this will not be in 3.2 either but should be in a future release. Nick I would definitely like to see issue file attachments added to the notification e-mail.
Rgds, I agree w/ Axel's comments as to how we would like to use it as well. We really want the ability for an attachment to go out on the email notification.
Since 3.3 is out and there are no comments, should we assume that it didn't make 3.2??? Please note that some shops may not want attachments being automatically sent with the notification email. I would think that stating an attachment was made along with its name in the notification and directing the customer to go to the website to download it would be enough.
Allowing the developer to email a issue to a customer with the option of including the attachment(s) is desirable for closed shops such as ours that do not allow customers to enter/view jira issues. "I would think that stating an attachment was made along with its name in the notification and directing the customer to go to the website to download it would be enough."
I say this because many corporate mail servers have attachment size limitations. If you attach large files to issues like we do (memory dumps) then they will get dropped from the email and the customer will likely have to ask questions. Just my $0.02 ... do I get any change back? Kevin makes some good points. It's not going to be easy to satisfy everyone, even at a corporate level. For an issue with a screenshot, maybe it's OK, but what if the attachment is an enormous pdf or memory dump...
Sounds like the user might want to decide on the fly for each issue. How about this.. implement issue JRA-5959 with the option "Include Attachments?" When we implment this feature we will definitely not mail all attachments. We might allow to specify maximum attachment size for email and a setting whether to disable it completely (set max size to 0).
Just wondering the status of this task? Will it be implemented at all? Been a year now
Hi Jeff,
Could you give us a short update on this issue? Is there a way to do this ourselves? Anyone already done this? Pointers would be greatly appreciated, as our company has a great need for this feature KR, With 8 votes, and being an optional feature (most people wouldn't want/need it), this is fairly low in the list of things to implement. If anyone wants to have a shot at implementing it, it would require modifying source in com/atlassian/jira/mail/MailingListCompiler.java, and various other classes (eg. Email.java). See http://developer.atlassian.com/
It also presents a whole bunch of problems. For example, what if the recipient's email server or client bounces the message because the attachment is too large, or because of some other attachment related rule? They would miss getting the notification itself.
G'Day Neal and Jeff,
I totally understand Neals point, that would be a problem. Whenever this is implmented, this could be an option in the admin-panel so that users who know for sure that it wont be a problem, can still use it. Our immediate need is to just include the screenshots. We take photos/screenshots that we include in the issue, that our clients need to see. Neal, would this pose any problems if it only included images? (Of course if you include 20 images, but wont they be then sent separately if uploaded 1 at a time?) KR, For me, I would never include the option to include attachment contents in an email because our clients use JIRA to create issues with screenshots of confidential information. I have created a custom field so they can include any confidential information (e.g. names) that doesn't show up in an e-mail, and because attachments aren't included in e-mails, they can safely attach Word docs, pdfs, screenshots etc. with no worries about it being in any emails.
I'm trying a work around by adding a URL to the attchached file for FTP download in the email notification template.
The path of an attached file named FILE.DOC look like this in the attach directory of JIRA: "attach/PROJ/PROJ-10/ 10041_FILE.DOC" I only know ${issue.getKey()} to get PROJ-10. Many thanks, Hi,
If you are using 3.7.x you can get the project key via $issue.getProjectObject().getKey(), if using an older version then $issue.getProject().getString('key') would work. You can always consult the JIRA API, http://www.atlassian.com/software/jira/docs/api/latest/ Thanks, Too many issues with attached files sent out with email notification.
By the way internal users do not need these in their email either, or need to clean them due to mailbox quota. This may be useful to someone looking for a workaround. As we all already have an FTP server so just need to add an anonymous account (locked down, not browsable, writetable, etc) serving the JIRA attach directory. Then add URL to attached files in the email template, html for internal users and text for customer. ALL attached file(s), html template, Just attached file(s), text template, Has anything been implemented to address and/or resolve this issue?
We are using Jira as the basis of our helpdesk system and Student Enquiry tracking procedure. As such, we are hampered by the inability to send email attachments with comments on jobs. Whilst we understand the security issues outlined above, we would have presumed that setting the "Viewable by" option on a comment would address this irritation. We would like to vote for this feature, even if it were settable on a per-project basis. If this isn't likely to be added, would someone be able to give us step-by-step instructions on setting up the custom transition and mail listener Nick Menere mentioned in his post above (14/Apr/05 02:09 AM)? Thanks, Hello,
We have made the development and will publish it in the coming days as – Hi Mickaël,
Did you successfully create a plugin for sending attachments? If so, have this been published? Thanks, Hello,
Yes, we made the plugin and we are using it in production. Thank you for the reminder. We will publish it this week on our web – Hi Mickaël,
I can't find the plugin, could you please post the link. Thank you Hi Mickaël,
Is there any movement on publishing that plugin? Thanks Peter Hello,
I did not forget but time is flying. – Le 18 juil. 08 à 22:21, "Peter Weatherdon (JIRA)" <jira@atlassian.com> Thanks Mickaël,
No problem, I have now added myself as a watcher so I will get a notice Thanks Peter On Fri, Jul 18, 2008 at 4:45 PM, Mickaël Rémond (JIRA) <jira@atlassian.com> My company uses JIRA as a support system with email only communication (Our clients do not log into JIRA). Often our support team needs to send a screenshot to a client. Currently when we need to send a screenshot or file we include a link to our FTP server. However we feel this feature would be very useful. In our case it would be great if when we attach a file to an issue there was a check box that if checked sends a notification with the attachment and if unchecked sends a notification that a file was attached to the issue but without the attachment included. To resolve the issue of people not getting the notification due to attachment restrictions a second check box that if checked would send one notification that they should expect another notifcation with an attachment, then the system would send the attachment immediatly after in a second notifcation. That way a client could reply to the first notification stating they did not receive the attachment. Also adding additional attachment related permissions would help, ie. view own attachments, view all attachments, able to receive attachments in notifications, etc. Also maybe add the ability to make an attachment viewable by only certin project roles just like comments (if this is not already possible). I know this is low on the list of priorities but to companies that would use this feature it would be a very welcome addition.
Thanks |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
We are using JIRA in a user support scenario where we want to leave it to the user whether he uses the web interface or not (Users are accustomed to email communication and some don't want to change).
Currently we attach our files to JIRA and send them to the reporter / all watchers manually afterwards.