Smart-фильтры: бизнес-логика

Smart-фильтры и smart-выражения — единый слой бизнес-вычислений платформы: настраиваемые условия и формулы, по которым система принимает решения. Smart-выражение возвращает значение, smart-фильтр — «да/нет»; на них держатся автоматизации, проверки прав, видимость элементов интерфейса, значения по умолчанию для ДП, ограничения списка исполнителей и отчётные выборки. Раздел адресован аналитикам и администраторам: что такое smart-выражение, где оно применяется и чем различаются два режима его настройки — визуальный конструктор и ручной T-SQL.

Обзор и доменная модель smart-фильтров

Smart-фильтры и smart-выражения — единый слой бизнес-вычислений в платформе.

• SmartExpression (IsFilter = false) возвращает значение.
• SmartFilter (IsFilter = true) возвращает булев результат.

Они используются в автоматизациях, правах, видимости UI-элементов, дефолтах ДП, ограничениях исполнителей и отчётных сценариях.

Основная сущность

• SmartExpressions — хранит определение выражения, источник (Origin), режим (filter/expression), контент (XML/TSql*).

Два бизнес-режима исполнения

1. Конструкторный режим: XML -> XSLT -> ESQL -> SQL.
2. Ручной режим: прямой TSqlContent.

Выбор режима определяет управляемость и риск:

• XML-режим безопаснее с точки зрения UX и повторного использования.
• T-SQL-режим гибче, но требует строгого контроля качества и прав.

Ключевые бизнес-сценарии и бизнес-правила smart-фильтров

1. Редактирование выражения в visual editor

Администратор собирает формулу из атрибутов доменной модели и сохраняет выражение для дальнейшего использования.

2. Runtime-вычисление

Система вычисляет результат в контексте задачи/пользователя/события и передаёт его в потребляющий домен.

3. Проверка фильтров доступа/видимости

Результат фильтра влияет на:

• доступность действий;
• отбор данных в UI;
• включение/исключение исполнителей и подсказок.

4. Анализ мест использования и аудит смартов

Применение смарт-выражений и фильтров видно из общего списка, без входа в карточку каждого выражения:

• родительский объект и конкретная точка подключения выражения;
• согласованность типов данных — объявленный тип результата против того, что ожидает поле-приёмник;
• быстрый переход к правилу автоматизации по идентификатору правила из таблицы.
• видны все места, включая привязки к настройкам: настройка источника данных лукапа, настройка дополнительного параметра типа «Файл», универсальный шаблон задачи, фильтр рабочего места — эти четыре вида приходят в выдаче начиная со сборки 2.268.

Бизнес-правила

1. Выражение должно быть контекстно совместимо с точкой использования.
2. IsDeleted/невалидный Origin исключают выражение из рабочего контура.
3. Для циклических сценариев (пакетные действия) значения вычисляются с учётом cycle-переменных.
4. Приоритет исполнения: TSqlContent выше автоматически скомпилированного контента.
5. Общее (не личное) выражение может создать только администратор подкатегории или суперадминистратор; у личного выражения владельцем всегда становится его создатель. Доступ выражения задаётся одним из трёх режимов — «Только мне», «Группам», «Всем». Владелец есть только у режима «Только мне» и назначается сервером; в режимах «Группам» и «Всем» владелец не назначается (и очищается, если был). Переданный владелец из запроса не принимается.

Зависимости, роль и операционные риски smart-фильтров

Потребители

• smart-actions
• ext-params
• tasks
• signatures
• grids
• portal

Бизнес-эффект

Домен задаёт единый «язык правил» и снижает необходимость хардкода условий в отдельных модулях.

Операционные риски

• Неверный контекст выполнения (ложные null/пустые результаты).
• Деградация производительности из-за тяжёлых выражений.
• Накопление legacy-выражений с неактуальными зависимостями.

Что проверять при инцидентах

1. Состояние выражения (IsDeleted, Origin, тип).
2. Корректность контекста (ContextID, параметры события, cycle-переменные).
3. Generated SQL и фактическую выборку.
4. Привязку выражения к целевой сущности/настройке.

Связанные документы по smart-фильтрам

• read-data.md