Create Redmine issues via email
At our last meeting we discussed the possibility of the support team (Sarah) being able to create issues on Redmine by sending an email to our Redmine server. Here are the official Redmine docs regarding email issue creation to keep the conversation rolling:
#2 Updated by Boone Gorges over 4 years ago
Sarah or Matt, can you remind us of the current setup? The firstname.lastname@example.org address is obviously a GC address. Does someone access it directly (ie by logging in with a password) or is it somehow piped to another account? I thought I remember Gmail playing some role in Sarah's setup.
#3 Updated by Matt Gold over 4 years ago
Hi Boone, as far as I understand, organizational accounts are now no longer allowed direct login via user/pass. If this presents a problem, I am pretty sure that IT would be willing to work with us on this, as they are using Redmine actively themselves and I am sure they would be interested in creating issues via email!
#7 Updated by Boone Gorges over 4 years ago
- Assignee set to Dominic Giglio
OK. Dom, can I ask you to take the reins on this? We'll need to get the cooperation of IT to set something up, so the decision making process is going to have to look something like this:
1. Make a preliminary decision about which of the options at http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails is going to be best for us. Keep in mind that "best" here means, in part, choosing something that's easy to get set up initially, and easy to communicate to IT. My guess is that option 2 ("Fetching emails from an IMAP or POP3 server") is going to be the simplest, because the customizations it requires will be at the level of Redmine rather than the email server - and I think it's going to be quite a bit easier to convince IT of the necessary steps if it involves a fairly low-priority installation like Redmine.
2. Come up with the desired list of rules, plus the necessary Rakefile (assuming we go with the option I've suggested).
3. Come up with a specific list of items that we'll need from IT. If we go with the suggestion option, it looks like that'll be (a) an IMAP account that we have credentialed (ie, non-delegated) access to; (b) uploading the Rakefile to the appropriate place on the Redmine server, and (c) setting up a cron job. We can sweeten the pot by suggesting that we'll give them the cookbook to do this (plus, ideally, reply-by-email) for themselves as well.
Does this make sense? Can you start the process of doing the required research and working up these recommendations?
#8 Updated by Dominic Giglio over 4 years ago
Yes, Boone. This is the kind of issue that works better for me right now. Something I can work on that is not tied directly to an immediate release.
Let me dig into the instructions, fire up a test install and see what I can come up with for the best balance of functionality and ease of setup/administration.
#9 Updated by Dominic Giglio over 4 years ago
First things first Boone,
Can you ask IT what version of Redmine we're currently running? As I am not an administrator of the entire Redmine install I cannot see our version in the admin. Maybe you can?
Supposedly, email issue creation and reply-by-email have been supported since v0.8.0; but there are currently three Redmine version releases (2.6.0 2.5.3 and 2.4.7) and I'd like to test with the version closest to the one we're using.
I'm going to start testing with the 2.4.7 version for now so I can reply back with more info asap.
#11 Updated by Dominic Giglio over 4 years ago
Thanks and WOW:
RUBY ONE EIGHT SEVEN! Didn't think anyone was still running that! :-)
Our Rails install is also getting close to ancient! Rails is currently at Release Candidate 4.2.0. Ruby is up to 2.1.5.
I'll have to test from their Github repo to get back to v2.2.3.stable, but that's not a problem.
I'm going to attempt to create some issues and then reply to some issues from a local install using a dummy gmail account I use to maintain some stupid social networking accounts. I'll report back with my suggestions for how we should move forward once I get a better feel for how the interaction works. So far I agree that your suggestion for going with Option #2 will probably work out best. Especially to start with.
#13 Updated by Dominic Giglio over 4 years ago
Let's hold off on a request to upgrade right now. That is a major version update of three different software stacks (Ruby, Rails and Redmine). That is a tremendous job to pull off successfully.
We can figure out this email stuff and then circle back to a discussion about asking IT to upgrade the software. We're not the only ones on Redmine, so any problems with an upgrade would affect a lot of people. That's probably why they haven't upgraded yet. It works and a lot of people would be affected by an outage if something went wrong with the upgrade.
#15 Updated by Dominic Giglio over 4 years ago
Here's what I've been able to accomplish so far:
1.) Spun up local install of Redmine. Due to different gem and Ruby requirements I couldn't go all the way back to 2.2.3 (not without unnecessary customization). Instead I'm just testing on the master branch (trunk). As I stated above, I don't think this will be a problem since incoming emails have been supported in Redmine since v0.8.0.
2.) Created a user for myself, created a test project and added myself as a user on that project. This is important: Redmine uses the 'From' field of an incoming email to determine which user the new issue should be associated with. If a user does not exist in Redmine with the same email as the one in the 'From' field it is considered anonymous and ignored by default. However, this default can be overridden to allow anonymous issue creation.
3.) Sent an email from my personal Gmail (the same that exists for my user in the local Redmine install) to the dummy Gmail account I mentioned previously.
4.) Manually executed the same command that the docs tell you to run from cron:
rake redmine:email:receive_imap host=imap.googlemail.com port=993 ssl=SSL username=[FULL_DUMMY_ADDRESS] password=[FILTERED] project=commons-test
5.) Checked the Commons Test project in the local Redmine install and verified that a new issue WAS CREATED for my user. It was almost too easy.
6.) Sent a second email with the subject line: Re: [xxxxxxx #1]
7.) Re-ran the above rake task
8.) Verified that the Commons Test project - Issue #1 did indeed have a new reply. Again, it was almost too easy.
I'm going to let you digest that info and update here again with a list of recommendations I think need to be taken to get up and running with our install.
#18 Updated by Dominic Giglio about 4 years ago
Sorry for the delay. First and foremost, what we need to do in order to push this feature forward is to decide on a canonical email account that will be used by our Redmine install.
There was some discussion above about existing GC addresses and possibly creating a new one. My feeling is that it really doesn't matter where the email account is hosted (we could just as easily create a new Gmail account for this feature) what is important is that the account is used only by this Redmine install. This isn't super important for the issue creation functionality, but when we start replying to issue threads via email I think it will make administration a lot easier if the Redmine cron job doesn't need to worry about other emails being in the account. The existing "no-reply" account that all our notifications currently come from is obviously not going to work. To reply by email to any issue here, the account that sends the notification will need to be able to accept replies.
What it comes down to is this: as long as Redmine can access the account through an IMAP connention we should be able to set the rest up without too much difficulty.
Once we decide what email account Redmine will use, we can begin to create a few issues via email, and once we confirm that is working we can start to reply to existing issues.
#20 Updated by Boone Gorges about 4 years ago
The only thing about a gmail account is that we share this Redmine installation with a few other IT projects, and I'm not sure how they would feel about using an external service for this purpose. I guess my suggestion would be that we offer to use a Gmail account, but throw in that if this is undesirable for some reason, that we could alternatively use a purpose-built GC account that they'd provide for us.
#25 Updated by Boone Gorges about 2 years ago
We've had intervening discussions with IT about it, and I've expressed that email-Redmine interaction is the #1 item on our wish list. I haven't spent any energy or goodwill pushing for implementation, though. If we're going to discuss at the next meeting, it should be in this context (how hard we want to lobby).
#26 Updated by Boone Gorges over 1 year ago
We have had a round of back-and-forth with IT about this. Briefly, the feature is there and partly working. It's possible to create tickets via email, though there are hiccups in the way that the script checks the inbox for new messages that would need to be ironed out before we really tried using the feature. More critically, Redmine's support for updating tickets via email reply is really limited, and depends on certain kinds of configuration that are incompatible with our multi-project setup. (Note to self: see email thread with Lihua and Ko from mid-September 2017 for details.) So, the utility of the feature may be fundamentally limited for use on the GC Redmine installation.
Let's leave this ticket open for further updates.