Правила доступа - освновная часть безопасности в Odoo. Они контролируют к каким записям пользователь имеет доступ. Например, пользователь продаж может иметь доступ только к его собственным продажам и коммерческим предложениям.

• Правила доступа может упростить разработку функциональности в Odoo (поскольку правила уже настроены)
• Однако, могут быть турдности связанные с несколькими ограничениями для одной модели(таблице БД).
  
  • Например, после установки стороннего модуля или включение опции Access to Private Addresses  могут появится непредсказуеммые результаты
  
  

Краткое рукводоство

1. Пользователи имеют группы доступа к приложениям (например, Вадим Семенович может быть Менеджер по закупкам и  Пользователь склада).
2. Каждая из этих групп доступа может «наследовать» доступ от связанной группы, например:
   • Менеджер по закупкам  наследует от  Пользователь по закупкам все его права
   • Пользователь по закупкам наследует все права от Внутренний пользователь
3. Пользователь может быть членом группы доступа "Технические настройки", каждая из которых имеет опредленные назначения, например:
   • Управление несколькими единицами измерения
   • Аналитический учет
4. Каждая группа доступа дает доступ к:
   1. БД
      
      1. Модели
      2. Записи (через Правила доступа)
      3. Поля (обычно не используется) 
   2. Представления 
   3. Меню
   4. Windows Actions
   5. Другим элементам таким как (Кнопки, Фильтры, Wizards)
5. Доступ от всех этих групп комбинирован, например, пользователь может иметь Доступ для чтения в одной группе, в другой для Записи. Ниже будет описано Разрешения).
6. Если нет правил для записей, то нет никаких ограничений на записи.
7. В версии 11 Odoo и более ранних версиях на учетную запись администратора не распространялись правила записи. В Odoo 12 и более поздних версиях учетная запись администратора является членом всех групп доступа и подчиняется правилам записи, но также имеет возможность стать «суперпользователем» и обходить правила доступа. 

Правила доступа

Правила доступа используют Домен для выборки записей с ограничениями.

Есть два типа Правил Доступа:

1. Глобальные правила (без заданной группы пользователей).
   • Они ограничивают доступ и не могут быть обойдены другими правилами доступа.
   • Они обычно используются для ограничений доступа у нескольких компаний.
   • Так же они легкие в понимании!
2. Приавла по группам  (для одной или нескольких групп доступа - например, Менеджер по закупкам)
   • Они предоставляют разрешение (с учетом ограничений, установленных Глобальными правилами). 
   • Если существует несколько групповых правил, то доступ предоставляется, если ЛЮБОЕ из условий выполнено.
   • Это может затруднить понимание правил, специфичных для группы, и при их использовании необходимо соблюдать осторожность.

ПРИМЕР

Группа доступа “Sales / User: Own Documents Only” имеет Правило доступа на модуль Продажи с доменом:

['|',
 ('user_id','=',user.id),
 ('user_id','=',False)
] 

Это позволит получить доступ только:

• для пользователя собственника заказа / предложения (где, пользователь продажи = текущий пользователь) ('user_id','=',user.id)
• и к заказам без указанного собственника(user_id) Заказа / Предложения). ('user_id','=',False)

Однако, группа “Sales / User: All Documents” имеет Правило доступа:

 [(1,'=',1)] 

Это дает доступ всем пользователям Заказа / Предложения.

Внимание: Правила группового доступа почти всегда состоят из двух наборов: один для ограничения доступа, другой для предоставления полного доступа (также возможен набор из трех или более правил).

Права доступа

Права доступа дают разрешение на одно или все из следующих действий:

1. Чтение
2. Запись (изменение)
3. Созадние
4. Удаление

Прошу заметить, что доступ на Чтение нужен для ограничений/разрешений просматривать записи в моделт!
Есть несколько возможных типов доступа, в том числе:

• Только для чтения
• Чтение и запись (но не создание и удаление)
• Чтение, Запись и Создание( но не удаление)
• Полный доступ

Это можно сделать в правах доступа или правилах доступа, вот важная разница между ними:

1. Если Доступ для чтения не указан в Правах доступа к модели и группе пользователей, у пользователя(ей) не будет доступа для чтения к этой модели *
2. Если Доступ для чтения не указан для Правил доступа с группой пользователей, то домен не  будет применяться для этого Правила  и не будет никаких ограничений*.
   • Однако, если есть другие Правила доступа на чтение для этой модели, они будут применяться.

* Обратите внимание, что в обоих приведенных выше примерах пользователи могут быть членами других групп пользователей, которые будут предоставлять или ограничивать доступ.

На примере заказа на продажу / предложений (sale.order) :

• Как правило, только менеджер по продажам может удалять заказы на продажу (это из доступа прав доступа к модели)
• Как объяснено выше, некоторые менеджеры по продажам могут получить доступ только к своим собственным заказам (через Правила доступа).
• Вы можете добавить Правила доступа:
  1. Только супервайзеры или менеджеры могут отменить подтвержденные заказы на продажу
  2. Все пользователи по продажам могут отменить предложения (в черновики заказов на продажу)
     • Отмененный заказ на продажу все еще находится в базе данных Odoo, и менеджер сможет его удалить.

Трудности

It’s easy to have problems with Record Rules because of the way they interact with each other. These can be in either direction:

• access is allowed when it should not be,
• users are not allowed do something they should be able to do

Here’s one example:

Private addresses

Odoo 12 introduced a Record Rule that was designed to limit access to “private addresses”. It’s on the Contacts model (res.partner).
Just like the above example, there are a pair of Record Rules:
1. Allow access to “private addresses” for selected users

[('type', '=', 'private')]

2. Allow access for all users to other “non-private addresses”

['|', 
 ('type', '!=', 'private'), 
 ('type', '=', False)
]

This Record Rule grants access to all internal users through the “Internal User” access group (“Employee” in earlier versions). This group is inherited by all application access groups.
The problem is that the second Record Rule would effectively override other Record Rules for Contacts.

• For example, you might have used Record Rules to limit access to vendors (suppliers), but:
  • a user who had not had access to vendors would now be granted access (because type will be blank).
    • They would also be able to access private addresses for customers and other types of contact!

That’s because access is granted if the conditions for ANY of the Group-specific rules are satisfied – and these can come from multiple access groups.
The solution is either to remove the two “private address” rules or to replace them with several rules that cover all the combinations.

Alternatives

It is also possible to restrict access without using Record Rules.

• Domains can be added to restrict access to fields in views (easy to do in Odoo Studio).
• Changes can be made to menus:
  • Limit access to menus
  • Create different menus with specific domains (example)
• Other options are available by doing development.

The disadvantage of these methods is that it will normally require the restrictions to be applied in multiple places (which, of course, is what makes it more flexible). But it is easy to miss one or more views and then the user has access they should not have!

List of Record Rules for a user (Odoo 13)

Navigate to Settings / Users & Companies / Users

These “smart buttons” can be useful for troubleshooting, and you can use Filters to show information for one or more Models:

This shows us that the user has full access to their own sales order lines (from the “Sales / User: Own Documents Only” group) plus Read-Only access to Sales Order lines for projects (as the “Project Administrator”).
This is the domain for the second Record Rule:
['&', '&',
('state', 'in', ['sale', 'done']),
('is_service', '=', True),
'|', ('project_id','!=', False), ('task_id','!=', False)]
This selects Sales Order Lines that are:

• confirmed or locked, and
• service items and
• with either a project or task id

This will be used when billing from timesheets, so it logical that this access is available for a Project Administrator.
Note: there should be no conflict between these two Record Rules (sometimes the combination produces undesirable results, as explained above).