Контекст
Сейчас у нас есть два режима тикетов — анонимный и неанонимный. Это основная причина сложности и множества веток в логике (owner_hash, guest‑доступ, разные read‑status, SG‑роль «как студент» и т.д.).
Факт: в базе сейчас 12 анонимных тикетов и 1 неанонимный — де‑факто продукт уже почти полностью анонимный.
Проблема
Требование поддерживать оба режима сильно усложняет архитектуру и поддержку. Любая правка должна учитывать 3–4 сценария доступа.
Предложение
После этапа адопшна выбрать один режим как основной:
- ✅ Только анонимные (сильное УТП приватности);
- ✅ Только неанонимные (проще контроль, меньше рисков).
Это упростит код, снизит вероятность багов и ускорит развитие. Сейчас логика уже заточена под анонимный режим — возможно, это более естественный выбор.
Нужно обсудить
- Какой режим фиксируем как единственный?
- Какие критерии/риски важнее (приватность, контроль, юридические риски и т.п.)?
Результат
Зафиксированное решение (one‑mode) + список последующих технических задач по упрощению логики.
Контекст
Сейчас у нас есть два режима тикетов — анонимный и неанонимный. Это основная причина сложности и множества веток в логике (owner_hash, guest‑доступ, разные read‑status, SG‑роль «как студент» и т.д.).
Факт: в базе сейчас 12 анонимных тикетов и 1 неанонимный — де‑факто продукт уже почти полностью анонимный.
Проблема
Требование поддерживать оба режима сильно усложняет архитектуру и поддержку. Любая правка должна учитывать 3–4 сценария доступа.
Предложение
После этапа адопшна выбрать один режим как основной:
Это упростит код, снизит вероятность багов и ускорит развитие. Сейчас логика уже заточена под анонимный режим — возможно, это более естественный выбор.
Нужно обсудить
Результат
Зафиксированное решение (one‑mode) + список последующих технических задач по упрощению логики.