Redmine

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 ?

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

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.

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

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

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".

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

+1 for this feature.

a few opinions: 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.

• would be great to be able to set individual email address
  

I think an email address for each project should work:

i.e.
bugs+myProject@redmine.org
bugs+anotherProject@redmine.org

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.

+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.

+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!

+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?

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.

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

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?

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

Issue #1110 has the start of this.

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.

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.

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

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!

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