Использование RLS в 1С Предприятии 8

Начиная с платформы 8.0 системы 1С Предприятие, существует возможность ограничивать права доступа пользователей на уровне записей. Для этого используется механизм RLS (Record Level Security). Такая «тонкая» настройка может быть полезна для ограничения доступа по организациям, клиентам, номенклатуре и др.

RLS – это возможность разработчика задать условие на таблицы базы данных для тех или иных пользователей (групп пользователей) и не дать им увидеть лишнего. Условие имеет булевый тип. Если значение условия принимает значение «истина», то доступ предоставляется, в противном случае – запрещается.

RLS используется одновременно с настройкой обычных прав доступа. Поэтому прежде чем приступить к настройке RLS, необходимо раздать обычные права на объекты конфигурации.

RLS применяется для следующих видов прав доступа:

  • Чтение
  • Добавление
  • Изменение
  • Удаление

Порядок настройки RLS

Рассмотрим простой пример выполнения настройки. Снимки экрана сделаны на версии 1С Предприятие 8.2 (8.2.9.356). Синтаксис шаблонов текстов ограничений описан в документации по 8.2 в книге «Руководство разработчика. Часть 1», поэтому на нем останавливаться не будем.

Итак, первым делом нужно определить шаблоны ограничений для каждой существующей роли.

 

  

 

 

 

 

 

 

 

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

Для редактирования нескольких ролей удобно управлять через окно «Все роли».

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

Вот и все. Можно проверить результат.

Недостатки использования RLS:

  1. Применение механизма ограничения доступа на уровне записей приводит к неявному увеличению таблиц, участвующих в запросе, что может привести к ошибкам в клиент-серверном режиме работы базы данных.
  2. Для контроля записи бывает трудно или невозможно реализовать сложную логику приложения. В таких случаях лучше использовать условия в процедуре ПриЗаписи().
  3. Написание условия (запроса) требует определенной квалификации разработчика.
  4. Дополнительные трудности может создать невозможность отладки условия (запроса).

В типовых конфигурациях права на уровне записей могут быть заданы интерактивно для следующих объектов: организации, контрагенты, номенклатура, склады, подразделения, физические лица, заявки кандидатов и другие.

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

Использование RLS в 1С Предприятии 8: 6 комментариев

  1. Как и где присваивается значение параметру 1 и переменной в запросе

  2. Первый параметр ты описываешь самостоятельно в правах пользователя в разделе «Ограничения доступа к данным». В моем примере Владелец — это ссылка на головную организацию.
    Переменная в запросе — это значение одноименного параметра сеанса.

  3. Да, роли это хорошо. Но как быть с тем..
    Я сделала ограничение на контрагентов, в регистре задала что пользователь А-видит только одних контрагентов, а пользователь В- видит других, но что делать с тем что может произойти задвоение контрагентов, т к по видимости у менеджера А одни контрагента/В-другие, менеджер не будет сравнивать что у него есть а чего нет, неудобно..тоже самое с номенклатурой..
    Что вы можете посоветовать?

  4. За ведение справочников Контрагенты и Номенклатура должны отвечать 1-2 ответственных сотрудника. Это официальный ответ фирмы 1С. Сталкивался с такой проблемой, пытался бороться, но все равно мой подход приводил к бардаку в системе. Поэтому лучше ограничить доступ пользователей к ведению справочников.

  5. Вы бы лучше посмотрели как в типовых такая ситуация разруливается… Для того чтобы не задвоились контрагенты и прочие, вы должны некоторые из реквизитов дать на чтение всем кто в этом может быть заинтересован. Итого например так: код, наименование, РНН, наименованиеполное. Обычно выдается в роль Пользователь. В т.ч. такая вещь необходима может быть при списании партии, мен. по продажам может не видить группу Поставщики Х и соотв. их документы, но списать товар с партии поступления от этого поставщика должен иметь право… Если у него не будет права на чтение этой партии получит ошибку. Должен уметь читать ссылку, версию, и прочую лабуду, а просмотр можно оставить закрытым. И тогда он при записи объекта-дубликата контрагента он получит ошибку, потому что в базе он прочитать может о наличии такой записи, а вот увидеть сам эту запись не может. Но тут появляется вопрос, а почему если мен. Б работает с контрагентом А, контрагент А настроен в группу которую мен. Б не видит?
    Все равно спасибо за статью.

Комментарии запрещены.