odoo-security-rules

Odoo のセキュリティルール

概要

Odoo のセキュリティは、モデルレベルのアクセス権（どのユーザーがどのモデルを読み書きできるか）とレコードレベルのルール（ユーザーがどのレコードを参照できるか）の 2 つのレベルで管理されます。このスキルは、正しい ir.model.access.csv エントリーと、ir.rule のドメインベースのレコードルールを作成するのに役立ちます。

このスキルを使用する場面

• 新しいカスタムモジュールのアクセス権を設定するとき。
• ユーザーが自分のデータまたは自社のデータのみを参照できるよう、レコードへのアクセスを制限するとき。
• 「アクセスが拒否されました」または「アクセスが許可されていません」というエラーをデバッグするとき。
• マルチカンパニーのレコード表示ルールを実装するとき。

仕組み

1. 有効化：@odoo-security-rules に言及し、アクセスのシナリオを説明します。
2. 生成：正しい CSV アクセス行と XML レコードルールを取得します。
3. デバッグ：アクセスエラーを貼り付けると、修正方法とともに診断結果を取得できます。

例

例 1：ir.model.access.csv

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_hospital_patient_user,hospital.patient.user,model_hospital_patient,base.group_user,1,0,0,0
access_hospital_patient_manager,hospital.patient.manager,model_hospital_patient,hospital_management.group_hospital_manager,1,1,1,1

注記： CSV を読み込む前に、専用のモジュールマネージャーグループを定義してください（hospital_management はモジュール ID に置き換えてください）。患者データを扱うロールには、広範な設定／管理者グループを再利用しないでください。このグループの例は Odoo 18 を対象としています。インストールされているバージョンのグループフィールドを確認してください。

<record id="group_hospital_manager" model="res.groups">
    <field name="name">Hospital Manager</field>
    <field name="category_id" ref="base.module_category_hidden"/>
</record>

例 2：レコードルール — ユーザーが自分のレコードのみを参照できるようにする

<record id="rule_hospital_patient_own" model="ir.rule">
    <field name="name">Hospital Patient: Own Records Only</field>
    <field name="model_id" ref="model_hospital_patient"/>
    <field name="domain_force">[('create_uid', '=', user.id)]</field>
    <field name="groups" eval="[(4, ref('base.group_user'))]"/>
    <field name="perm_read" eval="True"/>
    <field name="perm_write" eval="True"/>
    <field name="perm_create" eval="True"/>
    <field name="perm_unlink" eval="False"/>
</record>

重要： グループを指定しないルールはグローバルになります（スーパーユーザーモードではレコードルールが回避されます）。グローバルルールは積集合になり、その範囲内でグループルールは和集合になります。perm_unlink=False は、このルールが削除時にチェックされないことを意味し、削除が拒否されるという意味ではありません。ACL は操作権限を加算的に付与し、該当するルールがない場合、レコードルールはデフォルトで許可します。

例 3：マルチカンパニーのレコードルール

<record id="rule_hospital_patient_company" model="ir.rule">
    <field name="name">Hospital Patient: Multi-Company</field>
    <field name="model_id" ref="model_hospital_patient"/>
    <field name="domain_force">
        ['|', ('company_id', '=', False),
               ('company_id', 'in', company_ids)]
    </field>
    
</record>

ベストプラクティス

• ✅ 推奨： 最も制限の厳しいアクセス設定から始め、必要に応じて許可範囲を広げてください。
• ✅ 推奨： マルチカンパニーのルールでは company_ids（複数形）を使用してください。これは現在の環境で有効な会社を反映します。会社の切り替えもテストしてください。
• ✅ 推奨： デバッグモードで管理者以外のユーザーを使ってルールをテストしてください。sudo() はすべてのレコードルールを完全に回避します。
• ✅ 推奨： Odoo の標準グループを再利用するのではなく、モジュールごとに専用のセキュリティグループを作成してください。
• ❌ 非推奨： 業務プロセスで削除が明示的に必要とされていない限り、一般ユーザーに perm_unlink = 1 を付与しないでください。
• ❌ 非推奨： パブリック（未認証）アクセスを許可する意図がない限り、ir.model.access.csv の group_id を空欄にしないでください。
• ❌ 非推奨： モジュールマネージャーに base.group_system を使用しないでください。サーバー設定を含む、技術的な全アクセス権が付与されます。

検証と参照元

重複するグループに属する一般ユーザーとして、本人／他者のレコード、すべての CRUD 操作、有効な会社の切り替え、ポータル／パブリックの各ロールをテストしてください。会社ルールは company_id フィールドがあることを前提としています。False を許可すると、所有者のいないレコードが意図的に共有されます。Odoo のセキュリティ とマルチカンパニーのルールを参照してください。

制限事項

• ORM のフィールド groups 属性を使用してフィールドアクセスを制限できます。OWL／ビューでフィールドを非表示にするだけでは、サーバー側のアクセス制御になりません。
• ポータルユーザーとパブリックユーザーのアクセスルールには、ここで完全には扱わない追加の注意点があります。base.group_portal を使って慎重にテストしてください。
• レコードルールは sudo() によって回避されます。スーパーユーザーコンテキストで実行されるコードは、すべての ir.rule エントリーを無視します。
• PostgreSQL による行レベルセキュリティ（RLS）は対象外です。Odoo はすべてのセキュリティを ORM レイヤーで管理します。