Odoo Owned Media By Maruweb

契約書の電子署名をOdoo Signで運用し始めると、すぐにこんな要望が出てきます。

「担当者が契約書を送る前に、上長のチェックを挟みたい」

契約書は一度相手に送ってしまうと取り消しがききません。誤ったテンプレート、誤った宛先、まだ社内合意が取れていない条件 — 送信ボタンの手前に関所が欲しくなるのは自然なことです。

弊社でも「担当者2名が署名依頼を送る際、代表の承認を必須にする」仕組みを作りました。結論を先に言うと、Odoo標準+Studioのノーコード機能では実現できず、最小構成のカスタムモジュールで実装しました。この記事は、その「できると思ったらできなかった」検証過程と、最終的に本番で動いている仕組みの実録です。

Odoo Signに承認フローを検討している方は、遠回りせずに済むはずです。

作りたかった仕組み(要件)

1. 担当者が署名依頼の「送信」を押すと、メールは飛ばずに承認待ちになる(ここが最重要。承認前に相手へメールが届いたら意味がない)
2. 承認者にOdoo内で通知が届く
3. 承認すると送信され、却下すると送信されず依頼者に理由が通知される
4. 承認者自身の送信は素通り(自分の送信に自分の承認は不要)
5. 承認待ち/承認済み/却下の履歴が一覧で見られる
6. 対象者・承認者の変更は、コード修正なしで設定画面だけでできる

第1ラウンド:Studioの「承認規則」で試す

Odoo(Enterprise)にはStudioというカスタマイズ機能があり、その中に「ボタンに承認を紐づける」承認規則があります。公式ドキュメントの手順は「Studioで対象のビューを開き、ボタンを選択して承認ステップを追加する」— まさに求めていたものに見えます。

罠その1:SignではStudioの公式手順が使えない

ところが、Odoo SignでこのStudio正規ルートは使えません。Signの編集画面は特殊な作り(カスタムクライアントアクション)のためStudioの起動ボタン自体が無効化されており、送信ウィザードは一時的なポップアップのためStudioで開こうとするとエラーになります(Odoo 19で実機確認)。

そこで技術メニューから承認規則のレコードを直接作る回避策を取りました。場所は、開発者モードを有効にした上で:

設定 → 技術設定 → ユーザインタフェース → スタジオ承認規則

対象をSignの送信処理(モデル sign.send.request / メソッド send_request)にし、承認者を代表に、ドメイン(適用条件)を「作成者 ≠ 代表」にして、承認者自身は素通りになるよう設定します。

罠その2:ブロックは効くが、承認する手段がない

設定は動きました。担当者が送信しようとすると「承認が不足しています」でブロックされ、メールも飛びません。ここまでは狙い通り。

しかし致命的な問題が実測で判明します。承認依頼がどこにも作られないのです。原因はOdooの内部構造にあります。Signの送信ウィザード(sign.send.request)はTransient(一時レコード) — 画面を閉じると消滅するデータです。承認規則は「そのレコードへの承認」を管理する仕組みなので、対象レコードが消滅するウィザードでは、承認依頼が永続化されず、承認者の受信箱に何も届かない。

つまりこの構成は「担当者を永久にブロックする装置」にしかなりません。承認して再開する導線が、仕組み上存在しないのです。さらに、消滅したウィザードを参照する承認記録が残ると、それを表示しようとした画面がクラッシュするおまけ付きでした。

結論:Studioの承認規則は、通常のフォームのボタンには有効ですが、ウィザード(Transient)経由の処理 — Odoo Signの送信はまさにこれ — には使えません。 これは公式ドキュメントには書かれていない、実測しないと分からない制約でした。

第2ラウンド:最小構成のカスタムモジュールで実装

他の代替(自動化ルール=送信時点でメールが飛ぶため承認前に止められない/署名順序で擬似承認=契約書PDFに承認欄が出てしまう)も検証した上で、カスタムモジュール一択と判断。sign_send_approval という小さなモジュールを実装しました。

設計の要点は3つだけです:

1. 送信処理を横取りする: Signの送信メソッドをオーバーライドし、「承認が必要」グループのユーザーの送信は、メールを送らずに申請内容(テンプレート・宛先・件名・本文)を通常のレコードとして保存する。Transient問題はこれで解消 — 承認対象が消えないので、承認→再開が成立します
2. 承認者にはアクティビティで通知: 承認者は届いた申請を開き、「承認して送信」なら保存内容のまま送信が実行され、「却下」なら理由が記録されて依頼者に通知されます
3. 人はグループで管理: 「承認が必要なユーザー」「承認者」の2グループを作り、人員の変更は設定画面のグループ割当だけ。コードは触りません(要件6)

デプロイはOdoo.shのGit連動で、ステージング(本番DBのコピー)で検証してから本番へ。ステージング検証では、開発環境では出なかった権限まわりのバグを2件捕捉できたので、本番コピーでの事前検証は必須工程だと改めて言えます。

本番での動作(全部実画面)

担当者が送信すると「承認待ち」になる

画面の通知にある通り、この時点で相手へのメールは1通も飛んでいません。

承認者に申請が届く

承認すると送信される

却下すると理由付きで依頼者に通知される

実運用初日に早速この却下フローが本領を発揮しました。担当者がテスト送信で、メールアドレスを持たないシステム用連絡先を署名者に指定してしまい、「署名者2の連絡先にメールアドレスが無いため」という理由付きで却下 → 担当者が正しい宛先で再申請、という流れがそのまま回ったのです(この経験から、申請時点でメールアドレス欠落を弾く検証も追加しました)。

依頼者は自分の申請の顛末を一覧で追える

まとめ

• Odoo Signの送信に承認を挟みたい場合、Studioの承認規則は使えません(Sign送信はTransientウィザードのため、承認依頼が永続化されず導線が成立しない)。ブロックだけなら効きますが、それは承認フローではなく送信禁止装置です
• 現実解は2つ:送信権限そのものを絞る(テンプレートの権限設定で担当者を外す=ノーコードだが承認ではない)か、小さなカスタムモジュールで承認フローを実装するか
• モジュールで作る場合の設計の勘所は「送信を横取りして通常レコードに保存する」こと。これでメール保留・承認再開・履歴管理が全部成立します
• 検証はステージング(本番DBコピー)で。開発環境では出ないバグが出ます

「承認を挟みたい」は多くの会社で必ず出てくる要望なのに、Odoo Signには標準機能がなく、ノーコードの抜け道もありません。同じ壁に当たった方の遠回りが、この記事で少しでも減れば幸いです。

---

この記事の内容に必要なOdooプラン

• Odoo Sign単体(署名・テンプレート): シングルアプリ無料プランから利用可能
• 本記事のようなカスタムモジュールの導入(Odoo.sh/オンプレ): カスタムプラン以上が必要

→ Odooを無料で試してみる: https://www.odoo.com/ja_JP/pricing

(1アプリ・ユーザー数無制限・無期限で無料)

承認フローを導入したい方へ

Odoo Signの承認フロー設計・カスタムモジュール開発・導入のご相談を承っています。本記事のモジュールをベースにした構築も可能です。

→ マルウェブに相談する https://www.maruweb.co.jp/ja/contact/

関連記事:DocuSignからOdoo Signへテンプレートを移行した実録はこちら → https://www.maruweb.co.jp/solution/odoo/media/?p=2098