# Позиция 4: Редактирование транзакций и правила категорий

## Цели

- Минимизировать ручной труд при категоризации транзакций.
- Обеспечить возможность "дообучения" системы за счёт действий пользователя.
- Отдельно обработать сложные случаи (маркетплейсы), где по описанию нельзя однозначно определить категорию.

## Редактирование транзакций (SPA)

При открытии истории операций пользователь может открыть карточку редактирования транзакции.

Доступные действия для одной транзакции:

- Изменить категорию (выбор из списка категорий `categories`).
- При необходимости добавить/изменить пользовательский комментарий (`comment`).
- Включить/отключить опцию "Создать правило для похожих транзакций в будущем".

Ограничения:

- Описание операции (`description`) **не редактируется** в SPA, чтобы сохранять оригинальные данные из банка.

Поле `comment` используется только для заметок пользователя и не влияет напрямую на
автоматические правила (на старте).

## Поля в таблице `transactions`

К ранее описанной структуре добавляются поля:

- `is_category_confirmed BOOLEAN NOT NULL DEFAULT FALSE` —
  признак того, что текущая категория транзакции подтверждена пользователем
  (явно или неявно).
- `comment TEXT` — пользовательский комментарий к транзакции.

Рекомендуемый DDL-дельта:

```sql
ALTER TABLE transactions
  ADD COLUMN is_category_confirmed BOOLEAN NOT NULL DEFAULT FALSE;

ALTER TABLE transactions
  ADD COLUMN comment TEXT;
```

## Поведение при редактировании транзакции

При сохранении изменений в SPA backend выполняет:

1. Обновление транзакции:
   - устанавливается новое значение `category_id`;
   - при изменении комментария сохраняется `comment`;
   - поле `is_category_confirmed` устанавливается в `TRUE`.

2. Если опция "Создать правило для похожих транзакций в будущем" включена (по умолчанию включена):
   - создаётся новая запись в `category_rules` или обновляется существующая.

## Создание правил из транзакций

В карточке редактирования транзакции отображается блок "Правило для будущих операций":

- Галочка (переключатель):
  - по умолчанию **включена**;
  - отвечает за то, будет ли на основе текущей транзакции создано/обновлено правило.

- Поле "ключевая строка/шаблон" (pattern):
  - заполняется автоматически (например, ключевым словом из `description`),
    но пользователь может его скорректировать;
  - сохраняется в `category_rules.pattern`.

- Тип совпадения (match_type): на старте можно использовать только `"contains"`.
  - В дальнейшем допускается расширение до `"starts_with"` и `"regex"`.

При сохранении:

- создаётся правило в `category_rules` с полями:
  - `pattern` — строка из формы;
  - `match_type` — тип (на старте `"contains"`);
  - `category_id` — выбранная категория;
  - `priority` — например, по умолчанию 100 для правил, созданных пользователем;
  - `is_active = TRUE`.

Логика приоритета:

- Если для одной транзакции подходит несколько правил, выбирается правило
  с максимальным значением `priority`.

## Особый случай: маркетплейсы

Проблема: по описанию вида "OZON", "WILDBERRIES" и т.п. невозможно
однозначно определить категорию (там могут быть любые товары).

Стратегия (MVP):

- Для маркетплейсов создаются специальные правила, которые:
  - могут присваивать "предполагаемую" категорию (например, "Дом" или
    любую другую, выбранную пользователем);
  - при этом все транзакции, закатегоризированные таким правилом,
    помечаются как `is_category_confirmed = FALSE`.

Результат:

- В истории операций такие транзакции визуально подсвечиваются
  как требующие внимания пользователя.
- Пользователь может:
  - подтвердить категорию (в этом случае `is_category_confirmed` становится `TRUE`);
  - изменить категорию и при желании создать новое правило.

Дополнительно:

- Для маркетплейсов особенно полезно поле `comment`, куда пользователь может
  записать, что конкретно было куплено (например, "корм для Арчи", "мебель", "одежда").

## Применение правил к прошлым транзакциям

В интерфейсе управления правилами (отдельный раздел SPA) для каждого правила
может быть доступна опция:

- "Применить правило к прошлым транзакциям".

При активации этой опции backend:

- находит все транзакции, подходящие под данное правило;
- проставляет им `category_id`;
- устанавливает `is_category_confirmed = FALSE` (категория считается предварительной).

Пользователь может затем:

- отфильтровать операции по `onlyUnconfirmed = true` через `/api/transactions`;
- просмотреть и при необходимости скорректировать категории;
- после ручного подтверждения транзакции становятся `is_category_confirmed = TRUE`.

## Связь с API `/api/transactions`

- Эндпоинт `/api/transactions` возвращает поля `isCategoryConfirmed` и `comment`,
  что позволяет:
  - отображать неподтверждённые категории отдельно (подсветка в UI);
  - предоставлять фильтр "Только неподтверждённые" (`onlyUnconfirmed=true`).

- При редактировании транзакции через отдельный эндпоинт (например, `PUT /api/transactions/{id}`):
  - передаются новые значения `categoryId` и/или `comment`;
  - флаг `isCategoryConfirmed` устанавливается в `true`.