Статистика для дашборда #7
Notifications
Due Date
No due date set.
Blocks
#2 Сделать доработки запрошенные фронтом
EventHub/EventHubBack
Reference: EventHub/EventHubBack#7
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Эндпоинт
GET /v1/admin/statsВозвращает агрегированные данные в зависимости от роли:
superadmin: общее количество пользователей, событий, жалоб, багов; график регистраций/событий по дням.moderator: свои обработанные жалобы/события (количество, статусы).support: количество открытых багов и жалоб, назначенных на текущего.https://git.sabilin.com/EventHub/EventHubBack/raw/branch/master/src/eventhub_app.erl
🎯 Этап 1: Добавление агрегирующих функций в Core-слои
Сначала нужно научить core_user, core_event, core_report и core_ticket быстро считать нужные нам показатели.
src/core/core_user.erl: Добавим функцию count_users/0, которая через mnesia:table_info(user, size) будет возвращать общее количество пользователей.
src/core/core_event.erl: Аналогично, добавим count_events/0 для подсчета всех событий.
src/core/core_report.erl: Потребуется две функции:
count_reports_by_status/1 для подсчета жалоб с определенным статусом (например, pending).
count_reports_by_admin/2 для подсчета жалоб, обработанных конкретным модератором (resolved_by), с определенным статусом.
src/core/core_ticket.erl:
count_tickets_by_status/1 для подсчета открытых багов (open).
count_tickets_by_admin/2 для подсчета багов, назначенных на сотрудника поддержки (assigned_to).
🧩 Этап 2: Расширение бизнес-логики в logic_stats.erl
Создадим новый модуль src/logic/logic_stats.erl (или расширим существующий). Он будет получать на вход роль и UserId и возвращать готовую карту данных.
Для superadmin: вызовет все счетчики (core_user:count_users/0, core_event:count_events/0 и т.д.) и вернет общую статистику.
Для moderator: вызовет функции для подсчета жалоб и событий, обработанных этим администратором.
Для support: вызовет функции для подсчета открытых багов и жалоб, назначенных на этого сотрудника.
⚙️ Этап 3: Адаптация обработчика admin_handler_stats
Теперь модифицируем src/handlers/admin/admin_handler_stats.erl.
В функции get_stats после успешной аутентификации будем получать роль администратора через core_admin:get_by_id(AdminId).
Вместо прямого подсчета в обработчике будем вызывать новый модуль: logic_stats:get_stats(Role, AdminId).
Результат сразу отправим в ответе.
🧪 Этап 4: Написание модульных тестов
Для нового функционала нужно создать test/unit/admin_handler_stats_tests.erl.
Тест 1: Проверка ответа для роли superadmin. Мокаем logic_stats:get_stats/2, чтобы он возвращал #{users => 100, events => 50, ...} и сверяем JSON.
Тест 2: Проверка ответа для роли moderator. Аналогично мокаем ответ и проверяем, что он содержит только свои счетчики.
Тест 3: Проверка для роли support.
Тест 4: Проверка, что не-админ получает 403.
🔄 Этап 5: Обновление интеграционных тестов
В test/api/api_admin_tests.erl уже есть тест Admin stats. Нужно просто убедиться, что он продолжает работать (возвращает 200) и, возможно, добавить проверку структуры JSON для разных ролей.
🧩 Этап 1: Расширение Core-слоёв новыми агрегирующими функциями
Добавим в соответствующие модули функции для получения:
количества новых пользователей/событий за период;
распределения по дням (для графиков);
среднего времени реакции на жалобы/тикеты.
Что потребуется:
core_user.erl: count_users_by_date/2 (количество регистраций по дням в диапазоне).
core_event.erl: count_events_by_date/2 (аналогично).
core_report.erl: count_reports_resolved_by_admin/2, avg_resolution_time/1 (среднее время обработки).
core_ticket.erl: avg_resolution_time/0 (среднее время жизни тикета до закрытия).
core_admin_audit.erl: count_actions_by_admin/2 (количество действий конкретного админа за период).
Все функции должны работать с Mnesia через dirty_match_object и dirty_index_match_object (если есть индексы).
🧩 Этап 2: Развитие logic_stats.erl под ролевую статистику
Расширим существующий модуль logic_stats, чтобы он принимал роль, AdminId и, опционально, параметры периода (From, To). Логика будет следующей:
superadmin: возвращает полную системную статистику + графики (массивы дат со значениями) + активность администраторов (кто сколько действий совершил).
moderator: возвращает количество обработанных жалоб и событий, среднее время реакции, список последних обработанных элементов.
support: возвращает количество открытых/назначенных тикетов и жалоб, персональную нагрузку.
Функция get_stats/2 останется, но будет делегировать к специализированным функциям: build_superadmin_stats/0, build_moderator_stats/1, build_support_stats/1.
🧩 Этап 3: Обновление обработчика admin_handler_stats
Добавим извлечение query-параметров from и to (в формате ISO8601) для задания периода графиков.
После успешной аутентификации и получения AdminId → получим роль через core_admin:get_by_id/1.
Вызовем logic_stats:get_stats(Role, AdminId, Params).
Возвращаем JSON с полной статистикой.
Структура ответа для суперадмина может выглядеть так:
json
{
"users_total": 1234,
"events_total": 567,
"registrations_by_day": [{"date":"2026-04-20","count":12}, ...],
"events_by_day": [...],
"admin_activity": [{"admin_id":"...","email":"...","actions":45}, ...],
"open_tickets": 5,
"avg_ticket_resolution_hours": 2.3
}
🧩 Этап 4: Тестирование
Модульные тесты для новых функций в core_* и logic_stats.
Обновление admin_handler_stats_tests: проверка формата ответа для каждой роли, проверка фильтрации по дате.
Интеграционные тесты: в api_admin_tests добавить запрос /v1/admin/stats с токенами разных ролей и проверить наличие ключевых полей.