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