Допустим, нам поставили задачу добавить в систему роль "Просмотр документов", которая должна открыть доступ на просмотр всех документов.
Роль добавляем в типовую конфигурацию "Управление производственным предприятием" версии 1.3. Поскольку конфигурация типовая был выбран вариант создания новой роли без модификации типовых ролей. В дальнейшем это должно облегчить процесс обновления конфигурации.
Что ж, приступим!
Добавим роль "ПросмотрДокументов" со следующими настройками прав:
Для всех документов мы открыли прва доступа на чтение, просмотр и ввод по строке. Этот набор полномочий должен открыть доступ пользователям на просмотр списков документов. Доступ к зависимым справочникам и документам мы не открывали, чтобы не усложнять пример.
Посмотрим как это будет работать.
Права мы успешно предоставили, пользователь может просмотривать документы, но есть несколько НО!
Как извествно, платформа определяет наличие того или иного права по правил "Если где-то это разрешено, значит право есть, иначе нет прав". То есть, если в одной из 5 ролей пользователя есть право просмотра документов, то значит право у него имеется.
Тут встает следующая проблема: мы добавили роль, открыли доступ только к необходимым документам, но "испортили" типовой механизм ограничения доступа на уровне записей, поскольку не описали выражения ограничений в добавленной роли.
Поэтому, после очередного обновления информационной базы всплывет проблема: RLS больше не работает. По крайней мере у тех пользователей, которым добавлена новая роль.
Помните, добавляя роль необходимо настроить выражения ограничений доступа на уровне записей для объектов, у которых определены разграничения прав на уровне записей в типовых ролях.