EventHub/EventHubBack
3
1
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

P1: При регистрации создавать пользователю дефолтный приватный календарь #49

New Issue
Closed
opened 2026-07-20 10:16:38 +03:00 by cursor-ai · 1 comment
cursor-ai commented 2026-07-20 10:16:38 +03:00
Owner
Copy Link
Copy Source

Проблема

После успешной регистрации у нового пользователя нет календаря: его нужно создавать вручную через API. Для клиентского сценария ожидается, что у пользователя сразу есть личное рабочее пространство.

Влияние

Новый пользователь после регистрации/активации не может сразу создавать события и пользоваться календарём без дополнительного шага. Ухудшается onboarding и усложняется клиентская логика.

Ожидаемый результат

При регистрации (или сразу после успешной верификации email — выбрать точку в коде с учётом того, что logic_calendar:create_calendar/3 требует статус active) система автоматически создаёт пользователю один дефолтный приватный календарь типа personal, владельцем которого является этот пользователь.

Рекомендуемая точка: после активации в handler_verify / core_user:update(..., [{status, active}]), либо создание через core_calendar:create/4 в обход проверки active на этапе POST /v1/register — зафиксировать выбранный вариант в реализации и тестах.

Критерии приёмки

  • После успешной регистрации и активации аккаунта у пользователя есть ровно один дефолтный календарь
  • Календарь приватный: тип personal, short_name пустой (без публичной ссылки), владелец — новый пользователь
  • Понятное имя по умолчанию (например, «Мой календарь»; при наличии языка пользователя — с учётом локали)
  • Повторный вызов регистрации/верификации не создаёт дубликаты дефолтного календаря
  • Существующие пользователи без календаря — вне скоупа этой задачи (follow-up при необходимости)
  • Покрыто тестами (API/юнит): поток register → verify → список календарей содержит один дефолтный приватный

Файлы (подсказка)

  • src/handlers/handler_register.erl — регистрация (core_user:create, статус pending)
  • src/handlers/handler_verify.erl — активация аккаунта
  • src/logic/logic_calendar.erl — create_calendar (сейчас требует active)
  • src/core/core_calendar.erl — create/4, create/5, list_by_owner/1
  • test/api/users/user_register_tests.erl
  • test/api/users/user_calendars_tests.erl

Приоритет

P1

## Проблема После успешной регистрации у нового пользователя нет календаря: его нужно создавать вручную через API. Для клиентского сценария ожидается, что у пользователя сразу есть личное рабочее пространство. ## Влияние Новый пользователь после регистрации/активации не может сразу создавать события и пользоваться календарём без дополнительного шага. Ухудшается onboarding и усложняется клиентская логика. ## Ожидаемый результат При регистрации (или сразу после успешной верификации email — выбрать точку в коде с учётом того, что `logic_calendar:create_calendar/3` требует статус `active`) система автоматически создаёт пользователю один дефолтный **приватный** календарь типа `personal`, владельцем которого является этот пользователь. Рекомендуемая точка: после активации в `handler_verify` / `core_user:update(..., [{status, active}])`, либо создание через `core_calendar:create/4` в обход проверки `active` на этапе `POST /v1/register` — зафиксировать выбранный вариант в реализации и тестах. ## Критерии приёмки - [ ] После успешной регистрации и активации аккаунта у пользователя есть ровно один дефолтный календарь - [ ] Календарь приватный: тип `personal`, `short_name` пустой (без публичной ссылки), владелец — новый пользователь - [ ] Понятное имя по умолчанию (например, «Мой календарь»; при наличии языка пользователя — с учётом локали) - [ ] Повторный вызов регистрации/верификации не создаёт дубликаты дефолтного календаря - [ ] Существующие пользователи без календаря — **вне скоупа** этой задачи (follow-up при необходимости) - [ ] Покрыто тестами (API/юнит): поток register → verify → список календарей содержит один дефолтный приватный ## Файлы (подсказка) - `src/handlers/handler_register.erl` — регистрация (`core_user:create`, статус `pending`) - `src/handlers/handler_verify.erl` — активация аккаунта - `src/logic/logic_calendar.erl` — `create_calendar` (сейчас требует `active`) - `src/core/core_calendar.erl` — `create/4`, `create/5`, `list_by_owner/1` - `test/api/users/user_register_tests.erl` - `test/api/users/user_calendars_tests.erl` ## Приоритет P1
cursor-ai added the Story label 2026-07-20 10:16:38 +03:00
cursor-ai self-assigned this 2026-07-20 10:16:38 +03:00
cursor-ai commented 2026-07-20 13:07:35 +03:00
Author
Owner
Copy Link
Copy Source

Готово. Коммит 7c1fe19: после POST /v1/verify вызывается logic_calendar:ensure_default_calendar/1 — идемпотентно создаётся personal-календарь (название из nickname или «Мой календарь»).

Тесты: API user_verification_tests, unit logic_calendar_tests. CI run 366 — зелёный (IFT e2e).

Спека обновлена: EventHubBackSpec.md, EventHubFrontSpec.md.

Готово. Коммит `7c1fe19`: после `POST /v1/verify` вызывается `logic_calendar:ensure_default_calendar/1` — идемпотентно создаётся personal-календарь (название из nickname или «Мой календарь»). Тесты: API `user_verification_tests`, unit `logic_calendar_tests`. CI run 366 — зелёный (IFT e2e). Спека обновлена: `EventHubBackSpec.md`, `EventHubFrontSpec.md`.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Bug
Дефект или ошибка
 Bug
Дефект или ошибка
 Bug
Дефект или ошибка
 Epic
Крупная инициатива / эпик
 Epic
Крупная инициатива / эпик
 Epic
Крупная инициатива / эпик
 Future
Отложенная работа
 Future
Отложенная работа
 Future
Отложенная работа
 Story
Пользовательская история
 Story
Пользовательская история
 Story
Пользовательская история
 Task
Техническая задача
 Task
Техническая задача
 Task
Техническая задача
No Label Story
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aleksey ci-builder cursor-ai deep-seek
No Assignees cursor-ai
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: EventHub/EventHubBack#49
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?