Почему в 1С:Управление торговлей недоступно добавление и изменение контрагентов при настроенном RLS?

При настройке ограничений прав доступа на уровне записей (RLS) в конфигурациях на базе обычных форм (например, Управление торговлей 10.3 или Управление торговлей для Украины 2.3) разработчики и администраторы часто сталкиваются с ситуацией: чтение данных ограничивается корректно, но пользователи полностью теряют возможность добавлять новые элементы и редактировать существующие. При этом в формах списков могут полностью пропадать кнопки командной панели «Добавить» и «Скопировать», даже если у пользователя включены полные права на интерактивное добавление.

Разберем подробно причины такого поведения системы, проанализируем типовые шаблоны запросов RLS и выясним, как восстановить возможность создания и редактирования элементов.

Причина 1. Запуск конфигурации обычного приложения в режиме управляемых форм

Проанализируем интерфейсную сторону проблемы. Конфигурации поколения УТ 10.3 разработаны для работы в режиме толстого клиента (обычное приложение). Если сеанс пользователя запускается под управлением тонкого клиента или в режиме управляемого приложения на платформе 1С:Предприятие 8.3, платформа пытается автоматически сгенерировать управляемые формы списков на лету.

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

1. Проверим режим запуска информационной базы в конфигураторе. Откроем свойства конфигурации и убедимся, что основным режимом запуска является Обычное приложение.
2. В свойствах учетной записи пользователя в конфигураторе проверим значение реквизита Режим запуска. Для типовых конфигураций этого поколения должно быть установлено значение Толстый клиент (обычное приложение).
3. Если запуск выполняется через ярлык или пакетный файл, проверим параметры командной строки. Режим должен явно форсироваться ключом запуска /RunModeOrdinaryApplication.

Причина 2. Особенности шаблона RLS при создании нового элемента с пустой группой доступа

Рассмотрим, как работает типовой шаблон ограничения доступа на уровне записей. В типовых конфигурациях для ограничения прав на справочник Контрагенты используется проверка через регистры сведений НазначениеВидовОбъектовДоступа и НастройкиПравДоступаПользователей.

Посмотрим на типовой текст запроса ограничения прав на чтение и запись:

ТекущаяТаблица ИЗ Справочник.Контрагенты КАК ТекущаяТаблица
    ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
        СоставГруппы.Ссылка КАК ГруппаПользователей
    ИЗ
        Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
    ГДЕ
        СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
    ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
ГДЕ (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ЛОЖЬ
            ИЛИ НЕ 1 В
                        (ВЫБРАТЬ ПЕРВЫЕ 1
                            1 КАК ПолеОтбора
                        ИЗ
                            РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа
                        ГДЕ
                            НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
                            И ВЫБОР
                                КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
                                    ТОГДА ВЫБОР
                                            КОГДА 1 В
                                                    (ВЫБРАТЬ ПЕРВЫЕ 1
                                                        1
                                                    ИЗ
                                                        РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
                                                    ГДЕ
                                                        НастройкиПравДоступаПользователей.ОбъектДоступа = ТекущаяТаблица.ГруппаДоступаККонтрагенту
                                                        И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Контрагенты)
                                                        И (НастройкиПравДоступаПользователей.Пользователь = НазначениеВидовОбъектовДоступа.ГруппаПользователей
                                                            ИЛИ НастройкиПравДоступаПользователей.Пользователь = ЗНАЧЕНИЕ(Справочник.ГруппыПользователей.ВсеПользователи))
                                                        И НастройкиПравДоступаПользователей.Запись = ИСТИНА)
                                                ТОГДА ИСТИНА
                                            ИНАЧЕ ЛОЖЬ
                                        КОНЕЦ
                                ИНАЧЕ ИСТИНА
                            КОНЕЦ = ЛОЖЬ)
                И НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL)

Выясним причину блокировки записи: при создании нового контрагента реквизит ГруппаДоступаККонтрагенту изначально пуст. Если в регистре сведений НастройкиПравДоступаПользователей для текущей группы пользователей не задана явная запись с разрешением на пустую ссылку справочника групп доступа (или не настроена подстановка значения по умолчанию), СУБД блокирует вставку новой строки, так как она не проходит предикат ГДЕ.

Разберем по шагам, как исправить эту проблему в пользовательском режиме:

1. Перейдем в справочник Группы пользователей и откроем форму настроек прав доступа для нужной группы.
2. Убедимся, что для вида объекта доступа Контрагенты добавлена пустая группа доступа с установленным флагом Запись, либо настроим обязательное автозаполнение группы доступа при создании нового контрагента через персональные настройки пользователя.
3. После изменения состава групп или прав в обязательном порядке перезапустим сеанс пользователя, так как параметры сеанса &ТекущийПользователь и служебные структуры кэшируются при входе в программу.

Причина 3. Ограничения дополнительных прав и связанных объектов

Проанализируем еще две распространенные ситуации, когда запись блокируется даже при корректном тексте RLS на справочник Контрагенты:

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

Для программной диагностики доступности прав в модулях конфигурации используем функцию ПравоДоступа:

Если НЕ ПравоДоступа("ИнтерактивноеДобавление", Метаданные.Справочники.Контрагенты) Тогда
    Сообщить("У пользователя отсутствуют права на интерактивное добавление контрагентов!");
КонецЕсли;

Таким образом, комплексная проверка режима запуска приложения (толстый клиент), корректности прав на пустое значение группы доступа в регистре НастройкиПравДоступаПользователей и прав на подчиненные объекты позволяет полностью восстановить добавление и редактирование контрагентов при включенном механизме RLS.