✅ 定義：Odooにおける「カスタマイズ」とは？
| 分類 | 内容 | カスタマイズに該当するか？ |
|---|---|---|
| 設定変更 | UIからモジュールのON/OFF、オプションのスイッチ変更（例：Suggested Features） | ❌ 基本的に標準設定の範囲。 ＝「構成（Configuration）」と呼ばれる |
| Studioでの画面追加 | 項目追加、ビュー編集、承認フロー設定 | ✅ ノーコードの軽微なカスタマイズとされる |
| 標準モジュールの拡張 | 標準モデルに対して inherit や view の継承を使って追加 | ✅ コードレベルのカスタマイズ |
| 標準モジュールの改変 | 既存機能のオーバーライド、直接コード変更 | ✅⚠️ 原則NGなハードカスタマイズ（非推奨） |
| 新規モジュールの追加 | 自社専用アドオンの開発 | ✅ 最も一般的な正式カスタマイズ方法 |
✅ 「モジュールを有効にする」ことはカスタマイズ？
→ いいえ、「構成（Configuration）」であり、カスタマイズとは区別されます。
たとえば：
sale_couponを有効にしてクーポン機能を使う
→ これは「機能を有効化した」だけで、コードもDB構造も変えていない。
→ Odooとしては構成の一部。
✅ カスタマイズとみなされる例（開発者視点）
| 行為 | カスタマイズ？ | 備考 |
|---|---|---|
| モデルに新しいフィールドを追加 | ✅ | Studioでもコードでも |
| ワークフローの条件追加 | ✅ | ステートやボタンロジックを変更 |
| 既存メニューや権限の上書き | ✅ | ir.ui.menuやrecord rulesを変更 |
| ビューの構造をコードで変更 | ✅ | XPATHやtemplate継承 |
| コードで標準処理をオーバーライド | ✅⚠️ | def create, write, action_... など |
✅ 一方でカスタマイズではない例
| 行為 | 備考 |
|---|---|
| モジュールのインストール / アンインストール | Suggested FeaturesやApp画面経由の導入 |
| 設定メニュー内のオプション変更 | 価格リスト、マルチ倉庫、クーポンなど |
| 標準レポートのパラメータ指定 | 期間・対象など |
| セキュリティグループの選択 | 例：ユーザーに「販売マネージャー」権限を付与 |
✅ 実務での表現整理
| 状況 | 推奨表現 |
|---|---|
| Suggested FeaturesでモジュールをON | 「機能を構成した」「標準機能を有効にした」 |
| Studioでフィールド追加 | 「ノーコードカスタマイズ」または「設定レベルのカスタマイズ」 |
| コードで拡張（inherit） | 「技術的なカスタマイズ」または「開発ベースのカスタマイズ」 |
| コアの書き換え | 「ハードカスタマイズ」または「非推奨なカスタマイズ」 |
✅ 結論
「モジュールを有効化する（Suggested Features含む）」こと自体は カスタマイズとはみなされない（＝構成の一部）
ただし、その機能に対してコードを追加・変更すれば カスタマイズ扱い になります。
Odoo Studio の Automation（自動化） は、特定の条件が満たされたときに、レコードに対して自動アクションを実行する強力な仕組みです。
これは開発不要で業務ルールを自動化できる「ノーコードワークフローエンジン」として設計されています。
✅ 全体構造の理解（大きな流れ）
Trigger（きっかけ）
↓
Apply On（対象レコード条件）
↓
Actions To Do（実行する処理群）
🧩 各項目の説明と相互関係
① Trigger（トリガー：いつ発動するか）
| 種類 | 説明 |
|---|---|
| On Creation | レコードが新規作成されたとき |
| On Update | レコードが更新されたとき |
| On Deletion | レコードが削除されたとき |
| Timed Trigger | 指定日時や期限前後に発動（定期的にチェック） |
📝 特定フィールドだけが変更されたときに発動などの細かい指定は On Update と併用
② Apply On（適用条件：どのレコードに対して発動するか）
条件タイプ：
- Match all of the following rules（AND条件）
- 条件式を複数指定可能（例：状態が draft、金額が 10万以上など）
条件例：
state = draftamount_total > 100000customer = True
🧠 この段階で、Automation の対象レコードが「絞り込み」される
③ Actions To Do（実行するアクション：何をするか）
トリガー＋Apply On の条件を満たしたレコードに対して、以下の操作を行います：
| アクション名 | 説明 |
|---|---|
| ✅ Update Record | 対象レコードの値を更新（例：state を confirmed に） |
| ✅ Create Activity | 次の担当者にタスク通知（営業のToDoなど） |
| ✅ Send Email | 指定されたテンプレートでメール送信（例：確認メール） |
| ✅ Send SMS | SMSで通知（Twilioなどの連携が必要） |
| ✅ Add Followers | レコードのフォロワーに特定ユーザーを追加（通知目的） |
| ✅ Create Records | 関連する他モデルのレコードを作成（例：注文→請求） |
| ✅ Execute Code | Pythonコードを直接書いて高度な処理を実装（開発者向け） |
| ✅ Send Webhook Notification | 外部システムへWebhook送信（他システムと連携） |
| ✅ Execute Existing Actions | 登録済みのir.actions.serverを呼び出す（再利用） |
🚨 複数のアクションを同時に実行可能。順序制御は不可（同時扱い）
🔁 関係性まとめ（流れ図）
mathematicaコピーする編集する┌────────────┐
│ Trigger │ ← いつ？
└────┬───────┘
↓
┌────────────┐
│ Apply On │ ← どのレコードに？
└────┬───────┘
↓
┌────────────┐
│ Actions To Do│ ← 何をする？
└────────────┘
✅ 活用例（営業案件）
条件：見積が確定されたときに、自動で請求書を作成して通知したい
| 項目 | 内容 |
|---|---|
| Trigger | On Update |
| Apply On | state = confirmed |
| Actions To Do | Create Record（account.move）＋Send Email |
✅ 注意点
- 条件は **すべて満たす（AND条件）**が基本
On Updateの場合、何が変わったかを明示的に指定しないと誤作動することがあるExecute Codeではrecord,envが使えるが、Studio外のPython知識が必要
✅ 結論：Automationの設計ポイント
| 観点 | 意識すること |
|---|---|
| Trigger | 業務の「いつ」起こすか（更新か作成か） |
| Apply On | どういう条件で処理すべきか（業務ルール） |
| Actions To Do | 何を自動で行うべきか（人手削減や通知など） |
コメントを残す