Добрый день! Впервые столкнулся и тестирую РЛС, задача - сделать для определенной роли видимость определенных контрагентов.
В документе поступление товаров в конфигураторе на чтение добавляю ограничение пока что в качестве теста на одного контрагента: ПоступлениеТоваровУслуг ГДЕ ПоступлениеТоваровУслуг.Контрагент.Код = "00-000002". Все работает, я захожу под пользователем с этой ролью и вижу документы только с контрагентом с данным кодом.
Делаю то же самое в справочнике контрагенты: Контрагенты ГДЕ Контрагенты.Код = "00-000002". Захожу в форму выбора - вижу всех контрагентов, захожу в форму списка - то же вижу всех контрагентов.
В гугле инфы не нашел, не понимаю в чем причина разной работы ограничения доступа в двух разных объектах? Заранее спасибо за помощь
---
У пользователя есть другая роль без РЛС на контрагента
---
У пользователя есть другая роль без РЛС на контрагента
---
Благодарю. Печально, что ограничения не накладываются друг на друга в разных ролях
---
Итоговой запрос к таблице БД где хранятся контрагенты строится примерно так:

SEL ECT
      ЗапрашиваемыеПоляТаблицы
FR OM
     ТаблицаКонтрагентов
WHERE
      СписокУсловийФормирумыхДинамически.

Далее:

```1c
    СписокУсловийФормирумыхДинамически = ";
    Для Каждого Роль Из РолиПользователей Цикл
    Если Роль.ИмеетЗапрашиваемыйДоступКТаблицеПолямТаблицы Тогда
    Для Каждого запрашиваемого Поля Из ЗапросаКПоля Цикл
    СписокУсловийФормируемыхДинамически = СписокУсловийФормируемыхДинамически + "И " + RLSЭтогоПоля;
    КонецЦикла;
    СписокУсловийФормируемыхДинамически = СписокУсловийФормируемыхДинамически + "ИЛИ";
    КонецЕсли;
    КонецЦикла;
```

Конечно сильно условно и без скобочек, но как то так.
---
Условия в разных ролях оказывается не накладываются друг на друга. Т.е. если есть роль без ограничения, то ограничения другой роли применены не будут, как я понял. Но в итоге если есть одна роль на объект с ограничениями, то все работает
---
Все условия идут в результирующий запрос с оператором ИЛИ (при складывании ролей) или с оператором И (при складывании RLS по полям. RLS действует на конкретные поля таблицы).

Поэтому "накладываются"/"Не накладываются" это вопрос результата итоговой функции WHERE в запросе.

(4) Это не печально, это одна из концепций реализации механизма доступов. Можете прикинуть на пальцах сами, что было бы, если бы было по другому:

Допустим вам нужно кому то назначить роль "полные права". Тогда вы должны были бы оставить человеку ТОЛЬКО эту роль, потому что очевидно что остальные роли пользователя накладывают ограничения, которые делают из полных прав неполные.

В итоге вы бы отступили от модели "выдачи разрешений" к модели "выдачи запретов". от белых списков к черным - это бы было бы лучше для всевозможных внедрений 1С?

ПС. Вот вы добавили новую подсистему "Сверхсекретная подсистема код сейфа генерального директора" себе в конфигурацию и по предлагаемой Вами непечальной модели все пользователи сразу же по внедрению получили доступ, т.к. они не в черных списках. И что бы настроить эти черные списки, вам надо их всех перешерстить. А потом снова добавляется пользователь "какая то мутная уборщица шпион" и у нее снова есть доступ, потому что черные списки...
---
Согласен, в приоритете доступность, а не ограничение