odoo-oca-developer

Odoo OCA 開発者

OCA の規約とベストプラクティスに従って Odoo モジュールを開発するためのエキスパートアシスタントです。

主な機能

1. モジュールの作成

OCA テンプレートを使用して、適切な構成と規約に沿った新しい Odoo モジュールを作成します。

クイックスタート：

python scripts/init_oca_module.py my_module_name --path /path/to/addons --version 17.0

提供される内容：

• OCA に準拠した完全なディレクトリ構成
• 必須キーを設定済みの __manifest__.py
• OCA ガイドラインに沿った README の構成
• 適切な __init__.py インポート
• モデル、ビュー、セキュリティファイルのサンプル

モジュールの命名規則：

• 単数形を使用します：sale_order_import（sale_orders_import ではありません）
• ベースモジュールには base_ を接頭辞として付けます（例：base_location_nuts）
• ローカライズモジュールには l10n_CC_ を接頭辞として付けます（例：l10n_es_pos）
• 拡張モジュールには親モジュール名を接頭辞として付けます（例：mail_forward）
• 組み合わせモジュールでは、Odoo モジュール名を先にします（例：crm_partner_firstname）

2. モジュールの構成

OCA の規約に厳密に従ってください。詳細なガイドラインについては、oca_conventions.md を参照してください。

必須の構成：

module_name/
├── __init__.py
├── __manifest__.py
├── models/
│   ├── __init__.py
│   └── <model_name>.py
├── views/
│   └── <model_name>_views.xml
├── security/
│   ├── ir.model.access.csv
│   └── <model_name>_security.xml
├── data/
│   └── <model_name>_data.xml
├── readme/
│   ├── DESCRIPTION.rst
│   ├── USAGE.rst
│   └── CONTRIBUTORS.rst
└── tests/
    ├── __init__.py
    └── test_<feature>.py

主な原則：

• モデルごとにファイルを1つ作成します：models/sale_order.py
• ビュー名はモデル名に合わせます：views/sale_order_views.xml
• デモデータには _demo 接尾辞を付けます：demo/sale_order_demo.xml
• マイグレーションはバージョン別のフォルダーに配置します：migrations/17.0.1.0.0/

3. OCA 規約への準拠

__manifest__.py の必須項目：

{
    'name': 'Module Name',
    'version': '17.0.1.0.0',  # {odoo}.x.y.z format
    'category': 'Sales',
    'license': 'AGPL-3',  # or LGPL-3
    'author': 'Your Company, Odoo Community Association (OCA)',
    'website': 'https://github.com/OCA/<repository>',
    'depends': ['base', 'sale'],
    'data': [
        'security/ir.model.access.csv',
        'views/model_name_views.xml',
    ],
    'installable': True,
}

Python コードの構成：

from odoo import api, fields, models, _
from odoo.exceptions import UserError

class SaleOrder(models.Model):
    _inherit = 'sale.order'
    
    # Fields
    custom_field = fields.Char(string="Custom Field")
    
    # Compute methods
    @api.depends('order_line')
    def _compute_total(self):
        for order in self:
            order.total = sum(order.order_line.mapped('price_total'))
    
    # Business methods
    def action_custom(self):
        self.ensure_one()
        # Implementation

XML の命名規則：

• ビュー：<model_name>_view_<type>（例：sale_order_view_form）
• アクション：<model_name>_action（例：sale_order_action）
• メニュー：<model_name>_menu
• グループ：<model_name>_group_<name>
• デモ：_demo 接尾辞を付けます

4. OpenUpgrade によるモジュールのマイグレーション

OpenUpgrade のパターンに従って、Odoo のバージョン間でモジュールをマイグレーションします。詳しいガイドについては、openupgrade_migration.md を参照してください。

マイグレーションの構成：

module_name/
└── migrations/
    └── 17.0.1.0.0/
        ├── pre-migration.py
        ├── post-migration.py
        └── noupdate_changes.xml

マイグレーション前の例：

from openupgradelib import openupgrade

@openupgrade.migrate()
def migrate(env, version):
    # Rename fields before module loads
    openupgrade.rename_fields(env, [
        ('sale.order', 'sale_order', 'old_field', 'new_field'),
    ])
    
    # Rename models
    openupgrade.rename_models(env.cr, [
        ('old.model', 'new.model'),
    ])

マイグレーション後の例：

from openupgradelib import openupgrade

@openupgrade.migrate()
def migrate(env, version):
    # Map old values to new
    openupgrade.map_values(
        env.cr,
        openupgrade.get_legacy_name('state'),
        'state',
        [('draft', 'pending'), ('confirm', 'confirmed')],
        table='sale_order',
    )
    
    # Recompute fields
    env['sale.order'].search([])._compute_total()

一般的なマイグレーション作業：

• フィールド名の変更：openupgrade.rename_fields()
• モデル名の変更：openupgrade.rename_models()
• テーブル名の変更：openupgrade.rename_tables()
• 値のマッピング：openupgrade.map_values()
• 不要なデータの削除：openupgrade.delete_records_safely_by_xml_id()

5. モジュールの拡張

OCA のパターンに従って Odoo のコアモジュールを拡張します。

既存のモデルを継承する：

from odoo import fields, models

class ResPartner(models.Model):
    _inherit = 'res.partner'
    
    custom_field = fields.Char(string="Custom Info")

既存のビューを拡張する：

<record id="res_partner_view_form" model="ir.ui.view">
    <field name="model">res.partner</field>
    <field name="inherit_id" ref="base.view_partner_form"/>
    <field name="arch" type="xml">
        <xpath expr="//field[@name='email']" position="after">
            <field name="custom_field"/>
        </xpath>
    </field>
</record>

モジュールの依存関係：

• 依存関係は必ず __manifest__.py で宣言します
• Odoo コア／OCA モジュールには depends キーを使用します
• Python パッケージには external_dependencies を使用します
• インストール要件を README に記載します

6. 検証と品質

モジュールの構成を検証する：

python scripts/validate_module.py /path/to/module

検証項目：

• 必須ファイルの有無（__init__.py、__manifest__.py）
• マニフェストの完全性（必須キー）
• OCA の著作者表示
• ライセンスへの準拠（AGPL-3 または LGPL-3）
• バージョン形式（x.y.z.w.v）
• ファイルの命名規則
• ディレクトリ構成

コード品質ツール：

# Install pre-commit for OCA checks
pip install pre-commit
pre-commit install

# Run checks
pre-commit run --all-files

# Run specific checks
flake8 module_name/
pylint --load-plugins=pylint_odoo module_name/

ワークフローの判断ツリー

「新しい Odoo モジュールを作成したい」 → scripts/init_oca_module.py を使って、OCA 準拠の構成を生成します → モジュールの詳細を __manifest__.py に記述します → models/ ディレクトリにモデルを作成します → views/ ディレクトリにビューを作成します → security/ にセキュリティルールを追加します → readme/ のドキュメントを更新します → scripts/validate_module.py を実行して検証します

「モジュールを新しい Odoo バージョンに移行したい」 → 互換性を損なう変更について OpenUpgrade を確認します → 移行フォルダーを作成します：migrations/<new_version>/ → スキーマ変更用の移行前スクリプトを作成します → データ変換用の移行後スクリプトを作成します → 本番データベースのコピーでテストします → openupgrade_migration.md を参照します

「コア Odoo モジュールを拡張したい」 → 依存関係にコアモジュールを指定して、新しいモジュールを作成します → _inherit を使ってモデルを拡張します → inherit_id を使ってビューを拡張します → OCA の命名規則に従います：<core_module>_<feature> → 変更は最小限に抑え、目的を明確にします

「自分のモジュールが OCA の規約に従っているか分からない」 → scripts/validate_module.py を実行します → oca_conventions.md を確認します → 必須キーが含まれているか __manifest__.py を確認します → ファイルの命名と構成を検証します → OCA の著者表記があることを確認します

リソース

scripts/

• init_oca_module.py：OCA 準拠の構成で新しい Odoo モジュールを作成します
• validate_module.py：モジュールが OCA の規約に準拠しているか検証します

references/

• oca_conventions.md：OCA のコーディング規約とモジュール構成のガイドライン全般
• openupgrade_migration.md：OpenUpgrade の移行パターンとベストプラクティス

assets/

• module_template/：ディレクトリ構成がすべて揃った、公式 OCA モジュールテンプレート

ベストプラクティス

モジュール開発

• OCA テンプレートから始めます：scripts/init_oca_module.py
• 命名規則に厳密に従います
• モデルごとにファイルを分けます
• モデル、ビュー、データを分離します
• OCA のパターンに沿った、意味の分かる xmlid を使います
• 包括的なテストを含めます
• readme/ フォルダーにドキュメントを記述します

コード品質

• Python コードには PEP8 に従います
• XML では 4 スペースのインデントを使います
• SQL インジェクションの脆弱性を作らないようにします
• 正当な理由なく ORM を迂回しないでください
• トランザクションを手動でコミットしないでください
• インポートエラーには _logger.debug() を使います
• 外部依存関係を適切に処理します

Git コミット

形式：[TAG] module_name: short summary

一般的なタグ：

• [ADD] - 新機能／モジュール
• [FIX] - バグ修正
• [REF] - リファクタリング
• [IMP] - 改善
• [MIG] - 移行
• [REM] - 削除

移行戦略

1. 対象バージョンの OpenUpgrade 分析を確認します
2. コアモジュールに互換性を損なう変更がないか確認します
3. まずデータベースのコピーでテストします
4. スキーマ変更用の移行前スクリプトを作成します
5. データ変換用の移行後スクリプトを作成します
6. 互換性を損なう変更を README に記載します
7. セマンティックバージョニングに従ってバージョンを更新します

よく使われるパターン

パターン：依存関係を指定して計算フィールドを追加する

total = fields.Float(compute='_compute_total', store=True)

@api.depends('line_ids.amount')
def _compute_total(self):
    for record in self:
        record.total = sum(record.line_ids.mapped('amount'))

パターン：安全にビューを拡張する

<xpath expr="//field[@name='partner_id']" position="after">
    <field name="custom_field"/>
</xpath>

パターン：セキュリティグループを追加する

<record id="group_custom" model="res.groups">
    <field name="name">Custom Access</field>
    <field name="category_id" ref="base.module_category_sales"/>
</record>

パターン：値のマッピングを伴う移行

openupgrade.map_values(
    env.cr,
    openupgrade.get_legacy_name('old_field'),
    'new_field',
    [('old_value', 'new_value')],
    table='model_table',
)

トラブルシューティング

モジュールがアプリに表示されない

• __manifest__.py の 'installable': True を確認します
• __init__.py のインポートを確認します
• 次を実行します：odoo-bin -u module_name -d database

インポートエラー

• 外部依存関係に try-except を追加します
• readme/INSTALL.rst にインストール方法を記載します
• Python パッケージの場合は requirements.txt に追加します

移行に失敗する

• モジュールの読み込み前に移行前処理が実行されることを確認します
• psql の \d table でテーブル名／カラム名を確認します
• デバッグには openupgrade.logged_query() を使います
• まずデータベースのコピーでテストします

テストが失敗する

• tagged('post_install', '-at_install') を使います
• @users() を使って、最小限のユーザー権限でテストします
• 動的な日付を避け、freezegun を使います
• 外部サービスをモックします

Quick Reference

Create module:

python scripts/init_oca_module.py my_module --version 17.0

Validate module:

python scripts/validate_module.py path/to/module

Check conventions: See oca_conventions.md

Migration guide: See openupgrade_migration.md

Module template: Copy from assets/module_template/