← На главную

В процессе настройки прав доступа в конфигурации 1С:Управление нашей фирмой (УНФ) администраторы часто сталкиваются с парадоксальной ситуацией: для того чтобы пользователь мог просто войти в программу, ему необходимо назначить роль Базовые права сервер лояльности. Однако эта роль, вопреки своему названию, предоставляет полные права на добавление и изменение справочников Контрагенты и Физические лица. Попытка отключить эту роль приводит к тому, что система выдает ошибку доступа при запуске и закрывается.

В этой статье мы подробно разберем, почему так происходит, как устроена логика прав в современных типовых конфигурациях и какими способами можно ограничить редактирование данных, не ломая возможность входа в систему. Рассмотрим ситуацию с точки зрения архитектуры Библиотеки стандартных подсистем (БСП) и практических методов администрирования.

Выясняем причину: почему роль становится обязательной для входа

Проанализируем техническую составляющую. На первый взгляд кажется, что права на "сервер лояльности" не должны влиять на базовую возможность запуска приложения. Однако в 1С:УНФ (особенно в версиях ветки 1.6 и ранних 3.0) разработчики включили в состав этой роли права на критически важные системные объекты. Рассмотрим, какие именно объекты могут требовать доступа в момент инициализации сеанса:

1. Параметры сеанса: При запуске система инициализирует множество параметров, связанных с функциональными опциями. Если роль содержит право на чтение параметров, используемых в коде модуля управляемого приложения или модуля сеанса, доступ будет заблокирован.
2. Справочник Идентификаторы объектов метаданных: Это фундаментальный справочник БСП. Если у пользователя нет прав на его чтение, платформа не сможет сопоставить программные идентификаторы с объектами базы данных, что приведет к аварийному завершению работы.
3. Константы и функциональные опции: Подсистема лояльности часто интегрирована в общие механизмы продаж. Даже если флаг «Использовать сервер лояльности» в настройках выключен, программный код может проверять значение этой константы. Отсутствие прав на чтение константы вызывает исключение.

Таким образом, роль Базовые права сервер лояльности в некоторых релизах выступает "контейнером" для прав, необходимых для прохождения процедуры ПриНачалеРаботыСистемы. Это может быть как осознанным решением разработчиков для упрощения структуры ролей, так и технической ошибкой (избыточностью), которую исправляют в более свежих обновлениях.

Почему роль дает полные права на справочники Контрагенты и Физлица

Разберем логику работы сервера лояльности. Данный механизм предназначен для взаимодействия с внешними системами (например, мобильными приложениями или кассами), где требуется быстрая идентификация клиента. Рассмотрим сценарий работы:

Когда покупатель приходит в магазин, система должна найти его по номеру телефона в справочнике Контрагенты. Если клиент не найден, сервер лояльности должен иметь возможность мгновенно создать новую карточку. Именно поэтому в роль заложены права Интерактивное добавление и Редактирование. По задумке разработчиков 1С, подсистема лояльности должна работать бесшовно, не требуя от пользователя переключения между ролями.

Проблема заключается в том, что в 1С права работают по принципу объединения (сложения). Если одна роль (например, "Чтение контрагентов") запрещает изменение, а вторая роль ("Базовые права сервер лояльности") разрешает его — итоговым правом пользователя будет разрешение на изменение. Это и создает "дыру" в безопасности, которую невозможно закрыть стандартными средствами настройки профилей групп доступа.

Способ 1: Проверка функциональных опций и обновление системы

Прежде чем приступать к программированию, проанализируем настройки программы. Иногда "обязательность" роли сохраняется из-за некорректного состояния кэша метаданных после отключения функций лояльности. Рассмотрим последовательность действий:

1. Перейдем в раздел Настройки — Больше возможностей — Продажи.
2. Найдем подраздел Цены и скидки и убедимся, что галочка Использовать сервер лояльности снята.
3. Если галочка была установлена и вы ее сняли, необходимо выполнить регламентные процедуры обновления данных. Перейдем в Обслуживание — Обновление программы — Результаты обновления.
4. Запустим процедуру Запуск процедур обновления и очистка данных. Это позволит системе пересчитать права доступа и, возможно, уберет жесткую зависимость от роли.

Также проверим версию конфигурации. В релизах УНФ 3.0 разработчики проводят активный рефакторинг, разделяя технические права и бизнес-права. Если вы используете старую версию, обновление до актуального релиза может решить проблему автоматически.

Способ 2: Использование расширения для модификации роли

Если обновление не помогает, а роль по-прежнему необходима для входа, наиболее правильным и безопасным методом будет использование Расширения конфигурации. Это позволит нам изменить состав прав роли, не снимая основную конфигурацию с поддержки. Проанализируем алгоритм создания такого расширения:

1. Создадим новое расширение в конфигураторе.
2. Добавим в расширение роль БазовыеПраваСерверЛояльности.
3. Внутри расширения снимем флажки Интерактивное добавление, Редактирование и Изменение для объектов Справочник.Контрагенты и Справочник.ФизическиеЛица.
4. Сохраним расширение и обновим базу данных.

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

Способ 3: Настройка ограничений на уровне записей (RLS)

Если вам требуется не просто запретить редактирование всех контрагентов, а разрешить менять только "своих", рассмотрим использование механизма RLS (Record Level Security). В 1С:УНФ этот механизм включается в разделе Настройки — Администрирование — Настройки пользователей и прав.

Установим флаг Ограничивать доступ на уровне записей. После этого в профилях групп доступа появится возможность детально настроить права по видам доступа (например, по группам доступа контрагентов). Однако помните, что включение RLS в 1С:УНФ может привести к заметному снижению производительности, особенно если база данных работает в файловом режиме или содержит десятки тысяч контрагентов.

Рекомендации по безопасности прав доступа

Подводя итог нашему анализу, дадим несколько практических советов по управлению правами в 1С:УНФ:

1. Минимализм прав: Всегда начинайте настройку с минимального набора ролей. Если система требует роль Базовые права..., всегда проверяйте в конфигураторе, какие именно объекты она открывает.
2. Использование расширений: Не бойтесь использовать расширения для корректировки типовых ролей. Это стандарт индустрии, который позволяет сохранить чистоту основной конфигурации.
3. Аудит изменений: Чтобы понять, кто и когда изменил контрагента (если права все же были предоставлены избыточно), обязательно включите Журнал регистрации и Версионирование объектов.

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