Как программно установить отбор в табличной части с условием «В списке»?

← На главную

При разработке интерфейсов на платформе 1С:Предприятие 8.3 часто возникает задача ограничения видимости строк в табличной части (ТЧ) формы. Разработчики сталкиваются с тем, что свойство ОтборСтрок элемента формы поддерживает только вид сравнения Равно. Если перед нами стоит задача отфильтровать строки по массиву значений (условие В списке), стандартный механизм оказывается бессилен. Давайте разберем, какие подходы существуют для решения этой технической задачи.

Метод 1: Использование вспомогательного реквизита «Флага»

Это наиболее популярный и простой способ «обхода» ограничений платформы, если объем данных в табличной части не является критически большим. Суть метода заключается в добавлении дополнительной колонки в коллекцию данных формы.

В структуру данных, отображаемых на форме (например, Объект.Товары), добавляем реквизит булевого типа, назовем его ВидимостьСтроки.
При открытии формы обходим коллекцию строк табличной части.
Проверяем каждую строку на соответствие условиям (например, входит ли ссылка в наш массив разрешенных значений).
Устанавливаем значение Истина или Ложь в колонку ВидимостьСтроки.
После обхода коллекции устанавливаем отбор по этому реквизиту.

Посмотрим, как это выглядит программно:


&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
    РазрешенныеСсылки = ПолучитьМассивРазрешенныхСсылок();
    
    Для Каждого СтрокаТЧ Из Объект.Товары Цикл
        Если РазрешенныеСсылки.Найти(СтрокаТЧ.Номенклатура) <> Неопределено Тогда
            СтрокаТЧ.ВидимостьСтроки = Истина;
        Иначе
            СтрокаТЧ.ВидимостьСтроки = Ложь;
        КонецЕсли;
    КонецЦикла;
    
    Элементы.Товары.ОтборСтрок = Новый ФиксированнаяСтруктура("ВидимостьСтроки", Истина);
КонецПроцедуры

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

Метод 2: Замена стандартной табличной части на Динамический список

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

Разберем этапы перехода к этому методу:

Вместо стандартной табличной части Объект.Товары мы создаем на форме ДинамическийСписок.
В качестве основной таблицы динамического списка выбираем таблицу документа (например, Документ.РеализацияТоваровУслуг.Товары).
Настраиваем отбор по Ссылке на текущий документ.
Программно добавляем динамические параметры отбора.

Код для установки отбора в Динамическом списке выглядит значительно чище:


Список.Отбор.Элементы.Очистить();
ЭлементОтбора = Список.Отбор.Элементы.Добавить(Тип("ЭлементОтбораКомпоновкиДанных"));
ЭлементОтбора.ЛевоеЗначение = Новый ПолеКомпоновкиДанных("Номенклатура");
ЭлементОтбора.ВидСравнения = ВидСравненияКомпоновкиДанных.ВСписке;
ЭлементОтбора.ПравоеЗначение = ПолучитьМассивРазрешенныхСсылок();
ЭлементОтбора.Использование = Истина;

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

Метод 3: Использование временной Таблицы значений

Если необходимо избежать изменений в объекте, можно при открытии формы копировать данные табличной части в реквизит формы с типом Таблица значений. В этой таблице можно реализовать любую логику фильтрации, а при необходимости сохранения — переносить данные обратно в основной Объект.

Однако, проанализировав ситуацию, мы понимаем, что этот метод требует сложной синхронизации (обработки событий ПриИзменении, ПередЗаписью и т.д.), поэтому его стоит выбирать только в крайних случаях, когда другие варианты не подходят.

Заключение: Безопасность vs Интерфейс

Напоследок напомним важный момент: все описанные выше методы решают задачу удобства интерфейса и отображения данных для конкретного пользователя. Однако, если ваша цель — ограничение доступа к конфиденциальным данным, помните, что программное скрытие строк на форме не является защитой. Пользователь с достаточными правами всегда сможет получить доступ к данным через отчеты или консоль запросов. Для реального ограничения прав доступа в 1С необходимо использовать механизмы RLS (Record Level Security), настраиваемые в конфигураторе.

Выбирайте метод в зависимости от объема данных и сложности бизнес-логики вашей формы!