Как исправить ошибку «Параметр ОграничениеДоступаНаУровнеЗаписейВключено не существует» после обновления 1С:Бухгалтерии?

После проведения очередного обновления конфигурации «1С:Бухгалтерия предприятия» (начиная с релизов ветки 3.0.71 и выше) администраторы и программисты часто сталкиваются с неприятной ситуацией. Пользователи, обладающие полными (административными) правами, заходят в базу данных без каких-либо проблем. Однако при попытке входа пользователей с ограниченными правами (например, с типовой ролью Бухгалтер (ограничено) или любыми нетиповыми доработанными ролями) система аварийно завершает работу.

На экране появляется критическая ошибка запуска, а в журнале регистрации фиксируется следующее системное сообщение:

{ОбщийМодуль.ОбщегоНазначенияБП.Модуль(705)}: Ошибка при вызове метода контекста (Выполнить)
    Если НЕ Запрос.Выполнить().Пустой() Тогда
по причине:
Ошибка выполнения запроса
по причине:
Ошибка в ограничении доступа к данным.
объект: 'Справочник.Организации', поле: 'Ссылка'; право: 'Чтение'
Синтаксическая ошибка "Параметр ОграничениеДоступаНаУровнеЗаписейВключено не существует"

Давайте подробно разберем, почему возникает эта ошибка, как устроены механизмы безопасности в современных версиях Библиотеки стандартных подсистем (БСП) и рассмотрим несколько практических способов устранения данной проблемы.

Выясняем причину возникновения ошибки

Для того чтобы понять природу сбоя, обратимся к архитектуре подсистемы Управление доступом, которая входит в состав БСП. В конфигурации «Бухгалтерия предприятия» ограничение доступа на уровне записей (известное как RLS — Record Level Security) активно использует параметры сеанса для динамического построения запросов ограничения прав.

В старых версиях БСП для проверки того, включено ли ограничение прав на уровне записей, использовался глобальный параметр сеанса ОграничениеДоступаНаУровнеЗаписейВключено. Тексты ограничений (шаблоны RLS) в ролях содержали конструкции вида:

#Если &ОграничениеДоступаНаУровнеЗаписейВключено #Тогда
...
#КонецЕсли

При обновлении конфигурации до версии 3.0.71 и выше разработчики фирмы «1С» произвели рефакторинг подсистемы управления доступом и обновили версию БСП. В новой версии этот параметр сеанса был полностью удален из метаданных. Вместо него разработчики внедрили новые параметры сеанса:

• ОграничениеДоступаНаУровнеЗаписейИспользуется — пришедший на смену старому параметру.
• ОграничениеДоступаНаУровнеЗаписейУниверсально — отвечающий за работу нового механизма «универсального RLS».

Поскольку старый параметр сеанса прекратил свое существование, любой RLS-запрос, в шаблоне которого осталась инструкция обращения к &ОграничениеДоступаНаУровнеЗаписейВключено, вызывает у платформы синтаксический шок. Платформа 1С:Предприятие пытается скомпилировать SQL-запрос с ограничением доступа для текущей таблицы (например, Справочник.Организации), обращается к несуществующему параметру сеанса и аварийно завершает сеанс пользователя.

Эта проблема затрагивает базы данных, в которых:

1. Используются собственные (кастомные) роли, скопированные ранее из типовых.
2. Типовые роли были изменены программистом и сняты с поддержки (из-за чего при обновлении они не заменились на новые версии из дистрибутива поставщика).
3. Произошел сбой при обновлении конфигурации, либо обновление распределенной информационной базы (РИБ) было выполнено некорректно, и новые обработчики данных не завершили свою работу.

Способ 1. Исправление ролей через глобальную замену (рекомендуемый ручной метод)

Если в вашей конфигурации присутствует большое количество измененных или добавленных вручную ролей, наиболее надежным и быстрым способом будет корректировка текстов ограничений RLS. Мы заменим обращение к старому параметру на новый.

Выполним следующие шаги по шагам:

1. Перед началом любых работ обязательно создайте резервную копию (выгрузку информационной базы .dt или копию файла 1Cv8.1CD).
2. Откройте базу данных в режиме Конфигуратор.
3. В главном меню выберите пункт Правка — Глобальная замена.
4. В открывшемся диалоговом окне настройте параметры поиска следующим образом:
   • В поле Искать: введите &ОграничениеДоступаНаУровнеЗаписейВключено
   • В поле Заменить на: введите &ОграничениеДоступаНаУровнеЗаписейИспользуется
5. В нижней части окна перейдите на вкладку Типы текстов. Обязательно снимите все флажки, кроме пункта Роли (это критически важно, чтобы замена произошла только в шаблонах ограничений прав доступа и не затронула программный код модулей, где логика работы может отличаться).
6. Нажмите кнопку Заменить все. Конфигуратор выполнит поиск во всех ролях конфигурации и произведет автозамену.

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

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

Способ 2. Быстрый «костыль» через расширение конфигурации (без изменения метаданных)

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

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

Реализуем этот метод по шагам:

1. Откройте Конфигуратор, перейдите в меню Конфигурация — Расширения конфигурации.
2. Добавьте новое расширение (например, с именем ИсправлениеОшибкиRLS). Снимите у него флажки Безопасный режим и Активно (сделайте его активным после написания кода).
3. В дереве объектов расширения добавьте новый объект метаданных: Параметры сеанса. Создайте параметр с именем ОграничениеДоступаНаУровнеЗаписейВключено.
4. Установите тип созданного параметра сеанса как Булево.
5. Теперь нам необходимо инициализировать этот параметр при запуске системы. Для этого перейдите в модуль сеанса расширения. Нажмите правой кнопкой мыши на корень дерева расширения, выберите Открыть модуль сеанса.
6. Напишем процедуру-обработчик установки параметров сеанса. Пропишите следующий код:

&После("УстановкаПараметровСеанса")
Процедура Расш1_УстановкаПараметровСеанса(ТребуемыеПараметры, ИменаПараметров)
    
    // Проверяем, инициализирован ли наш параметр сеанса
    Попытка
        ПараметрыСеанса.ОграничениеДоступаНаУровнеЗаписейВключено = Константы.ИспользоватьОграниченияПравДоступаНаУровнеЗаписей.Получить();
    Исключение
        // На случай, если константа недоступна, установим значение по умолчанию
        ПараметрыСеанса.ОграничениеДоступаНаУровнеЗаписейВключено = Ложь;
    КонецПопытки;
    
КонецПроцедуры

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

Способ 3. Переход на универсальные шаблоны ограничений (Best Practice)

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

Разработчики БСП постепенно отказываются от старых громоздких RLS-запросов в пользу Универсального ограничения доступа. Проанализируем, как это сделать:

1. Откройте свойства любой полностью типовой роли в обновленной конфигурации (например, роль ЧтениеОрганизаций).
2. Перейдите на вкладку Шаблоны ограничений. Вы увидите новые шаблоны, которые поставляются вместе с БСП.
3. Обратите внимание на то, как теперь выглядят ограничения для чтения и изменения таблиц. Тексты ограничений стали значительно короче и сводятся к вызову универсальных шаблонов (например, #ПоЗначениям(...)).
4. Вам необходимо открыть свои кастомные роли, скопировать новые шаблоны ограничений из аналогичных типовых ролей поставщика и заменить ими старые тексты ограничений, содержащие обращения к удаленным параметрам сеанса.

Этот способ является наиболее трудоемким, однако он полностью соответствует стандартам разработки фирмы «1С» и гарантирует стабильную работу прав доступа при любых последующих обновлениях БП.

Способ 4. Завершение обновления и очистка кэша

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

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

1. Запустите сеанс под пользователем с полными правами (Администратор).
2. Если обновление зависло, запустите конфигурацию из командной строки с параметром принудительного обновления: 1cv8.exe ENTERPRISE /F "ПутьКВашейБазе" /C ЗапуститьОбновлениеИнформационнойБазы
3. После успешного входа администратора перейдите в раздел Администрирование — Обслуживание — Результаты обновления программы. Проверьте, все ли дополнительные процедуры обработки данных были выполнены успешно.
4. Дополнительно выполните запуск регламентного задания «Обновление прав доступа (оперативное)». Это заставит систему очистить старый кэш ключей доступа и пересчитать ограничения прав для всех пользователей в соответствии с новыми механизмами БСП.

Мы надеемся, что предложенные методики помогут вам быстро диагностировать и устранить проблему с параметрами сеанса RLS, вернув пользователей к комфортной и бесперебойной работе в программе 1С:Бухгалтерия предприятием!