Project

General

Profile

Actions

Feature #444

closed

submit issue via email

Added by mark lilly about 17 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Email receiving
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

i don't think this is handled yet, but for our group, we would like to have our user-clients simply email the project
and have it show up as an issue. that's very high on my list.

then, changes to that issue are automatically mailed back to the person.

thanks,
m


Related issues

Related to Redmine - Feature #568: Let end user customer report IssueClosed

Actions
Related to Redmine - Patch #1110: Allow email to create issue or add commentClosed2008-04-25

Actions
Related to Redmine - Feature #393: Role that can't assign a ticketClosed

Actions
Has duplicate Redmine - Feature #491: Email integration more expandedClosed

Actions
Has duplicate Redmine - Feature #1083: Accept new tickets via emailClosed2008-04-21

Actions
Actions #1

Updated by Jean-Philippe Lang about 17 years ago

Do you have more than 1 project that would receive issues by
mail ? If so, what solution do you see in order to know which
project an incoming email is related to ?

Actions #2

Updated by mark lilly about 17 years ago

hi Jean-Philippe,
more than one project, yes. each project has a dedicated
email box, so no worries about parsing out Subject lines for
specific projects.

if they want to send to a single email box, the first step
in triage within redmine would be to assign it to the right
project.

this way, it keeps the complexity down somewhat.

thanks for following up!
best,
m

Actions #3

Updated by Jerry Van Galder about 17 years ago

Hi there - this feature would be helpful for us as well. Our
members submit most of our issues. This includes bugs, feature
requests, improvement suggestions and general support issues.

If there was one project called JoeBlow v2.0 - with the following
issue types:

Bug
Enhancement
Feature Request
Support

and if our members, from a pull down menu on our site, was able
to select one of those and then add a short description, and
have it automatically added to the our JoeBlow v2.o project,
and put in those issue categories when sent would be ideal. The
ability to triage them using a priority scale (Critical, Major,
Medium, Minor, Disregard, etc...) would be cool for triaging
and then can be forwarded to the appropriate person/queue/resource
to deal with it.

Actions #4

Updated by mark lilly about 17 years ago

I think this leans towards some sort of a simple API. adding
items via a simple form on a website, or submitting via
email, you could do a lot of issue creation using different
means....

could be very useful.

thanks,
m

Actions #5

Updated by John Kelly almost 17 years ago

I don't know about everyone else, but how about the issues recieved
by mail go into a "uncategorized" project. Kind of
like a placeholder until someone goes in and manually decides
what project it belongs to. The other option would be to have
the subject line as the project.

On another note, I would love to see this implemented, I love
redmine, and this is the only thing that is holding back our
company from using it over what we are currently using (which
i hate)

Thanks,

John

Actions #6

Updated by Gerhard Hoogterp almost 17 years ago

For me this is also an important improvement. As for how to
handle this a few things come to mind:

start with putting all the mails in a queue with the possibility
to assign them easily to a project

Add an issue number to the subject and check incoming mails for
this number to find back the original project

Add a mail header which would do the same as the subject would
be the third option.

New issues would have to be handled by a person anyhow, replies
to mails, notes etc. could be handled automatically this way..
If not they fall back into the "fallback queue".

Actions #7

Updated by Jos Yule almost 17 years ago

I would agree that this kind of ability would be great.

See the Roundup Issue tracker for some excellent ideas on email
integration.

http://roundup.sourceforge.net

Actions #8

Updated by chris mcharg almost 17 years ago

+1 for this feature.

a few opinions:

  • would be great to be able to set individual email address
    for each project, rather than one for all projects.
  • new issues submitted by email could first be put into some
    sort of "unconfirmed issues" queue to let users know
    that some issue meta info (priority etc) may be missing (this
    would let you skip having to make a messy email parser, and just
    set the subject and description from the email)
  • being able to reply to email notifications (which would add
    notes to the issue) is just as important as being able to create
    issues via email.
  • this functionality should of course be a module that can be
    enabled/disabled in project settings.
Actions #9

Updated by Ross Lawley almost 17 years ago

I think an email address for each project should work:

i.e.

There could also be a default project for the email address if
its invalid. Otherwise could return a fail email if the sender
email address is on the system.

Actions #10

Updated by Rocco Stanzione almost 17 years ago

+1. One way, maybe the best way, to implement this would be
to just provide a script that an email could be piped to by e.g.
procmail. The script would take the project identifier as an
argument and create a ticket with a default tracker (or take
tracker as an optional argument, or set up separate email addresses
per tracker...)

This would allow for the most flexibility, I think, and the least
intrusiveness into the application.

Actions #11

Updated by J P almost 17 years ago

+5 on this one... this is an abesolute deal breaker for us in
this project. Otherwise, Redmine is a perfect fit.

I hope you get this implemented soon.

Thanks for a good (soon to be great) project!

Actions #12

Updated by Mark Gallop almost 17 years ago

+1. Having no ticket creation by email (or api) is also deal breaker for my work place. Any idea if this is to be implemented in the short term?

Actions #13

Updated by Doug Smith almost 17 years ago

We have implemented Redmine in Development, PM, and QA. We would love to use it in IT however, we don't want to train all users on how to use Redmine and put in tickets. Imagine showing a bunch of executives how to use Redmine. They can barely make their Crackberries work. I hope this is a priority on the implementation list as we really need it.

Actions #14

Updated by Mark Gallop almost 17 years ago

As mentioned in #491, this python app looks like would provide some useful ideas for email integration - http://roundup.sourceforge.net.

Actions #15

Updated by Rocco Stanzione over 16 years ago

Jean-Philippe, if you can provide some input on how you would like this to work, I'll write a script. Here's what I'm thinking:

  • A script that takes Getopt style command line arguments, which would be passed by e.g. procmail.
  • Author looks up by name and/or email address in From field. If it's not found, it's anonymous or "Redmine".
  • Subject is simply the Subject line.
  • Project would be a Getopt argument - MDA would be in charge of setting it, probably by configuring per-project email addresses
  • Description would be the body of the email
  • Version 0.1 might not do this, but attachments could be handled in the same way
  • Also maybe not 0.1, but issue updates (comments only) could be handled by the script, by replying

Am I forgetting anything? Do you think this is a good approach?

Actions #16

Updated by Jean-Philippe Lang over 16 years ago

  • Category set to Email notifications
  • Target version set to 0.8

Sounds good to me. Let me know when your script is ready !

Actions #17

Updated by Eric Davis over 16 years ago

Issue #1110 has the start of this.

Actions #18

Updated by Eric Davis over 16 years ago

I want to disagree with the getopt style shell script for three major reasons:

  1. Each time that script starts up, it will have to start a full Redmine/Rails environment. This is a severe performance hit and has been known take down servers (mine included).
  2. This would require changing the MDA and potentially MTA. While not hard, this is another barrier to entry for administrators.
  3. Using a script assumes your Redmine server is the same server as your mail server (or a shared filesystem). In many organizations, this will not be true.

Here's my suggestions, some are echoed on #1110:

  1. Using cron/scheduled tasks, have a single script batch process emails. This will make sure it's running only once and will let the user schedule it on their own. (Could even hook up a button to run it via the web for users who don't want to have it run automatically)
  2. Instead of using a mail filter, why not just use a POP or IMAP mailbox? Everyone has one, they are cheap and easy to setup, and very flexible. Combine this with #1, and we can batch process the entire inbox at once. Ruby's POP and IMAP libraries are pretty easy to use. Each project can have their own IMAP mailbox (or folder).
  3. Using a POP or IMAP will make this a non-issue. As long as the Redmine server can reach the email server, it should be able to scale.

That said, I think this feature would be killer and I have several companies very interested in it.

Actions #19

Updated by Maxim Krušina over 16 years ago

Good Idea, I'm waiting ;)
Anyway, it should be good idea to add confurable Status for tickets created by email. I would like to add new Status like "Received by email" and select this status as default for tickets created by email. It will help me as project manager to sort out tickets created by email and to pass the work or discard tickets.

Actions #20

Updated by Thomas Lecavelier over 16 years ago

Added relation to feature request #393, which should be implemented prior mail submission, and impact it.

Actions #21

Updated by Ewan Makepeace over 16 years ago

What I am really looking for is what is offered by http://www.fogcreek.com/FogBUGZ/ - principally:

  • Simple creation of tickets from incoming emails (already discussed at length above).
  • Optional Automatic response to the sender using a standard template "Many thanks for your feedback XXXX, this has been assigned issue #1234 and can be tracked here." type things.
  • Automatic update of existing issues with emails to reporter (so that I can cc: redmine with my questions and hopefully the user will do the same and it call gets recorded on the ticket).

Just creating tickets from emails is nice, but unless redmine responds appropriately and allows us to capture some of the follow up discussion we are missing half the point.

Generally I like RedMine better than FogBugz, but they really have the email integration done right!

Actions #22

Updated by Eric Davis over 16 years ago

Ewan Makepeace wrote:

What I am really looking for is what is offered by http://www.fogcreek.com/FogBUGZ/ - principally:

  • Simple creation of tickets from incoming emails (already discussed at length above).
  • ..snip..
  • Automatic update of existing issues with emails to reporter (so that I can cc: redmine with my questions and hopefully the user will do the same and it call gets recorded on the ticket).

Just creating tickets from emails is nice, but unless redmine responds appropriately and allows us to capture some of the follow up discussion we are missing half the point.

In issue #1110, there is a discussion (and code) that will create tickets and update existing tickets.

  • Optional Automatic response to the sender using a standard template "Many thanks for your feedback XXXX, this has been assigned issue #1234 and can be tracked here." type things.

That is a great idea. It would be best to open a new feature request for it so it isn't lost in this issue

Actions #23

Updated by Jean-Philippe Lang about 16 years ago

  • Status changed from New to Closed
  • Resolution set to Fixed

Feature added. See #1110.

Actions #24

Updated by Jean-Philippe Lang almost 15 years ago

  • Category changed from Email notifications to Email receiving
Actions

Also available in: Atom PDF