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