開発ポータル用：ビュー設定説明書（業務コンサルタント向け）

この説明書は、Odoo開発ポータルでビュー作成依頼を入力する際のガイドです。
「common settings」では、ビューの種類に依存せず共通で設定できる内容をまとめています。
一覧ビュー・フォームビュー・検索ビュー・Kanbanビュー・グラフビューのいずれでも利用できます。

---

1. 表示制御（フィールド選択・ソート設定）

1-1. 表示フィールド選択

• ビューで表示する項目（フィールド）を選択します。
• 必要な情報を一目で確認できるよう、業務目的に合わせて選びます。

入力例：

• 販売注文一覧 → 「顧客名、受注日、金額、ステータス」
• 請求書詳細 → 「請求書番号、請求日、金額、支払条件」

---

デフォルトソート（Sort by）

• ビューを開いたときに、レコードをどの順序で表示するかを指定します。
• 昇順（小さい値・古い日付から順に）または降順（大きい値・新しい日付から順に）を選択します。

入力例：

• ソートフィールド：作成日　ソート順：昇順　OR　降順

---

デフォルトグループ化（Default group by）

• 初期表示時に、レコードを特定のフィールドで自動的にグループ化する設定です。
• 一覧画面で大量データを整理する際に便利です。

入力例：

• 販売注文一覧 → 「顧客別にグループ化」
• 請求書一覧 → 「ステータス別にグループ化」

---

1-4. デフォルトフィルタ

• 初期表示時に特定条件を自動で適用する設定です。
• 特定の条件でデータを絞り込みたい場合に利用します。

2. 操作権限制御

ビュー上で利用者がどの操作を行えるかを制御する設定です。
依頼時には「画面上での制御」なのか「システムレベルで禁止したいのか」を明確に記載してください。

設定項目	内容	例／備考
can create	新規レコードを作成できるか	「請求書は手動作成を許可しない」
can edit	既存レコードを編集できるか	「販売注文は編集不可」
can delete	レコード削除を許可するか	「顧客マスタは削除禁止」
enable mass editing	一覧画面上での一括編集を許可するか	「販売注文の金額フィールドは一括編集を許可」
show invisible elements	開発用設定。表示条件で隠されたフィールドを可視化するか	通常は「いいえ」でOK

注意

• 画面上の操作制御：Studioで設定可能（リスト編集許可など）
• システムレベルで制御：開発者による権限設定が必要（削除禁止など）

---

3. 作成時の動作（新規レコード作成時の表示モード）

Odoo Studioで設定できる「作成時の動作」には3つのモードがあります。
業務目的に合わせてどれを使うかを依頼時に指定してください。

作成時の動作	説明	適した業務ケース	注意点
インライン	一覧ビュー上で直接、行を追加して入力する	– データ量が多く、入力効率を重視したい場合 – 簡単なマスタや日次明細入力	– フォームビューを開かないため、必須項目が多い場合は不向き
モーダルダイアログ	ポップアップ画面（モーダル）で詳細入力する	– 入力項目が多い場合 – 関連項目をまとめて入力したい場合	– ダイアログ内で必要項目をすべて設定できる
クイック作成	最低限の項目だけ即時入力し、必要に応じて後から編集	– 顧客名や商品名など、最小限の情報だけ先に登録したい場合 – 後で詳細を補完する運用	– 追加設定が必要な場合、ユーザーが必ず後から詳細編集するルールを決めるとよい

3-2. デフォルト値の設定

• 新規レコード作成時に自動で入力される初期値を設定できます。
• 定型業務の効率化に役立ちます。

入力例：

• 「請求日＝本日を初期値に設定」
• 「支払条件＝30日後を自動設定」

3-3. レコード複製（Allow duplicate）

• 既存レコードを複製して新規作成を許可するかどうかを指定します。

設定例：

• 「見積書は複製可」
• 「請求書は複製禁止」

3-4. アーカイブ機能（Enable archive）

• レコードを削除せず非表示にする「アーカイブ機能」を有効化するかを設定します。

設定例：

• 「失注案件はアーカイブで管理」
• 「製造済み商品はアーカイブしない」

4. ビューの意味（AI学習用途）

この項目は、開発ポータル独自のオリジナル設定です。
「なぜこのビューが必要なのか」を記載することで、将来的にAIがビューの目的を学習し、
自動でSQLを組み立てる際の参考情報として活用します。

入力例：

• 「顧客別の販売額を可視化し、営業チームで共有するため」
• 「請求書ステータスを一目で確認し、未回収を早期発見するため」
• 「在庫残高を商品カテゴリ別に分析するため」

設定例：

【対象アプリ／モデル】
販売注文（sale.order）

【作成するビュー種別】
一覧ビュー（リスト）

【設定内容】
・表示フィールド：顧客名、受注日、金額、ステータス
・初期表示時の並び順：受注日 降順
・初期グループ化：顧客別
・デフォルトフィルタ：ステータス=「見積依頼中」
・検索対象項目：顧客名、商品コード

【対象ユーザー】
営業チーム全員

【備考】
顧客別の販売状況を一目で見られるようにする目的

まとめ

• common settings では、ビューの種類を問わず共通で設定すべき内容を整理
• コンサルタントは「どう見せたいか」「どう操作させたいか」を明確に入力
• 複雑なJOINや条件ロジックはStudioで対応できないため、必要に応じて開発依頼する

ビュー別：個別に設定できること（Studio前提）

Form view

項目	できる？	設定場所 / 補足
ビュー名	〇	ビューのプロパティ
モデル	〇	ビューのプロパティ（対象モデル）
ヘッダー表示/非表示	〇	<header>内のボタン類を削除 or 可視条件（Studioでボタンの表示条件設定）
フッター表示/非表示	〇	<footer>内のボタン類を削除 or 可視条件
優先度（並び順）	〇	ビューの「優先度」（数値が小さいほど優先）

注：ヘッダー/フッターは“全体トグル”というより 中のボタンを出す/消す・条件で出し分けの運用になります。

---

List (Tree) view

項目	できる？	設定場所 / 補足
ビュー名	〇	ビューのプロパティ
モデル	〇	同上
インライン編集	〇	リスト設定で「編集を許可」（= editable）
ページ当たりの行数	✕（ビュー単位では不可）　Studioではできないがポータルではできるようにする	既定のページングはWebクライアント側。Studioから 1ビューだけの件数変更はできません。

代替：絞り込み・デフォルト並び・グループ化で“見える量”を調整。大量編集はインライン編集やバッチアクションで対応。

---

Kanban view

項目	できる？	設定場所 / 補足
ビュー名	〇	ビューのプロパティ
モデル	〇	同上
デフォルトグループ化	△（ビュー内ではなく Action/Search で指定）	初期の列分けは Actionのcontextで group_by または 検索ビューのフィルタを既定ON。Kanban自体に“初期グループ”直指定トグルはありません。
クイック作成（トグル）	〇	Kanban設定で quick_create / group_create を有効化（Studioで可）
ドラッグ可能フィールド	△（列を作るグループ化フィールド）	実体は 列の基準＝group_by対象フィールド（例：stage_id）。“ドラッグ先の列”はこのフィールドで決まるため、Action/Search 側で指定します。

---

Calendar view

項目	できる？	設定場所 / 補足
ビュー名	〇	ビューのプロパティ
モデル	〇	同上
開始フィールド	〇	Calendar設定（開始日時フィールドを指定）
終了日フィールド	〇	同上（無ければ duration で代替）
色分けフィールド	〇	Calendar設定（colorフィールド）
デフォルト表示（⽉/週/⽇）	〇	Calendar設定で既定ビュー（例：月）を選択

---

Search view

項目	できる？	設定場所 / 補足
ビュー名	〇	ビューのプロパティ
モデル	〇	同上
優先度	〇	ビューの「優先度」
（補足）デフォルトフィルタ	△（開発者設定が必要）	Studioでフィルタ追加は可。ただし“初期ON（default="1"）”はXML上の属性で付与が必要→依頼で指示すれば反映可。

---

その他のビュー（Graph / Pivot / Gantt など）

項目	できる？	設定場所 / 補足
ビュー名	〇	ビューのプロパティ
モデル	〇	同上
優先度	〇	ビューの「優先度」

追加でよくある指定：

• Graph：指標（measure）・軸（dimension）・チャート種別（棒/折れ線/円）
• Pivot：初期の行・列軸、集計指標
  これらはStudioである程度指定できます（細かな“初期状態の固定”はAction/Searchで補完）。

---

まとめ（修正ポイント）

• OK：各ビューの「名前・モデル・優先度」、Formのヘッダー/フッター可視、Listのインライン編集、Kanbanのクイック作成、Calendarの開始/終了/色/表示モード、Searchの優先度。
• 要修正：
  • Listのエクスポートボタン → ビュー単位ではなく 権限で制御。
  • Listのページ当たり行数 → Studioでは個別変更不可。
  • Kanbanの“デフォルトグループ化” → Action の context group_by または Searchフィルタ既定ONで指定（ビュー内トグルではない）。
  • Searchのデフォルトフィルタ → フィルタ作成はStudioで可、初期ONは開発者側で属性付与が必要（依頼で指示すればOK）。

1. 優先度の意味

Odooでは同じモデルに複数のビューが定義されていることが多いです。
たとえば：

• sale.order モデルには「標準のフォームビュー」「Studioで作ったカスタムフォームビュー」「他モジュールで追加されたフォームビュー」など複数存在します。
• どれを使うかは 優先度の数値で判定されます。

ルール：

• 数値が小さいほど優先される。
• Studioでは次のようにマッピングされています：

Studioの表示	内部のpriority値	適用順位
高 (High)	0 または 1	最優先で適用
標準 (Standard)	16	デフォルト
低 (Low)	32	他に優先度高いビューがあれば後回し

---

2. 優先度の使いどころ

(1) Studioで作ったビューを優先したい場合

• Studioでビューを作ったら「優先度＝高」にすることで、標準ビューよりStudioビューが優先的に適用されます。

例：

• Odoo標準の sale.order フォームビュー → priority=16（標準）
• Studioでカスタムしたフォームビュー → priority=0（高）

→ 販売注文を開いたとき、Studioビューがデフォルトで使われます。

---

(2) モジュールを複数入れている場合

• サードパーティモジュールが追加ビューを持つ場合もあります。
• 優先度を「高」にすると、自社用に作ったカスタムビューを常に最初に適用可能です。

---

(3) 低優先度ビューの使い道

• あえて「低」にすると、基本は標準ビューを使い、必要なときだけ手動で切り替えられます。
• 例：請求書に2種類のフォームを用意し、特殊帳票用は「低」に設定。

---

3. 注意点

注意点	内容
モデル単位の適用	優先度はモデル単位で効く。同じモデルのビュー間でのみ比較される。
ビュー切り替え可能	優先度が低くても、画面右上の「ビュー切替」で選べば使える。
Studio以外での変更も反映	開発者がXMLでビューを追加した場合も、この優先度ルールで競合解消。

View 詳細画面変更願い

リストビューのエクスポートボタンはStudioでは設定できないので省いてください