В процессе работы в 1С:Управление торговлей 10.3 часто возникает задача разграничения прав доступа, когда менеджеры должны видеть и редактировать только те документы, за которые они несут ответственность. Это критически важно для соблюдения коммерческой тайны и предотвращения случайного изменения чужих данных. Разберем подробно, как это реализовать, используя механизмы платформы и встроенные возможности конфигурации.
Механизм RLS (ограничение доступа на уровне записей) — это самый надежный способ защиты данных. Он работает на уровне СУБД: платформа сама модифицирует SQL-запросы таким образом, что пользователь физически не получает из базы данных «чужие» записи. Проанализируем шаги, необходимые для его включения.
Для начала убедимся, что конфигурация позволяет вносить изменения. Если база находится на поддержке, перейдем в Конфигурация — Поддержка — Настройка поддержки и нажмем Включить возможность изменений. После этого необходимо активировать саму константу ограничения в режиме «1С:Предприятие»: Сервис — Настройка учета — Настройка параметров учета (или через список констант «Ограничивать права доступа на уровне записей»).
Теперь перейдем к созданию роли в Конфигураторе:
ЗаказПокупателя).
ГДЕ Ответственный = &ТекущийПользователь
Важно помнить, что &ТекущийПользователь — это параметр сеанса. Рассмотрим подробнее, почему это может не заработать сразу. Если в вашей конфигурации параметр сеанса ТекущийПользователь не инициализирован, система выдаст ошибку. Обычно инициализация происходит в модуле сеанса при старте системы. Если вы добавляете свой параметр, обязательно пропишите его установку в процедуре УстановкаПараметровСеанса.
Разберем ситуацию, когда пользователь имеет несколько ролей. В 1С права работают по принципу сложения. Если у пользователя есть роль «Менеджер» с ограничением RLS и роль «Продавец» без него, то в итоге он будет видеть все документы. Чтобы ограничение сработало, оно должно быть прописано во всех ролях пользователя, имеющих доступ к чтению данного объекта, либо лишние роли должны быть удалены.
Проанализируем влияние RLS на скорость работы. Поскольку платформа добавляет подзапрос к каждому обращению к таблице, это может замедлить работу журналов документов. Особенно это заметно в отчетах. При использовании RLS в отчетах рекомендуется использовать ключевое слово ВЫБРАТЬ РАЗРЕШЕННЫЕ в текстах запросов. Если этого не сделать, пользователь с ограниченными правами получит ошибку при попытке сформировать отчет, содержащий «чужие» данные.
Рассмотрим неприятный побочный эффект RLS. Если вы ограничили доступ к документам, но оставили доступ к регистрам (например, Продажи), то в отчетах пользователь увидит суммы по чужим сделкам, но вместо названия документа в поле регистратора будет написано «Объект не найден» (битая ссылка). Чтобы этого избежать, необходимо настраивать аналогичные шаблоны RLS и для регистров накопления, ориентируясь на поле Ответственный, если оно там присутствует, или ограничивая чтение регистра через регистратор.
Если задача стоит не в жесткой безопасности, а в удобстве работы (чтобы менеджер не путался в чужих заказах), можно воспользоваться программным отбором. Это не защитит данные от просмотра через отчеты или консоль запросов, но значительно упростит интерфейс. Посмотрим, как это реализовать в обычных формах (характерных для УТ 10.3).
В модуле формы списка документа (например, ЗаказПокупателя) в процедуре ПриОткрытии добавим следующий код:
Процедура ПриОткрытии()
// Устанавливаем отбор по текущему пользователю
ЭлементОтбора = ДокументСписок.Отбор.Ответственный;
ЭлементОтбора.Значение = ПараметрыСеанса.ТекущийПользователь;
ЭлементОтбора.Использование = Истина;
// Запрещаем пользователю менять этот отбор вручную
ЭлементОтбора.ВидСравнения = ВидСравнения.Равно;
// В обычных формах можно также управлять доступностью поля отбора в настройках списка
КонецПроцедуры
Выясним преимущество этого метода: он практически не влияет на производительность. Однако помните, что опытный пользователь может найти способ отключить отбор или увидеть данные через другие инструменты (внешние обработки, универсальные отчеты).
В конфигурации 1С:Управление торговлей 10.3 предусмотрен встроенный механизм групп доступа. Перейдем в Настройки учета и включим Использовать группы доступа к контрагентам. Хотя штатно там нет прямого ограничения «только свои документы», можно настроить систему так, что менеджеры будут видеть только «своих» контрагентов. Поскольку документы неразрывно связаны с контрагентами, через RLS по группам доступа контрагентов можно косвенно добиться того, что документы чужих клиентов будут недоступны.
Проанализируем ситуацию: менеджер пытается создать «Реализацию товаров и услуг» на основании «Заказа покупателя», созданного другим сотрудником. Если включен RLS, и менеджер не видит чужие заказы, он не сможет выбрать этот заказ в качестве основания. Система выдаст ошибку прав доступа. Для решения таких коллизий иногда приходится использовать Привилегированный режим в программном коде, который выполняет чтение данных, или пересматривать бизнес-процесс передачи дел между сотрудниками.
Подводя итог, выбор метода зависит от требований заказчика. Если нужна абсолютная конфиденциальность — используем RLS, несмотря на затраты ресурсов. Если нужно только удобство — ограничиваемся программными отборами в формах списков.