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