目次
Redmine の通知を Mattermost で受け取るには？
背景
今回の現場は、ちょっと特殊な環境。
- 現場での作業であるか否かにかかわらず、2 段階で RDP を繋ぎ、作業はすべてその先で行なう。
- ただし、メールのやり取りやオンライン会議は 1 段目の方で行なう。
一方、よくあるパターンで、「進捗管理は数多ある Excel で」「質疑や依頼、相談などは『Excel の管理表』＋ 2 段目の環境にあるチャット（Mattermost）で」という体制。これはものすごく非効率なので（特にコミュニケーション手段がオンライン会議以外で「チャット」と「直接会話」しかないのがつらい）、強く要望してなんとか Redmine を導入してもらった。
ところで、Redmine の強力な武器は、メールによる通知。しかし、メールは 1 段目の環境でしか読めず、通常の作業は 2 段目でのみ行うことになっていることもあって、メールで通知したとしても気付けない。Redmine のサーバ自体は 2 段目の環境内にあってブラウザで読み書きできるので、通知も Mattermost で受け取りたい……
ということで、Redmine と Mattermost との連携を模索してみた。
Mattermost 側の仕込み
まずは Mattermost で通知を受け取れるようにならないと話にならない。調べたところ、「Incoming Webhook」による方法と「パーソナルアクセストークン」による方法があることが判った。
メッセージを投稿できるようになるまで（Incoming Webhooks 編）
- システムコンソールの「統合機能＞統合機能管理」で「内向きのウェブフックを有効にする」を「有効」に設定
- システムコンソールの「統合機能＞統合機能管理」で「統合機能によるユーザー名の上書きを許可する」と「統合機能によるプロフィール画像アイコンの上書きを許可する」を「有効」に設定
- これをやっておかないと、3. で投稿元ユーザ名の指定ができず、仮に投稿元ユーザ名を指定してあっても Webhook の作成者名に強制される
- 「統合機能」で「内向きのウェブフック」を選択し、「内向きのウェブフックを追加する」を押して Incoming Webhook を追加する
- 「チャンネル」の指定は何でもいいが、「このチャンネルに固定する」にはチェックしないこと
- 「ユーザ名」に通知元ユーザ名を設定しておくと、実際の投稿時に username の指定を省略可能
- 以下のようにすると投稿できる
- チャンネル宛
curl -i -X POST -d 'payload={"text": "＜テキスト＞", "username": "＜通知元ユーザ名＞", "channel": "＜投稿先チャンネル名＞"}' ＜Webhook の URI＞ - DM（Mattermost クライアントのサードバーでは、投稿者名に関わらず、Incoming Webhook の作成者から DM が届いたように見える）
curl -i -X POST -d 'payload={"text": "＜テキスト＞", "username": "＜通知元ユーザ名＞", "channel": "＜「@」＋通知先ユーザ名＞"}' ＜Webhook の URI＞
- 必要に応じて、システムコンソールの「環境＞投稿頻度制限」の設定をする
メッセージを投稿できるようになるまで（パーソナルアクセストークン編）
- 通知の投稿に使用するオフラインユーザを登録する
sudo -u mattermost mmctl --local user create --username="redmine" --email="メールアドレス" --password="パスワード"
- 登録したユーザをチームに招待する
- システムコンソールの「統合機能＞統合機能管理」で「パーソナルアクセストークンを有効にする」を「有効」に設定
- システムコンソールの「ユーザー管理＞ユーザー」で 1. のユーザのメニューから「ロールの管理」を選択し、以下のように設定
- 「このアカウントがパーソナルアクセストークンを生成できるようにする」にチェック
- 「投稿:全て」にチェック
- 1. のユーザでログイン
- 右上のユーザアイコンを押して表示されるメニューから「プロフィール」（またはユーザアイコンとユーザ名の項目）をクリック
- 表示されたメニューの「セキュリティー」タブで「パーソナルアクセストークン」の項の「編集する」をクリック
- 「トークンを生成する」をクリックし、「トークンの説明」を記入後に「保存する」をクリックして、表示されたアクセストークンを控える
- 「トークンID」は再表示可能だが、「アクセストークン」は再表示不可。紛失した場合は、一旦トークンを削除して再作成。
- 投稿する
- チャネルへの投稿
- 投稿先のチャネルを表示し、ヘッダに表示されているチャネル名（左側の一覧ではない）のメニューから「情報を表示する」を選び、ID を見る
- その ID を使って以下のようにする
curl -i -H 'Authorization: Bearer ＜投稿元ユーザのアクセストークン＞' -H 'Content-Type: application/json' -d '{"channel_id": "＜チャネルの ID＞", "message": "＜メッセージ＞"}' http://mattermost.gotanda.or.jp:8065/api/v4/posts
- DM の投稿
送信元ユーザ ID と送信先ユーザ ID を指定して「ダイレクトチャンネル」を作成し、そのチャンネルの ID を指定して送信する必要があるらしい。めんどくちゃい。
結論
こと DM の送信に関しては、Incoming Webhook を使うのが圧倒的に楽。で、Redmine 側のプラグインがどうだか調べたところ、（その範囲では）すべて Incoming Webhook を使用していた。これで、万一希望に沿うように改造することになっても、障壁は低い (^^;。
Redmine 側の仕込み
Redmine 側のプラグインとしてとりあえず 3 つ見つかったが……
- 「
redmine_mattermost」は最近メンテナンスされておらず、4.x 系まででしか動かないっぽい。 - 「
redmine_issue_assign_notice」は担当者が変更された際に新旧担当者に通知を飛ばすものだが、「redmine_messenger」もこの機能を持っていることが判明。
というわけで、以下に redmine_messenger との組み合わせについて雑にまとめておく。
- 設定において「『メッセンジャーのチャンネル』の指定は必須」とされているが、これは「通知先を書かないと通知されないよ」という意味であり、この項目が空であってもエラーになったり動作に支障が出たりするわけではない。
むしろ、「Send direct messages」にチェックを入れてあれば通知先のアカウントへ DM が飛ぶ（正確には通知先のチャネル一覧に通知先ユーザ名が追加される）ので、それで十分。 - 実際のコードを「送信先をログに吐く」よう改造して観測した結果、上記の設定をした場合の通知は以下の通り。なお、いずれの場合も、「更新者本人には飛ばさない」設定がされている場合はそれが優先される（通知先ユーザが複数いる場合、本人以外に対してのみ飛ぶ。通知対象が本人のみの場合は通知が飛ばない）。
- Watcher へは飛ぶ
- 担当者にも飛ぶ
- 担当者の変更があった場合、旧・新両担当者に飛ぶ（上記の通り、
redmine_issue_assign_noticeプラグインの機能も内包している） - チケットの作成者にも常に飛ぶ（これは困る……）
- Incoming Webhook の作成者にも常に飛ぶ（これも困る……）
- これについては、「ダイレクトメッセージ」欄での表示がおかしな状態になる（DM 内の送信者名とは関係なく、自分が更新すると第三者から DM が来たように見えたり、第三者が更新すると自分から来たように見えたり……）。
- 通知専用のユーザを作り、そのユーザで Incoming Webhook を作ればそういう問題は解消する（「ダイレクトメッセージ」欄でも通知専用アカウントからの DM に見えるようになる）が、今度はそのユーザに対して常に通知が飛ぶ、という問題が発生する。
ただし、「既存の通常ユーザを bot アカウントに変換する」ということができ、それをするとそのアカウントではログインできなくなるので、「通知専用のユーザに通知が無駄に溜まっていく」という事態は避けられる（と思いたい……）。 - ちなみに、ユーザの変換は GUI 上ではできず、以下のコマンドを実行する必要がある。
mmctl user convert ＜変換するユーザ名＞ --bot
- Wiki については、「Wiki の作成」「Wiki の更新」へチェックを入れてあっても一切飛ばない（これも困る……）
なお、設定項目にある「ユーザー名をその人についての投稿（＠ユーザー名）に変換する」「ウォッチャーを表示する」「チケットの更新」の効果は、よく判らない……