Добрый день, вопрос к гуру RLS, подскажите пожалуйста, можно ли только средствами данного механизма сделать такую штуку. Чтобы отдельные пользователи могли просматривать элемент справочника "Контрагенты" в форме списка, но не могли при этом выбирать его в заказах, видеть в задачах и т.д. Я почитал о RLS, но насколько я понял, можно только дать права на чтение, удаление, добавление, изменение. Т.е. если я не дам право на чтение, то пользователь и в списке видеть этого клиента не будет. Как лучше решить эту проблему? Подпилить форму выбора из этого справочника и остальные места где нужно ограничение?
---
RLS накладывает дополнительные условия на работу с ТАБЛИЦАМИ. Соответственно и прикручивается к таблицам, а не к сущностям (типа "Контрагенты").
Вполне можно разрешить видеть контрагента в списке (таблица контрагентов), но запретить видеть и создавать заказы по этому контрагенту (таблица заказов). Про таблицы регистров тоже не забыть.
Срабатывают ограничения в момент соответствующего обращения к табице (попытка чтения, попытка записи). То есть выбрать контрагента в заказе пользователь сможет (если есть права на чтение таблицы контрагентов), но при попытке записи такого заказа получит исключение (если запрещено писать заказы с этим контрагентом).
Все очень просто и железобетонно. Если нужно что-то сверх этого - RLS уже ничем не поможет.
---
RLS накладывает дополнительные условия на работу с ТАБЛИЦАМИ. Соответственно и прикручивается к таблицам, а не к сущностям (типа "Контрагенты").
Вполне можно разрешить видеть контрагента в списке (таблица контрагентов), но запретить видеть и создавать заказы по этому контрагенту (таблица заказов). Про таблицы регистров тоже не забыть.
Срабатывают ограничения в момент соответствующего обращения к табице (попытка чтения, попытка записи). То есть выбрать контрагента в заказе пользователь сможет (если есть права на чтение таблицы контрагентов), но при попытке записи такого заказа получит исключение (если запрещено писать заказы с этим контрагентом).
Все очень просто и железобетонно. Если нужно что-то сверх этого - RLS уже ничем не поможет.
---
Спасибо, осталось разобраться с реализацией, буду пробовать!)
---
Подскажите пожалуйста, создал роль, в ней добавил рлс правило на изменение документ "ЗаказКлиента", для теста написал небольшой запрос, я так понимаю теперь у меня запрет на проведение любого заказа, так как условие всегда истинно, но почему-то у пользователя, которому присвоена эта роль нет ограничений, заказы проводятся( что я сделал не так?
---
У вас стоит условие, что если контрагент в списке контрагентов, то менять можно. Вот программа и дает менять.

Простой вариант реализации: заведите параметр сеанса "Текущий пользователь" и при старте системы устанавливайте его.
Заведите регистр сведений "Пользователь - Контрагент" , в роли пропишите , что если контрагент есть для этого пользователя в регистре сведений, то можно писать, если нет, то нет.
---
Я переписывал условие и таким образом:

```1c
    ЗаказКлиента ГДЕ НЕ ЗаказКлиента.Контрагент В
    (ВЫБРАТЬ
    СписокКонтрагентов.Ссылка
    ИЗ
    Справочник.Контрагенты КАК СписокКонтрагентов)
```

Это ничего не дало. А по поводу параметров сеанса и рс, не могу добавить их т.к. конфигурация стоит на поддержке, а расширение не позволяет менять структуру метаданных (
---
У пользователя есть еще роли с правами на заказ клиента ?
---
Да, это пользователь с полными правами. Я думал рлс работает поверх ролей, т.е. перекрывает их, это не так?
---
Совсем не так. РЛС работает так же как все роли в 1С, если хоть одна роль разрешает, значит можно.
---
Я думал рлс работает поверх ролей, т.е. перекрывает их, это не так?
Нет. RLS - это "уточнение" работы ролей (конкретизация, как роль будет работать на уровне записей таблицы). При "сложении" ролей в 1С пользователь получает "наибольшие" права.
---
Понял, всем огромное спасибо, буду двигаться дальше!)
---
Просто для информации.
В подсистеме БСП "Управление доступом" реализован очень гибкий и интересный подход. Чтобы избежать перекрытия ролей и при этом дать максимально гибкие возможности настройки прав доступа используется правило - для каждого объекта, на каждый вид доступа к этому объекту (чтение/изменение) создается ОТДЕЛЬНАЯ роль. Получается много-много ролей. Но в каждой - только одно ограничение. Поэтому "перекрытие" разных ролей на одной таблице исключается в принципе.
А чтобы с этим было удобно работать, уже в рамках подсистемы реализованы т.н. "профили доступа", которые объединяют эти микро-роли в какие-то осмысленные логические единицы, по которым уже можно удобно выдавать доступ пользователям (в пользовательской части пользователя включают в какую-то группу доступа, ассоциированную с профилем, а БСП при этом сама автоматически накидывает пользователю все нужные микро-роли).
---
не понимаю. В метаданных предусмотрено на каждый вид документа 27 прав. Роль в 1с предусматривает хранение всех установленных/не установленных прав доступа на все объекты метаданных. Как минимум в метаданных в результате 80% предусмотренного для метаданных пространства не используется (1 право из 5 укрупненных(чтение, запись, проведение, удаление, отмена проведения), в худшем 1/27). Сколько процентов от размера cf составляют роли?
---
Сколько процентов от размера cf составляют роли?
Без понятия. Я не смотрел на формат сохранения ролей в метаданных. Но даже если ваше предположение верно и в случае микророли она занимает неоправданно много места (в чем я очень сильно сомневаюсь - лично я могу придумать массу вариантов оптимизированного хранения ролей в случае их частичного наполнения. Модель хранения метаданных скорее документная, чем реляционная), то я не вижу в этом большой проблемы. Во всяком случае на практике это никогда проблемой не становилось.
---
Для моего понимания доступно в конфигураторе только одно право - это "чтение", булево, поскольку оно фигурирует в запросах как выбрать разрешенные.
Остальные вполне могут быть реализованы программно, тем более с такими же нагромождениями как БСП в модулях как статусы возврата или отказ.