FAQ: миграция видимости ДП с JS-вставок на смарт-фильтры¶
Как перенести логику показа и скрытия блоков ДП с устаревших JavaScript-вставок на штатные смарт-фильтры.
1. Симптомы¶
Пользователь/администратор спрашивает:
- «После обновления интерфейса поля пропали / всегда видны»
- «Была JS-вставка, которая скрывала ДП — теперь не работает»
- «Как перенести логику видимости из JS в системные механизмы?»
- «Где настроить условное скрытие блоков ДП без JavaScript?»
2. Что изменилось¶
Старый подход: JS-вставки (SubcategoriesInclude)¶
Как видимость настраивалась раньше:
- Администратор писал JavaScript-код, который при открытии формы задачи скрывал/показывал элементы по DOM-селекторам
- Хранение: таблица
SubcategoriesInclude(FK →Includes) привязана к категории - Типы:
useForMtf(главная форма) иuseForNewTask(форма создания) - Проблемы: хрупко при обновлении интерфейса, нет серверного контроля, нет аудита
Новый подход: смарт-фильтры на блоках/группах ДП¶
Штатный механизм на стороне сервера, не зависит от JS:
| Уровень | Таблица | Колонки | Что контролирует |
|---|---|---|---|
| Блок ДП | ExtParamBlocks |
HiddenSmartFilterId |
Скрытие блока на МТФ |
HiddenOnNtfSmartFilterId |
Скрытие блока на НТФ | ||
MinimizedSmartFilterId |
Сворачивание блока по умолчанию | ||
| Группа блоков | ExtParamBlocksGroups |
HiddenSmartFilterId |
Скрытие группы |
MinimizedSmartFilterId |
Сворачивание группы |
Каждая колонка — FK на SmartExpressions. Смарт-выражение вычисляется на сервере при открытии задачи и возвращает true/false.
3. Как мигрировать¶
Шаг 1. Определить логику старой JS-вставки¶
Найти JS-вставку в AdminSPA → Категория → Вкладка «Includes» (или через БД: SubcategoriesInclude).
Типичные паттерны:
// Скрыть блок ДП если значение поля = "X"
if (task.extParam_12345 === "X") { $(".ep-block-67").hide(); }
Шаг 2. Создать эквивалентное смарт-выражение¶
Создать SmartExpression с аналогичным условием:
- Если
ExtParam[12345] = "X"→ результатtrue(блок скрыт) - Тип: фильтр (
IsFilter = 1) - Привязка к категории
Шаг 3. Привязать к блоку ДП¶
В AdminSPA → Категория → Настройки блоков ДП → выбрать блок → поле «Скрывать по смарт-фильтру» → выбрать созданное выражение.
Или через БД:
update dbo.ExtParamBlocks
set HiddenSmartFilterId = @smartExpressionId
where ExtParamBlockId = @blockId;
Шаг 4. Протестировать¶
После привязки проверьте оба сценария:
- Открыть задачу с условием → блок должен быть скрыт
- Открыть задачу без условия → блок должен быть виден
- Проверить НТФ отдельно (если нужно, использовать
HiddenOnNtfSmartFilterId)
Шаг 5. Удалить старую JS-вставку¶
После подтверждения — деактивировать/удалить JS-include.
4. Сравнение подходов¶
Ключевые различия двух механизмов:
| Аспект | JS-вставки | Смарт-фильтры |
|---|---|---|
| Хранение | SubcategoriesInclude + Includes |
FK в ExtParamBlocks → SmartExpressions |
| Выполнение | На стороне браузера (клиент) | На стороне сервера (при открытии формы) |
| Условия | Произвольный JS | Смарт-выражение (визуальный конструктор) |
| Контекст | DOM задачи | Данные задачи (ДП, состояние, пользователь) |
| Аудит | Нет | Изменения фиксируются в журнале администрирования |
| Устойчивость к обновлениям интерфейса | Хрупко | Стабильно |
| МТФ/НТФ | Одна логика на оба | Раздельные колонки |
5. Что подготовить для миграции¶
Что понадобится:
- ID категории (SubcatID)
- Текст JS-вставки (или скриншот из AdminSPA)
- Описание ожидаемого поведения: «при каком условии какое поле/блок скрывается»
- ID блоков ДП, которые нужно контролировать
6. Когда обращаться в поддержку 1Ф¶
В некоторых случаях миграцию лучше выполнять при участии поддержки 1Ф:
- Если JS-логика слишком сложна для одного смарт-выражения (каскадные зависимости, множественные условия) — для проектирования набора смарт-выражений
- Если после миграции поведение отличается от ожидаемого — для проверки логики смарт-выражения
7. Связанные документы¶
Смежные разделы:
- Настройка категорий — где настраиваются блоки ДП и смарт-фильтры