Добавление новых реквизитов и колонок через механизм расширений конфигурации — стандартная задача разработчика 1С. Однако нередко возникает ситуация: реквизит выведен в форму списка документов, но полнотекстовый поиск по нему не находит нужные данные. Более того, у администратора поиск может срабатывать корректно, а у рядовых пользователей выдавать пустой результат. Давайте разберем эту проблему подробно, выясним архитектурные причины такого поведения платформы 1С:Предприятие и рассмотрим по шагам способы ее решения.
Прежде всего проанализируем разницу между двумя принципиально разными механизмами поиска, которые часто путают конечные пользователи и начинающие разработчики.
Поиск по текущей колонке работает непосредственно с данными динамического списка, используя стандартные механизмы отбора и фильтрации платформы (быстрый поиск, сочетания клавиш Ctrl + F или Alt + F). Если колонка физически присутствует в таблице формы и заполнена данными, отбор по ней срабатывает мгновенно у того пользователя, который установил фокус на эту колонку.
Полнотекстовый поиск (ППД) работает через глобальную строку поиска или общее поле поиска списка. Он обращается не к текущему экранному отображению таблицы, а к специальному служебному полнотекстовому индексу базы данных. Если данные не попали в этот индекс или исключены из него на уровне прав доступа, система вернет пустой результат, даже если значение видно на экране.
Выясним частую причину ошибки при проектировании расширения. Механизм полнотекстового поиска платформы индексирует исключительно те данные, которые физически хранятся в таблицах базы данных.
Если новый реквизит создан только как реквизит управляемой формы или рассчитывается программно (например, в процедуре ПриПолученииДанныхНаСервере динамического списка), платформа не может включить его в полнотекстовый индекс базы данных. Полнотекстовый поиск по таким колонкам принципиально невозможен.
Для того чтобы данные участвовали в полнотекстовом поиске, колонка должна быть связана с реквизитом объекта конфигурации (или реквизитом, добавленным в расширении в сам объект метаданных), а не существовать лишь на уровне формы.
Проверим свойства добавленного реквизита в дереве метаданных расширения:
ПолнотекстовыйПоиск. Убедимся, что для него установлено значение Использовать (или Не определять, если у родительского объекта поиск включен). Если установлено значение Не использовать, платформа полностью игнорирует содержимое поля при построении индексов.Многие разработчики полагаются на стандартное регламентное задание Обновление индексов ППД. Рассмотрим, почему его работы в фоновом режиме часто бывает недостаточно сразу после внедрения расширения.
Фоновое регламентное задание индексирует только те объекты информационной базы, которые были изменены после добавления реквизита (отслеживая записи через таблицу регистраций изменений). Документы, которые уже существовали в базе до применения расширения, не содержат в индексе данных по новому полю. Они попадут туда только после их повторной перезаписи либо после выполнения полной переиндексации.
Разберем по шагам, как принудительно перестроить полнотекстовый индекс:
Проанализируем ситуацию, когда поиск успешно работает у администратора, но не дает результатов у обычных пользователей. Это типичный признак ограничений безопасности.
Когда в расширение добавляется новый реквизит объекта, платформа не назначает на него права автоматически для существующих типовых ролей. Администратор обладает полными правами ко всей базе данных без ограничений, поэтому поиск находит записи. Для обычного пользователя платформа принудительно исключает из выдачи полнотекстового поиска все поля и объекты, на которые у текущего сеанса отсутствуют права Чтение и Просмотр, а также данные, ограниченные механизмами RLS (ограничение на уровне записей и полей).
Для исправления этой проблемы добавим в расширение роль с правами чтения и просмотра нового реквизита и назначим ее пользователям либо включим реквизит в существующие роли расширения.
Строка поиска в динамическом списке по умолчанию ориентируется на видимые и активные колонки формы. Если у пользователя в локальных настройках форма списка была сохранена до обновления, добавленная колонка может оказаться скрытой или некорректно спозиционированной.
Чтобы исключить влияние кэшированных настроек конкретного пользователя, выполним следующие действия:
Таким образом, для гарантированной работы полнотекстового поиска по новому реквизиту из расширения необходимо убедиться, что реквизит принадлежит объекту базы данных, проверить включение свойства полнотекстового индексирования, настроить права доступа для пользователей и выполнить полную переиндексацию ППД.