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