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