メールからRedmineのチケットを自動登録する時の注意点

メールからRedmineのチケットを自動登録する時の注意点をメモ書き。

【1】第8回RxTStudy勉強会で、@g_maedaさんは、顧客からの問合せメールをRedmineのチケットに自動登録する機能によって、ヘルプデスク管理をチケット管理に置き換える事例を紹介している。

第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

Redmineによるメール対応管理の運用事例 from g_maeda

メール対応に付随する苦労の多いヘルプデスク管理をRedmineのチケット管理に置き換えたことによって、チケット管理の恩恵が得られる利点を強調されていた。
その反面、下記の課題がまだ残っていると話されていた。

(1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。
(2)メールソフトとRedmineを行ったり来たりして面倒。
　メール対応という一つの目的で2つのツールを使っている。
(3)古いメールに新たな問合せを返信メールで送る顧客もいる。
　古いチケットNoがSubjectに入っている場合が多い。
(4)サポート担当者からメールを発信する場合、SubjectにチケットNoがないので、チケットが登録されない。
　顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを、一つのチケットでまとめたい場合がある。
(5)ステータス変更し忘れる。
　忘れた頃に、終了チケットへ返信メールが追加されるが誰も気づかない。
(6)発信元アドレスがチケットに記録されない。
　メールによるRedmineチケット登録機能では、匿名ユーザとしてチケット登録されるため、メール送信者(顧客)の情報がチケットに残らない。

上記の課題のうち、手運用でカバーせざるをえないのは、(1)(3)(5)だろう。
(2)は、Redmine画面上で返信メールを送信できる機能をプラグインで作るべきかもしれない。

そのうち、(4)と(6)の解決策について、考えてみた。

【2】サポートデスクからの送信メールと顧客からの受信メールで、同一のチケット番号を振るようにするプラグインを@yusuke_kokuboさんが公開されている。

Redmine Mail Intergration plugin - こくぼ＠Everything is the experience.

(引用開始)
◆背景
Redmineにはチケットが更新されたときなどにメールで通知してくれる機能があります。さらにその通知メールに返信することで注記を書けたりします。
さらには、Redmineのメールアドレスを宛先に含めておくだけでRedmineがメールを受信してチケットにできる機能もあります。
いろいろ便利な機能がそろっているのですが、うちの会社の使い方ではちょっと痒いところに手が届きません。

◆なにに困ってるの
マネージャ「お客さんからこんなこと頼まれたんだけど、Aさんこの作業お願い！」
とお客さんからの依頼をAさんのメールアドレス宛にRedmineのメールアドレスをCCに入れて転送しました。*1
Redmineはメールを受信してチケットに起こして通知メールを投げます(投げったっけ？)。

◆Aさんが受け取ったメール
この時点でAさんはマネージャからのメールとRedmineからの通知メールを受け取っています。
AさんがRedmineからの通知メールに返信すればRedmineは注記として処理できます。しかし元々のマネージャからのメールに返信すると、Redmineは返信元のチケットを特定できないので、新たにチケットを作成してしまうのです。注記にできないどころか無駄なチケットが作られてしまいます。困りました。

◆そこで作ったプラグイン
Redmineがメール受信したときにメールのMessageIDと処理したチケットNoを覚えておくプラグインを作りました。
この場合でいうと、最初にマネージャが投げたメールを処理したときにMessageIDとチケットNoをDBに保存します。
そしてAさんからの返信を受信したときに、メールのin-reply-toからMessageIDを検索して処理元のチケットを特定します。

◆まとめ
これでRedmineを意識できない人でもとりあえず宛先にRedmineのメールアドレスを含めておいてもらえば、チケットに履歴が残っていってハッピーになれるかもしれません。
(引用終了)

つまり、(4)顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを一つのチケット番号でまとめる機能は、上記のプラグインで実現されている。

但し、MessageIDとチケットNo、ユーザ名を保持する新規テーブルが1個増えるので注意。
また、GitHubのemail.rakeを見ると最新版よりも古いので、パッチを当てるなどの動作検証が必要と思う。
だから、すぐに上記のプラグインですぐに解決できるとは限らないのが残念だ。

YusukeKokubo/redmine_mail_intergration

redmine_mail_intergration/lib/tasks/email.rake at master ・ YusukeKokubo/redmine_mail_intergration

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

上記のプラグインの機能をRedmine本家に取り込んでもらえないのだろうか？

【3】(6)発信元アドレスがチケットに記録されない課題については、RedmineはCRMソフトとして使えるか？: プログラマの思索にも書いたけれども、顧客問合せメールからRedmineチケット登録時に、顧客を新規ユーザとして登録する機能を使う方法もある。

メールからチケット登録する場合のRedmineのオプションはRedmine本家のWikiに書かれている。

RedmineReceivingEmails - Redmine

Redmineのソースemail.rakeを読むと、下記のオプションがある。

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

(引用開始)
General options:
unknown_user=ACTION how to handle emails from an unknown user
ACTION can be one of the following values:
ignore: email is ignored (default)
accept: accept as anonymous user
create: create a user account
no_permission_check=1 disable permission checking when receiving
the email
no_account_notice=1 disable new user account notification
default_group=foo,bar adds created user to foo and bar groups
(引用終了)

つまり、「unknown_user=create」オプションを追加すれば、Redmineのユーザーが作成されるのでメールアドレスを保持できる。
さらに、「default_group」オプションを追加すれば、作成されたRedmineユーザのユーザグループまで設定が可能だ。

従って、あらかじめ顧客ユーザだけを含むユーザグループ「顧客」を作っておき、顧客問合せメールからRedmineチケット登録時に、顧客をRedmineユーザとして新規登録するだけでなく、新規Redmineユーザとして「顧客」ユーザグループに属するようにオプションを使えばいい。

つまり、Redmineのユーザグループ＝取引先企業、ユーザ＝企業の担当者としてマッピングすれば、「企業◇--担当者」の関係を実現することができる。

例えば、外部サーバーからメールサーバーへIMAPで問合せメールを検知する場合、下記のようなrakeコマンドになるだろう。

#supportプロジェクトにbugトラッカーでチケット登録し、ユーザは顧客のメールアドレスで新規登録する。
#さらに、新規ユーザは、fooユーザグループに属する。

rake redmine:email:receive_imap RAILS_ENV="production" \\
host=imap.foo.bar username=redmine@somenet.foo password=xxx ssl=1 \\
project=support \\
tracker=bug \\
unknown_user=create \\
no_permission_check=1 \\
default_group=foo \\
allow_override=tracker,priority

但し、TO・Ccアドレス、Subjectの情報はチケットに登録してくれない問題はまだ残る。
Redmine本家に対する今後の改善要望となるだろう。

【3】「メールからRedmineのチケットを自動登録する」機能に注目する理由は、メール駆動の業務をチケット管理へ置換できる可能性を感じるからだ。
普通の社会人ならば、毎日数十～数百通のメールを受け取って、その返信に追われていないだろうか？
実際の仕事は、顧客からの問い合わせメールやシステムの障害検知メールなどが起点となって始まる場合が多い。
すると、メールの履歴を追いかけながら仕事せざるを得ず、メールという古い機能に縛られた流れでしか仕事できない。

メール駆動の仕事の弱点は下記に書いた。
メール駆動はExcel駆動と同様に、何らかの解決策が必要ではないだろうか？

メール駆動開発は時代遅れではないか: プログラマの思索

管理のためのExcelをチケット管理が駆逐しているように、外部とのやり取りはメールというインターフェイスで行っていたとしても、社内ではチケット管理で回せる仕組みが作れないか？
今後も考えてみる。

【追記】@sakaba37さんが、(1)(3)(5)の問題点に対し、返信メールを受け取る時に「ステータス＝New(新規)」でチケット更新すればよいのではないか、と提案されている。
新規ステータスならば、問合せタスクが終了していないので、必ず対応状況のチェックで引っかかるから、現実的な解決策になると思う。
rakeコマンドにstatus=newをセットすればいいので実装は問題ない。

但し、rakeコマンドではデータをロードできないため、結局はシェルスクリプトでメールのヘッダ情報を取得する処理を作りこむしか無い。
From・To・Ccアドレスをrakeコマンドだけでチケットに表示できない課題はまだ残る。

[#Redmine] Redmineによるメール対応管理 - 第８回 #RxTstudy -: ソフトウェアさかば

(引用開始)
さて、前田さんの発表で課題とされていたものに、チケット番号が間違っているものや、クローズしたものの場合がありましたが、これは、関連チケットのステータスをnewか適当なものにすれば良いと思います。
ステータスを変える方法には色々あると思いますが、メールハンドラーを修正しなくてもメールの最後に「Status: New」という行を追加するフィルタのスクリプトを、メールハンドラの前にかませれば良いと思います。
こうすると、クローズされていないメールを管理するだけで、番号違いなども拾う事ができるでしょう。
(引用終了)

svn.redmine.org/redmine/trunk/lib/tasks/email.rakeを読むと、statusのオプションがあるので、実現可能だ。

(引用開始)
Issue attributes control options:
project=PROJECT identifier of the target project
status=STATUS name of the target status
tracker=TRACKER name of the target tracker
category=CATEGORY name of the target category
priority=PRIORITY name of the target priority
allow_override=ATTRS allow email content to override attributes
specified by previous options
ATTRS is a comma separated list of attributes
(引用終了)

【追記2】
@sakaba37さんが上記の課題に対して、幾つかの方法を試されている。

[#Redmine] Redmineによるメール対応管理(その２) - 検証編 -: ソフトウェアさかば