В процессе администрирования систем на базе 1С:Предприятие 8 часто возникает классическая дилемма: пользователям необходимо ограничить доступ к данным на уровне записей (RLS) — например, разделить видимость по кассам, организациям или подразделениям, — и в то же время наделить их полномочиями самостоятельно устанавливать дату запрета редактирования. Сложность заключается в том, что в типовых конфигурациях (УТ 11, ERP, КА 2) возможность изменять дату запрета часто «зашита» в роль ПолныеПрава. Если мы оставляем пользователю полные права, механизмы RLS просто перестают работать. Если забираем — пользователь теряет доступ к настройке дат. Рассмотрим, как решить эту задачу правильно.
Прежде всего, проанализируем ситуацию, описанную в теме. При включении профиля Полные права система игнорирует любые ограничения доступа (RLS). Это архитектурная особенность платформы: администратор должен видеть всё. Поэтому для реализации ограничений по подразделениям нам приходится создавать кастомные профили. Однако при попытке добавить возможность редактирования даты запрета в такой профиль, мы сталкиваемся с тем, что стандартная форма настройки может просто не открываться или выдавать ошибку «Недостаточно прав».
В современных редакциях конфигураций на базе БСП (Библиотеки стандартных подсистем), таких как ЗУП 3.1 или последние версии УТ 11, разработчики 1С уже выделили необходимые права в отдельные роли. Если ваша конфигурация достаточно свежая, выполним следующие шаги:
Добавление и изменение дат запрета изменения.Просмотр описания изменений программы, так как она часто необходима для корректного отображения общих интерфейсных элементов.Если типовой роли в вашей версии программы нет (как в случае с УТ 11.1), нам придется воспользоваться конфигуратором. Рассмотрим этот процесс по шагам.
Создадим новую роль, назовем ее, например, ИзменениеДатыЗапрета. В составе прав этой роли необходимо указать доступ к следующим объектам:
ДатыЗапретаИзменения (права на чтение, просмотр, запись, редактирование).ДатыЗапретаИзменения (право на просмотр и использование).ИспользоватьДатыЗапретаИзменения (чтение и просмотр).Важный нюанс: даже если вы проставите все «галки», роль может не заработать в режиме «1С:Предприятие» из-за кэширования справочников метаданных. В системах на БСП права проверяются не только платформой, но и программным кодом через справочник Идентификаторы объектов метаданных.
Разберем ситуацию: вы создали роль, добавили её пользователю, но форма настройки всё равно не открывается. Проблема в том, что справочники системы не знают о вашей новой роли. Выясним, как принудительно обновить эти данные.
Для корректной работы механизмов управления доступом после внесения изменений в конфигураторе необходимо выполнить специальный код в обработке «Консоль кода» или через внешнюю обработку:
// Обновляем справочник идентификаторов объектов метаданных
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника();
// Обновляем внутренние регистры системы прав доступа
РегистрыСведений.ПраваРолей.ОбновитьДанныеРегистра();
РегистрыСведений.ТаблицыГруппДоступа.ОбновитьДанныеРегистра();
// Если используется RLS, обновляем параметры ограничений
УправлениеДоступомСлужебный.ОбновитьПараметрыОграниченияДоступа();
После выполнения этих процедур система «увидит» вашу новую роль в списке доступных ролей для профилей групп доступа, и она начнет функционировать корректно.
Проанализируем еще один подводный камень. В старых версиях УТ 11 (как 11.1.4.13 из примера) проверка прав на изменение даты запрета может быть жестко прописана в коде формы обработки ДатыЗапретаИзменения. Рассмотрим пример функции, которая может блокировать доступ:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
Если Не РольДоступна("ПолныеПрава") И Не РольДоступна("Администрирование") Тогда
// Программный запрет, даже если у роли есть права на регистр
Элементы.ГруппаНастройки.Доступность = Ложь;
КонецЕсли;
КонецПроцедуры
В этом случае у нас есть два пути. Первый — использовать Расширение конфигурации, чтобы перехватить процедуру ПриСозданииНаСервере и добавить в проверку вашу новую роль. Второй — включить вашу роль в список «административных» ролей в общем модуле ПользователиПереопределяемый (в зависимости от версии БСП название модуля может отличаться).
Рассмотрим альтернативный вариант решения, который не требует постоянного ручного изменения даты. В типовых решениях предусмотрен механизм динамической установки. Например, можно настроить дату запрета как «Конец прошлого месяца» с отсрочкой в 5 дней. В этом случае система будет автоматически закрывать период, и пользователям не придется вручную двигать дату, что снимет саму потребность в предоставлении им избыточных прав.
Подводя итог, отметим, что наиболее правильным и современным методом является создание отдельной роли с правами на регистр ДатыЗапретаИзменения и обязательным последующим обновлением идентификаторов метаданных. Это позволяет сохранить работоспособность RLS и обеспечить безопасность данных, не давая пользователям полных прав администратора.