← На главную

После обновления конфигурации 1С:Управление торговлей (редакция 11.5) многие администраторы и разработчики сталкиваются с лавинообразным появлением ошибок в Журнале регистрации. Текст ошибки обычно сообщает о невозможности получения характеристик для различных типов (например, Бизнес-регион, Внешний пользователь, Номенклатура) или о сбое в ограничении доступа к данным для объекта ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения. Ситуация осложняется тем, что ошибки часто сопровождаются пометкой «Задание отменено пользователем», хотя сам пользователь ничего не отменял.

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

Выясним причину: почему ошибки сыпятся «пачками»?

Разберем ситуацию: в современных версиях УТ 11.5 поиск в динамических списках (таких как список номенклатуры или контрагентов) стал «умным» и многопоточным. Когда пользователь вводит запрос в строку поиска, система запускает фоновое задание для фильтрации данных. Это сделано для того, чтобы интерфейс не «зависал» во время сложных запросов. Если в процессе этого фонового выполнения механизм Ограничения доступа на уровне записей (RLS) натыкается на нехватку прав или некорректный шаблон ограничения, фоновое задание аварийно завершается. Интерфейс интерпретирует это как «отмену задания», и в Журнал регистрации записывается целая серия связанных ошибок.

Основные факторы, провоцирующие проблему:

1. Изменение шаблонов RLS: При переходе между минорными версиями (например, с 11.4 на 11.5 или даже внутри веток 11.5.x) фирма «1С» обновляет стандартные шаблоны ограничений в составе Библиотеки стандартных подсистем (БСП). Если в вашей базе есть роли, созданные копированием типовых, или роли в расширениях, их шаблоны остаются старыми и становятся несовместимыми с новым кодом конфигурации.
2. Производительный режим RLS: В УТ 11.5 активно используются вспомогательные таблицы для хранения ключей доступа. Если эти таблицы не обновились после внесения изменений в структуру прав, запросы будут падать с ошибкой.
3. Обращение к ПВХ Дополнительные реквизиты: Динамические списки часто пытаются подтянуть характеристики объектов. Даже если Внешние пользователи у вас отключены, этот тип данных присутствует в метаданных плана видов характеристик, и система пытается проверить права на него при построении дерева характеристик.

Шаг 1: Обновление шаблонов ограничений в расширениях и кастомных ролях

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

Рассмотрим, как правильно обновить шаблоны:

1. Откройте типовую роль, которая служила прототипом для вашей (например, ЧтениеКонтрагентов).
2. Перейдите на закладку «Ограничения доступа».
3. Скопируйте текст из колонки «Ограничение доступа» и текст шаблона на соответствующей закладке.
4. Вставьте эти данные в вашу кастомную роль в расширении.

Важный нюанс: Часто ошибка возникает на объекте Справочник.Контрагенты или Справочник.Партнеры. Убедитесь, что в ваших ролях текст ограничения для права Чтение соответствует актуальному типовому коду. Старые конструкции типа #ПоЗначениям(...) могут работать некорректно, если состав параметров шаблона в конфигурации-поставщике изменился.

Шаг 2: Настройка прав на План видов характеристик

Как показывает практика, явное добавление прав на чтение метаданных часто решает проблему «загадочных» ошибок при поиске. Нам необходимо убедиться, что у пользователя есть право на чтение объекта ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения. Для такой проверки подойдёт обработка для анализа прав доступа на объект базы данных в режиме 1С:Предприятия.

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

1. Создайте новую роль в расширении (например, _ИсправлениеПравПоиска).
2. Дайте этой роли право «Чтение» и «Просмотр» на объект ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения БЕЗ каких-либо условий RLS (пустое поле в ограничениях).
3. Добавьте эту роль в профили групп доступа проблемных пользователей.
4. Аналогично проверьте права на справочник НаборыДополнительныхРеквизитовИСведений.

Шаг 3: Обновление данных доступа (Производительный RLS)

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

Выполним принудительное обновление доступа:

1. Перейдите в раздел Администрирование — Обслуживание — Управление доступом.
2. Найдите гиперссылку «Обновление доступа на уровне записей».
3. Если система сообщает, что обновление не требуется, все равно запустите процедуру пересчета для конкретных пользователей или групп доступа, в которых возникают ошибки.
4. В крайнем случае, можно временно отключить константу Ограничивать доступ на уровне записей, дождаться завершения регламентных заданий и включить её снова. Это спровоцирует полную очистку и перезаполнение вспомогательных таблиц.

Шаг 4: Очистка настроек поиска и кэша

Иногда настройки динамического списка «запоминают» некорректное состояние колонок или параметров поиска, что приводит к ошибке именно у конкретного пользователя. Разберем, как это исправить.

Воспользуемся следующим алгоритмом:

1. Зайдите в Администрирование — Настройки пользователей и прав.
2. Перейдите в Персональные настройки пользователей — Очистка настроек.
3. Выберите проблемного пользователя и найдите настройки для формы Справочник.Номенклатура.Форма.ФормаВыбора или Список.
4. Удалите эти настройки. При следующем открытии формы система заново инициализирует динамический список и дерево характеристик.

Особенности для файловых баз данных

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

Для гарантированного обновления прав доступа в файловой базе рекомендуется запустить сеанс с параметром /AllowExecuteScheduledJobs -Force. Это заставит систему выполнить все регламентные задания, включая Заполнение данных для ограничения доступа, в приоритетном режиме. Убедитесь, что в этот момент в базе нет других пользователей, чтобы исключить блокировки таблиц СведенияОПользователях и КлючиДоступа.

Резюмируем: решение проблемы с «сыплющимися» ошибками RLS в УТ 11.5 требует комплексного подхода. Сначала мы обновляем шаблоны в кастомных ролях, затем обеспечиваем беспрепятственный доступ к ПВХ дополнительных реквизитов, и в завершение инициируем полную перерегистрацию данных доступа в интерфейсе управления программой.