FAQ: миграция видимости ДП с JS-вставок на смарт-фильтры¶
Тип: FAQ для поддержки и администраторов Источник тикетов: «видимость доп параметров», «миграция глобальных js/css вставок»
1. Симптомы¶
Пользователь/администратор спрашивает: - «После обновления интерфейса поля пропали / всегда видны» - «Была JS-вставка, которая скрывала ДП — теперь не работает» - «Как перенести логику видимости из JS в системные механизмы?» - «Где настроить условное скрытие блоков ДП без JavaScript?»
2. Что изменилось¶
Старый подход: JS-вставки (SubcategoriesInclude)¶
- Администратор писал JavaScript-код, который при открытии формы задачи скрывал/показывал элементы по DOM-селекторам
- Хранение: таблица
SubcategoriesInclude(FK →Includes) привязана к категории - Типы:
useForMtf(главная форма) иuseForNewTask(форма создания) - Проблемы: хрупко при обновлении UI, нет серверного контроля, нет аудита
Новый подход: смарт-фильтры на блоках/группах ДП¶
Системный механизм на уровне backend, не зависит от 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 |
| Выполнение | Browser-side (клиент) | Server-side (при загрузке формы) |
| Условия | Произвольный JS | XML SmartExpression → ESQL → TSQL |
| Контекст | DOM задачи | Данные задачи (ДП, состояние, пользователь) |
| Аудит | Нет | Изменения логируются в AdminService |
| Устойчивость к обновлениям UI | Хрупко | Стабильно |
| МТФ/НТФ | Одна логика на оба | Раздельные колонки |
5. Что запросить у клиента¶
- ID категории (SubcatID)
- Текст JS-вставки (или скриншот из AdminSPA)
- Описание ожидаемого поведения: «при каком условии какое поле/блок скрывается»
- ID блоков ДП, которые нужно контролировать
6. Когда эскалировать¶
- Если JS-логика слишком сложна для одного смарт-выражения (каскадные зависимости, множественные условия) → эскалировать на L3 для проектирования набора смарт-выражений
- Если после миграции поведение отличается → L2 (проверка логики смарт-выражения через TestCases)
7. Связанные документы¶
docs/domains/ext-params/backend.md— ExtParamBlocks, валидация, видимостьdocs/domains/ext-params/database.md— таблицы ExtParamBlocks, ExtParamBlocksGroupsdocs/domains/smart-filters/backend.md— пайплайн SmartExpression (XML → ESQL → TSQL)docs/domains/smart-filters/editor-api.md— API редактора смарт-выраженийdocs/domains/categories/admin.md— настройка категорий в AdminSPA