Signs of Triviality

Opinions, mostly my own, on the importance of being and other things.
[homepage] [index] [jschauma@netmeister.org] [@jschauma] [RSS]

Updating Jira tickets via mail

GodzillaMy preferred workflow is largely command-line and email driven. I frequently have a number of systems send me notifications of events via email: I get alerts via email, I get code commit messages via email and I get ticket updates via email. This works well if I can also respond to these events via email. That is, I routinely reply to a ticket- or code commit message and expect the system that initially sent me mail to be able to handle mail replies in return.

Many systems can easily be set up to accept incoming email and Do The Right Thing, but it turns out that Atlassian's Jira ticketing system requires per-project email addresses to be set up in order for users to be able to reply to ticket mail and get their response added as a comment. This can be annoying to set up for the administrators and so, in the mean time, I wrote a small little tool to work as a reverse mail filter: it takes email as input, checks if it should go to Jira and will post the comment via Jira's REST API. You can find it here and on GitHub.

Since it is a filter, it will still spit out the incoming email, so that you can then choose to pipe it into whatever program you normally use to actually deliver your mail.

Obviously, in order to use this tool, you have to send mail locally, so that you can actually feed your outgoing mail to this program from within your MUA. I use mutt on my laptop (reading mail retrieved via fetchmail and procmail) locally, dispatching mail to msmtp. Now unfortunately mutt does not appear to support a pipeline for the sendmail parameter in my ~/.muttrc, so I had to create a trivial shell script to wrap the new invocation:

#! /bin/sh
jiramail | /usr/pkg/bin/msmtp -t

Next, jiramail needs to authenticate with the Jira instance. Ideally, I'd be using OAuth for this, but again it seems that this is not quite as straight forward as I would have wished. It is still unclear to me whether or not I can get OAuth tokens from Jira for individual applications for individual users (ie versus a site-wide token). So again, I feel back on the less desirable, but quicker and simpler solution: authentication using the user's password.

Layer Cake jiramail can prompt the user for the password, but that is somewhat inconvenient in an outgoing mail filter. Instead, you can also set the environment variable JIRA_PASS, so as to avoid additional (and repeated) interactions with the tool. And so another wrapper comes to life, ~/bin/mutt:

#! /bin/sh
stty -echo
read -p "Jira Password: " p
stty echo
export JIRA_PASS="${p}"
/usr/pkg/bin/mutt

Yes, this is in some ways ridicolous: just in order to be able to update Jira tickets via email I now have a separate filter, an outgoing mail server wrapper script and a mutt-start-up script. But hey, all problems in my world can be solved by another level of indirection, right?

August 22, 2012


[Integrating Duo 2FA with OpenVPN] [Index] [Spectacular File System Confusion]