Контекст
Нам нужно реализовать раздел «История активности» в профиле пользователя. Это позволит юзеру видеть список своих действий в системе (вступление в команды, создание проектов, изменение статусов задач). Это повышает прозрачность и помогает в навигации по недавним действиям.
Требования
Персонализация: Юзер видит только те действия, которые совершил он сам, либо те, которые коснулись его напрямую (например, его назначили на задачу).
Читаемость (Human-readable): Лог не должен быть дампом БД. Каждое событие должно иметь понятный заголовок: "Вы присоединились к команде X", "Вы создали задачу Y".
Группировка: Возможность фильтрации по типу действия и временному промежутку.
Легкость: Запись лога не должна замедлять работу API.
Что нужно сделать
Database: Доработать таблицу user_activity.
Поля: id, user_id, type (enum), target_id (ID объекта), target_type (Task, Team, Project), data (JSONB для контекста: название команды, слаг), created_at.
Activity Service: Создать сервис-декоратор или хук, который будет дергаться при ключевых событиях в бизнес-логике.
API Endpoint: Реализовать GET /users/me/activity с поддержкой пагинации (Cursor-based или Offset).
DTO: Описать структуру объекта активности так, чтобы фронтенд мог легко подставлять иконки под разные типы (MEMBER_JOINED — иконка юзера, TASK_CREATED — иконка чекбокса).
Критерии приемки
[ ] При совершении действия (например, acceptInvite) в таблицу user_activities падает запись.
[ ] Эндпоинт отдает список событий в обратном хронологическом порядке.
[ ] В JSON ответа приходят данные, достаточные для рендера ссылки: teamSlug, taskTitle и т.д.
[ ] Написаны базовые тесты на сохранение активности.
Контекст
Нам нужно реализовать раздел «История активности» в профиле пользователя. Это позволит юзеру видеть список своих действий в системе (вступление в команды, создание проектов, изменение статусов задач). Это повышает прозрачность и помогает в навигации по недавним действиям.
Требования
Персонализация: Юзер видит только те действия, которые совершил он сам, либо те, которые коснулись его напрямую (например, его назначили на задачу).
Читаемость (Human-readable): Лог не должен быть дампом БД. Каждое событие должно иметь понятный заголовок: "Вы присоединились к команде X", "Вы создали задачу Y".
Группировка: Возможность фильтрации по типу действия и временному промежутку.
Легкость: Запись лога не должна замедлять работу API.
Что нужно сделать
Database: Доработать таблицу user_activity.
Поля: id, user_id, type (enum), target_id (ID объекта), target_type (Task, Team, Project), data (JSONB для контекста: название команды, слаг), created_at.
Activity Service: Создать сервис-декоратор или хук, который будет дергаться при ключевых событиях в бизнес-логике.
API Endpoint: Реализовать GET /users/me/activity с поддержкой пагинации (Cursor-based или Offset).
DTO: Описать структуру объекта активности так, чтобы фронтенд мог легко подставлять иконки под разные типы (MEMBER_JOINED — иконка юзера, TASK_CREATED — иконка чекбокса).
Критерии приемки
[ ] При совершении действия (например, acceptInvite) в таблицу user_activities падает запись.
[ ] Эндпоинт отдает список событий в обратном хронологическом порядке.
[ ] В JSON ответа приходят данные, достаточные для рендера ссылки: teamSlug, taskTitle и т.д.
[ ] Написаны базовые тесты на сохранение активности.