Как в 1С:Управление торговлей 11 настроить права на добавление партнеров только в разрешенные группы доступа

В процессе работы с крупными базами 1С:Управление торговлей 11 часто возникает задача разграничения прав между менеджерами. Типовая ситуация: пользователь должен иметь возможность создавать новых партнеров и работать с существующими, но только в рамках своей «зоны ответственности». В терминах системы это означает ограничение доступа по объекту Группы доступа партнеров. Рассмотрим, как реализовать такую настройку штатными средствами, проанализируем возможные сложности, разберем нюансы работы механизма RLS (Record Level Security) и проведем Аудит прав доступа.

Постановка задачи и анализ механизмов доступа

Выясним основную причину сложности: по умолчанию в системе права на добавление объектов часто выдаются «широким жестом», что позволяет пользователю при создании нового партнера выбрать любую группу доступа или оставить ее пустой. Наша задача — настроить систему так, чтобы в списке выбора групп доступа менеджер видел только разрешенные ему значения и не мог сохранить карточку с недопустимым значением.

Для реализации этого сценария нам потребуется задействовать три уровня настроек:

1. Профили групп доступа — здесь определяются роли и общие правила ограничения.
2. Группы доступа — здесь конкретные пользователи связываются с разрешенными значениями (конкретными группами партнеров).
3. Виды доступа — механизм, через который система понимает, по какому разрезу фильтровать данные.

Шаг 1. Настройка профиля групп доступа

Проанализируем процесс создания специального профиля. Нам не подходят предопределенные профили с пометкой «дополнительный», так как в них зачастую установлена политика «Все разрешены, исключения назначаются в группах доступа». Для нашей задачи нужна обратная логика: запрещено всё, что явно не разрешено.

1. Перейдем в раздел Администрирование — Настройки пользователей и прав — Профили групп доступа.
2. Создадим новый профиль, назовем его, например, Ответственный за ведение партнеров (с ограничениями).
3. На вкладке Роли обязательно добавим роль Добавление и изменение информации по партнерам. Важно убедиться, что у пользователя при этом нет ролей, позволяющих обходить проверку прав (например, Полные права или Добавление изменение партнеров без контроля групп доступа), в чем поможет Анализ ролей (универсальный).
4. Перейдем на вкладку Ограничения доступа. Выберем вид доступа Группы партнеров.
5. Установим значение доступа: «Все запрещены, исключения назначаются в группах доступа». Это критически важный момент — именно эта настройка заставит систему проверять наличие конкретных разрешений в каждой группе доступа.

Шаг 2. Создание группы доступа для конкретного пользователя

Теперь рассмотрим, как привязать созданный профиль к конкретному менеджеру (например, Иванову) и ограничить его только «его» группами.

1. Создадим новую Группу доступа (раздел Администрирование). Назовем ее Менеджеры (Иванов).
2. В поле Профиль выберем созданный нами на предыдущем шаге профиль.
3. На вкладке Участники добавим пользователя Иванова.
4. На вкладке Ограничения доступа мы увидим вид доступа Группы партнеров. Установим для него значение Все запрещены, а в табличную часть Разрешенные значения добавим те группы, в которые Иванову разрешено записывать партнеров (например, группу Менеджеры Поволжье).

После такой настройки система при открытии списка выбора в карточке партнера автоматически отфильтрует только те Группы доступа партнеров, которые мы указали как разрешенные.

Проблема «пустого значения» и автоматизация заполнения

Рассмотрим нюанс, который часто ставит в тупик администраторов. При нажатии кнопки Создать в справочнике Партнеры, поле Группа доступа изначально является пустым. Если в настройках RLS не разрешено значение «Пустая ссылка», то при попытке записи (или даже в момент открытия формы помощника регистрации) система может выдать ошибку «Нарушение прав доступа».

Выясним, как обойти эту проблему без изменения кода:

1. Персональные настройки: В разделе Мои настройки для пользователя можно указать основную группу доступа партнера. В этом случае при создании нового объекта поле заполнится автоматически разрешенным значением.
2. Настройка RLS: В некоторых версиях платформы помогает включение в список разрешенных значений пустой ссылки, однако это может быть небезопасно, так как позволит оставлять поле незаполненным.

Для более жесткого контроля проанализируем возможность использования небольшого расширения. Посмотрим на пример кода, который можно внедрить в процедуру ПриУстановкеНовогоНомера или ПередЗаписью, чтобы гарантировать подстановку группы доступа:

Процедура ПередЗаписью(Отказ, ПараметрыЗаписи)
    Если ЭтоНовый() И ЗначениеЗаполнено(ПараметрыСеанса.ТекущийПользователь) Тогда
        // Логика определения группы доступа на основании подразделения или настроек пользователя
        Если Не ЗначениеЗаполнено(ЭтотОбъект.ГруппаДоступа) Тогда
            ЭтотОбъект.ГруппаДоступа = ПолучитьГруппуДоступаПоУмолчанию(ПараметрыСеанса.ТекущийПользователь);
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Важность разделения Партнеров и Контрагентов

Проанализируем ситуацию: пользователь создал партнера, но система выдает ошибку при попытке сохранить ИНН или банковский счет. Это происходит из-за того, что в 1С:УТ 11 объекты Партнер и Контрагент разделены. Ограничение по Группе доступа работает для Партнеров.

Если вы используете «Помощник регистрации нового партнера», система одновременно создает и юридическое лицо. Убедитесь, что у пользователя достаточно прав на справочник Контрагенты. Ограничения по группам доступа для контрагентов настраиваются аналогично, но часто для них не требуется такая жесткая сегментация, как для партнеров, по которым ведется управленческий анализ продаж.

Влияние на производительность системы

Рассмотрим техническую сторону вопроса. Использование RLS добавляет к каждому SQL-запросу (при открытии списков, формировании отчетов) дополнительные условия WHERE. Если в базе десятки тысяч партнеров и сотни групп доступа, это может замедлить работу.

Для оптимизации рекомендуется:

• Регулярно обновлять индексы в базе данных SQL.
• Избегать создания сотен индивидуальных профилей — лучше использовать механизм Виды доступа, где настройки определяются «Из группы доступа», как мы разобрали в Шаге 2.
• Следить за тем, чтобы в запросах динамических списков не было избыточных соединений, на которые также накладывается RLS.

Таким образом, мы выяснили, что задача решается стандартными средствами конфигурации без программирования, если правильно скомбинировать настройки профилей и групп доступа с политикой запрета по умолчанию.