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