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