承認フローの通知メールを整える

発注の承認フローの記事で、割り切ったところを2つ書きました。

• 通知がありません。担当者が発注しても管理者にメールは飛びません
• 注文完了メールも承認前に届きます。担当者には「ご注文ありがとうございます」が届いてしまいます

同じ話の裏表なので、まとめて片付けます。

作るもの

メールを3通に整理します。

画面は EC-CUBE 4.4 の開発環境で、送信先を Mailpit に向けたものです。

メールは3つに分かれている

先にここを押さえておかないと、直したつもりで直っていません。EC-CUBE のメール1通は、こういう構成です。

件名がテンプレートに入っていません。 マスタの列です。だから「テンプレートを上書きすれば文面を変えられる」と思って Mail/order.twig をコピーしても、件名は「ご注文ありがとうございます」のまま残ります。

そして HTML テンプレートが存在すると、本体はテキストと HTML の両方を組み立てて、1通のメールに詰めます。本文が2つあるということです。

注文完了メールに割り込む

本体は注文完了メールを送る直前にイベントを投げています。この中で、組み立て終わったメールそのものを受け取れます。件名も本文も、送る前なら差し替えられます。

承認待ちのときだけ、こう変えました。

• 件名の「ご注文ありがとうございます」を「ご発注を受け付けました（承認待ち）」に置き換える
• 本文の先頭に「管理者の承認をお待ちしています。承認されるまで手配は始まりません」を差し込む

イベントを選んだのは、件名を変えられるのがここだけだからです。テンプレートの上書きでは件名に手が届きません。

テキストだけ直すと足りない

最初はテキスト本文だけ差し込んで、動いたと思いました。件名も変わっているし、テキストにも注意書きが入っています。

届いたメールを開いたら、こうなっていました。

件名は「承認待ち」なのに、本文は「この度はご注文いただき誠にありがとうございます」のまま。 HTML パートを触っていなかったからです。メールソフトは HTML があればそちらを表示します。テキストは見えません。

HTML 側にも同じ注意書きを差し込んで、ようやく揃いました。

差し込みではなく文面ごと入れ替えたいなら、テンプレートを2枚とも上書きすることになります。テキストと HTML の両方です。片方だけ直すと、また同じことが起きます。

承認依頼のメールを足す

管理者に送る通知は新しいメールです。文面は Twig で書きますが、マスタにも1行足しておきます。

そうすると本体のメールと同じ扱いになり、管理画面のメール設定から件名も本文も編集できます。文面をコードの中に持たせないほうが、あとから店舗側で直せます。「承認をお願いします」の言い回しは、店によって好みが割れるところです。

送るタイミングは、注文完了メールに割り込んだのと同じイベントの中にしました。担当者向けの文面を差し替えたついでに、管理者宛の通知も送ってしまいます。

別のフックを増やすより確実です。購入完了画面の表示をきっかけにすると、画面を再読み込みされたときに二重に送りかねません。受注1件につき1回しか通らない場所を選びます。

本文には承認画面へのリンクを入れました。ここは絶対URLで組み立てないと、メールの中でリンクになりません。

承認結果を担当者に返す

こちらは素直です。承認と差し戻しの処理を終えたあと、担当者宛に1通送ります。承認されたのか差し戻されたのかを引数で渡して、テンプレートの中で文面を分けています。

通知が落ちても発注そのものは止めないようにしました。 送信に失敗したときは例外を握って、ログに残すだけにしています。メールサーバーの調子で受注が消えるほうが困ります。

割り切ったところ

管理者は1人だけです。 送り先は担当者の親アカウントに固定しています。承認できるのが1人という承認フロー側の前提をそのまま引き継いでいます。

差し戻しの理由を書けません。 結果メールは承認か差し戻しかを伝えるだけです。理由を載せるなら、差し戻すときに理由を入力させて、受注のメモ欄に持たせることになります。

注文完了メールは注意書きの差し込みです。 元の「ご注文いただき誠にありがとうございます」は本文の下に残ります。ここまで直すならテンプレートの上書きです。

BCC は本体のままです。 注文完了メールは店舗のアドレスに BCC が飛びます。承認待ちの段階で店舗に流れてくるのが困るなら、イベントの中で BCC を外すこともできます。

送信の記録が残るのは注文完了メールだけです。 本体は受注メールの送信履歴をデータベースに残しますが、自分で足したメールは残りません。管理画面の受注詳細から「いつ承認依頼を送ったか」は追えません。

メールが届かないときの落とし穴

EC-CUBE の標準ではメールは同期送信です。送信に失敗すればその場でログに残ります。

ただし、メールを Messenger のキューに載せている環境では話が変わります。 送信処理はキューに入るだけで、実際に送るのは別プロセスのワーカーです。ワーカーが止まっていると、コードは正常に動いているのにメールだけ届きません。

この記事を書いているときに実際に踏みました。承認依頼だけが届かず、送信先の判定を疑って30分ほど溶かしています。原因はワーカーが落ちていたことでした。キュー方式にしている環境では、まずワーカーの生死を見てください。

EC-CUBE 4.2 / 4.3 での違い

メールまわりの作りは 4.2 から変わっていません。注文完了メールのイベントも、メールテンプレートのマスタが件名を持つ構造も、HTML テンプレートが同じ名前で置かれていれば送られる挙動も同じです。

変わるのは、いつもどおりルーティングとアノテーションの書き方です。詳しくはEC-CUBE 4.4 でプラグインが動かなくなる変更点にまとめています。

会員グループ管理を入れている場合

通知メールは会員グループを見ていません。担当者アカウントの親子関係だけで宛先を決めています。会員グループ管理プラグインの有無で挙動は変わりません。

ただ、承認フローを卸売の会員だけに効かせているなら、通知もその範囲にとどまります。一般消費者の注文は今までどおり「ご注文ありがとうございます」が届きます。承認待ちのステータスかどうかだけを見て分岐しているので、一般の注文には触れません。

B2B サイト全体でどこまでが標準・プラグインで、どこからが作るものになるのかは、B2Bサイト全体の線引きにまとめました。