В практике разработчика и администратора 1С нередко встречается загадочная ситуация: пользователь пытается найти документ в форме списка (через поиск по номеру или «Показать в списке»), программа находит нужный объект, но при попытке позиционирования выдает системное предупреждение: «Найденный документ не соответствует отбору, установленному в списке. Отключить отбор?». При этом пользователь клянется, что никаких фильтров не ставил, а программист, проверив форму в отладчике, видит, что все элементы коллекции Отбор имеют флаг Использование = Ложь.
В рамках данной статьи мы подробно разберем, почему платформа ведет себя подобным образом, и выясним, где искать «невидимые» фильтры, когда стандартные инструменты проверки говорят, что их нет. Мы проанализируем влияние механизмов безопасности, программных настроек и специфику работы динамических списков.
Проанализируем наиболее частую и «коварную» причину, которая и стала решением в рассматриваемом случае. Механизм Record Level Security (RLS) позволяет ограничивать доступ к конкретным экземплярам объектов (например, документам только по определенной организации).
Ключевой нюанс заключается в различии между правом на «Чтение» и правом на «Просмотр»:
Если у пользователя настроен RLS так, что он может «Видеть» (Просмотр) номер документа, но само условие RLS в роли запрещает «Читать» (Чтение) эту запись в данном списке (например, из-за несоответствия подразделению), возникает конфликт. Поиск платформы отрабатывает по индексам и находит ссылку, но при попытке вывести строку в список запрос динамического списка «отсекает» эту запись. Платформа интерпретирует это как действие внешнего фильтра и выдает стандартное сообщение.
Как проверить: Попробуйте зайти под пользователем с полными правами. Если проблема исчезла — дело однозначно в настройках ролей и шаблонах RLS. Необходимо проверить ограничения на чтение для конкретного объекта метаданных.
Разберем ситуацию, когда программный код формы кажется чистым. Помимо стандартного пользовательского отбора, у элемента формы типа «Список» существует свойство ФиксированныеНастройки.
Фиксированный отбор не отображается в окне «Настройка списка» и его невозможно снять интерактивно. Он часто устанавливается программно при открытии формы или задается непосредственно в конфигураторе в свойствах элемента ТабличноеПоле или Список.
Для диагностики проверим состояние фиксированного отбора с помощью небольшого фрагмента кода в отладчике:
// Проверка наличия скрытых (фиксированных) отборов
Для Каждого ЭлементОтбора Из Список.ФиксированныеНастройки.Отбор.Элементы Цикл
Если ЭлементОтбора.Использование Тогда
Сообщить("Обнаружен скрытый отбор по полю: " + ЭлементОтбора.ЛевоеЗначение);
КонецЕсли;
КонецЦикла;
Если вы обнаружите там активные элементы, значит, ограничение накладывается жестко на уровне кода инициализации формы или настроек метаданных.
Рассмотрим ситуацию, когда форма списка открывается не сама по себе, а как форма выбора из другого объекта. В этом случае на нее могут влиять настройки, заданные в свойствах реквизита, из которого вызывается выбор.
Проверьте в конфигураторе свойства «Параметры выбора» и «Связи параметров выбора». Например, если в документе «Заказ» у поля «Договор» стоит связь по контрагенту, то при открытии списка договоров платформа автоматически наложит невидимый фильтр по владельцу. Если вы попытаетесь найти в этом списке договор другого контрагента, вы получите сообщение о несоответствии отбору.
В старых версиях платформы (8.2, 8.3 в режиме обычных приложений) объект ДокументСписок имеет встроенный механизм управления периодом. Этот период стоит особняком от коллекции Отбор.
Даже если программно все поля Отбор.Использование установлены в Ложь, внутреннее состояние объекта может помнить установленный интервал дат (например, через кнопку «Установить интервал»). Выясним причину, проверив свойства ДатаНачала и ДатаКонца у объекта ДокументСписок. Иногда помогает явный сброс этих значений программно при открытии:
ЭтаФорма.ДокументСписок.ДатаНачала = '00010101';
ЭтаФорма.ДокументСписок.ДатаКонца = '00010101';
Проанализируем ситуацию, когда код исправлен, прав достаточно, но ошибка сохраняется. Платформа 1С сохраняет настройки списков (порядок колонок, видимость, последние фильтры) в системном хранилище. Иногда эти данные повреждаются или «залипают».
Решение:
В обычных формах также помогает удаление файлов из папки %AppData%\1C\1Cv8\ (локальный кэш конфигурации на компьютере пользователя).
Если ваш список построен на произвольном запросе, документ может физически не попадать в выборку из-за логики самого SQL-запроса. Например, если используется ВНУТРЕННЕЕ СОЕДИНЕНИЕ (INNER JOIN) с другой таблицей, и в этой связанной таблице нет соответствующей записи, то основной документ просто «исчезнет» из списка. Попытка позиционироваться на нем приведет к ошибке отбора, так как список «не знает» о существовании такой строки в своей результирующей выборке.
Рекомендуем проверить текст запроса в консоли запросов, подставив ссылку на «проблемный» документ в качестве параметра условия ГДЕ Ссылка = &Ссылка.
Мы рассмотрели основные причины возникновения фантомных отборов. Подведем итог: если вы столкнулись с сообщением о несоответствии отбору при пустых фильтрах, первым делом проверьте права доступа (RLS) и фиксированные настройки списка. В большинстве случаев решение кроется именно в этих механизмах, скрытых от глаз обычного пользователя.