При работе с устаревшими или сильно кастомизированными конфигурациями на обычных формах (такими как 1С:Управление торговлей 10.3) разработчики часто сталкиваются с жестким требованием заказчика: «Дайте нам возможность настраивать права доступа прямо в режиме Предприятие, без конфигуратора и сложных RLS-запросов». Типовой механизм ролей в конфигураторе слишком инертен, требует монопольного доступа для обновления и неудобен для оперативного управления доступом. Рассмотрим подробно, как создать гибкое и универсальное решение на базе регистров правил.
Основная идея заключается в переносе логики проверки прав из жестко заданных ролей в динамическую таблицу (регистр сведений). Проанализируем структуру такого регистра, который позволит гибко управлять доступом. Нам понадобится создать независимый непериодический регистр сведений, например, с именем РегистрПравилДоступа.
Измерения регистра:
Строка (имя метаданных) или СправочникСсылка.ИдентификаторыОбъектовМетаданных.СправочникСсылка.Пользователи или СправочникСсылка.ГруппыПользователей.ПеречислениеСсылка.ВидыПравДоступа (Чтение, Добавление, Изменение, Удаление).Ресурсы регистра:
Булево.Строка или ХранилищеЗначения (здесь можно хранить настройки компоновки данных для сложных ограничений по полям, например, «Разрешить только для Организации А»).Такая структура позволяет администратору в режиме «1С:Предприятие» просто добавлять строки в таблицу, определяя, кто и что может делать в системе.
Чтобы заставить систему учитывать настройки из нашего нового регистра, разберем механизм внедрения проверок. Использовать стандартный RLS (Row Level Security) на запись часто бывает нерационально из-за сложности его отладки и влияния на производительность транзакций. Вместо этого применим подписки на события.
Создадим общую подписку на событие ПередЗаписью для всех необходимых документов и справочников. В обработчике подписки пропишем вызов универсальной функции контроля:
Процедура ПередЗаписьюОбъектаДляКонтроляДоступа(Источник, Отказ, РежимЗаписи, РежимПроведения) Экспорт
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Выясняем, новое это право (Добавление) или корректировка (Изменение)
ВидОперации = ?(Источник.ЭтоНовый(), Перечисления.ВидыПравДоступа.Добавление, Перечисления.ВидыПравДоступа.Изменение);
Если Не ПраваДоступаСервер.ПроверитьПраво(Источник, ВидОперации, ПараметрыСеанса.ТекущийПользователь) Тогда
ОбщегоНазначения.СообщитьПользователю("У вас недостаточно прав для выполнения данной операции!");
Отказ = Истину;
КонецЕсли;
КонецПроцедуры
Рассмотрим подробнее преимущество такого подхода: в коде функции ПроверитьПраво мы можем реализовать любую сложную логику, включая проверку динамических дат запрета редактирования. Например, можно разрешить менеджеру править документ только в течение двух дней после его создания, что практически невозможно реализовать стандартными ролями без изменения конфигурации под каждого пользователя.
Одной из частых задач является ограничение редактирования «задним числом» не для всех сразу, а индивидуально. Выясним причину, почему типовой механизм даты запрета часто не устраивает клиентов — он обычно глобален. С помощью регистра правил мы можем добавить ресурс СрокРедактированияВХорсах (или днях). Тогда проверка будет выглядеть так:
Функция ПроверитьСрокРедактирования(Объект, ТекущийПользователь)
Срок = ПолучитьСрокИзРегистра(Объект.Метаданные().Имя, ТекущийПользователь);
Если Срок > 0 Тогда
Если (ТекущаяДата() - Объект.Дата) / 86400 > Срок Тогда
Возврат Ложь; // Срок истек
КонецЕсли;
КонецЕсли;
Возврат Истина;
КонецФункции
Как отмечают опытные разработчики, основная сложность внедрения подобных систем — это объем объектов метаданных. Если вы предоставите руководителю список из 500 справочников и 300 документов для настройки «галочек», он быстро «утонет» в этом объеме. Проанализируем, как упростить этот процесс:
При проектировании универсального решения необходимо помнить о безопасности данных на уровне чтения. Внимание: программная проверка в подписке на событие или в форме работает только тогда, когда пользователь взаимодействует с объектом через интерфейс или стандартный программный вызов. Если у пользователя в роли в конфигураторе стоит галочка «Чтение» на документ, он все равно сможет увидеть его данные через «Универсальный отчет» или прямой SQL-запрос, так как подписки на чтение (в отличие от записи) в старых версиях платформы ограничены.
Для полной изоляции данных (чтобы менеджер видел только свои реализации в отчетах) все же придется использовать RLS на чтение, но его можно сделать максимально простым, ссылающимся на один-единственный параметр сеанса, который заполняется при входе в систему на основании данных из нашего РегистраПравилДоступа.
Если бюджет проекта позволяет, стоит обратить внимание на готовые расширения и подсистемы, такие как «Регистры правил» от сторонних разработчиков (например, решения 33lab). Они уже содержат в себе все необходимые подписки, интерфейсы для настройки прав и оптимизированные механизмы проверки, что избавляет от необходимости «изобретать велосипед» с нуля. Однако, если требуется специфическая логика (вроде контроля прав на изменение конкретных реквизитов формы), ручная доработка на базе вышеописанной архитектуры будет более предпочтительной.
Таким образом, мы разобрали, что создание универсального решения по правам доступа в УТ 10.3 — это задача, требующая баланса между гибкостью настройки в «Предприятии» и жесткостью контроля на уровне метаданных. Сочетание регистра правил и подписок на события является наиболее оптимальным путем для решения этой проблемы.