Dev Specs

Epic E05 — Issues [desktop]

Назначение эпика: регистрация инцидентов по юниту (поломка/проблема в комнате или infrastructure-item) и их обработка — от заведения issue до связанной maintenance-задачи. Глобальный реестр инцидентов через модуль Tasks (вкладка Issues) + детальная карточка issue. Участвует в use-cases: UC-3 (Issue → linked maintenance Task → Maintenance Report). Сущности (owns/touches): owns Issue; touches Task (linked maintenance task), Unit, UnitArea/Room, InfraItem, Employee (reported by), Department/SubDepartment, Attachment. Экраны: S15 (Issues list — вкладка модуля Tasks), S40 (Issue detail). Открытые findings: F (issues-req-and-not-req) — обязательность issues; F (filter-hierarchy-assignee) — каскад фильтров department→cluster→assignee; F (placeholder-copy) — лейблы-заглушки в каталоге.


S15 — Issues list [desktop]

  • Назначение: глобальный реестр инцидентов всех юнитов с фильтрами и переходом в карточку issue; живёт внутри модуля Tasks как вкладка рядом с All Tasks.
  • Источник (Miro): «Copy of Copy of Copy of Templates» id 3458764672845971639 (1×). Заголовок раздела Tasks, вкладки All Tasks / Issues; контролы input_button×5 (вкладки + fast filters/filters), input_text×1 (поиск).
  • Layout: header (заголовок Tasks) → tab-bar (All Tasks · Issues) → панель fast filters + filters → data-table issues. Detail открывается на S40 (отдельный экран; в каталоге S40 без drawer-контролов — full-page detail).
  • Данные на экране (колонки таблицы, дословно):
    • ID — порядковый/issue id (1, 2, 3).
    • Unit — юнит (Alaya).
    • Issue — имя инцидента (AC Maintenance, Check Wifi, Plumbing Repair).
    • Description — краткое описание.
    • Reported at — дата (22/05/2026).
    • DepartmentOperations.
    • Sub DepartmentMaintenance, Maintenance Issue, Direct.
    • Reported bySarah Martinez.
    • Linked Task — связанная задача (AC Maintenance, Direct, Operations).
    • Linked Task Status — статус связанной задачи.

    Замечание: в строках каталога встречаются также Cleaning / AC Maintenance / Inspection (fast-filter чипы) и Property Services / Owner Services / Vendors / Accounting — это значения фильтров department/subdept, не отдельные колонки.

  • Контролы и действия:
    • All Tasks (button/tab) → переключение на вкладку всех задач (эпик E03).
    • Issues (button/tab) → текущая вкладка (активна).
    • fast filters (filter) → быстрые чипы: department/subdept/issue-type (Cleaning, AC Maintenance, Inspection).
    • filters (filter) → расширенная панель: department, sub department, reported by (+ unit, reported at диапазон 🟡).
    • поиск (input_text) → текстовый фильтр по Issue/Description.
    • клик по строке → открыть S40 (Issue detail).
    • Linked Task (ссылка в строке) → открыть связанную задачу (эпик E03), если задача создана.
  • Состояния/вкладки: вкладки All Tasks/Issues; filtered (по department/subdept/reported-by); empty (нет инцидентов под фильтром); loading; error. Состояние строки: issue без linked task (Linked Task пусто) vs с задачей (статус виден в Linked Task Status).
  • Связи (data-flow):
    • читает: Issue (+ Unit, Department/SubDepartment, Employee reported-by, связанный Task для Linked Task/Linked Task Status).
    • источники инцидентов: заведены на S40, либо из вкладки Issues карточки юнита (S17, эпик E01), либо в ходе исполнения задачи (mobile, эпик E04).
    • уходит: клик → S40; Linked Task → задача в E03; зарегистрированный issue со связанной задачей стекает в Maintenance Report (S24, эпик E06) как строка Issues.
  • Мутации: нет прямых на этом экране (read/filter/navigate). Создание/правка — на S40.
  • Права: Operations/Coordinator — полный список своих department-scoped юнитов. Accounting/Owner Services — read. Field staff — не видят desktop-реестр (их issues — через mobile-исполнение).
  • 🟡 [не было додумано]: (1) колонки Linked Task + Linked Task Status в каталоге названы, но содержимое строк — заглушки; принял, что Linked Task = ссылка на Task, Linked Task Status = task status-чип (Planned/New/In Progress/Finished). (2) Размещение вкладки Issues внутри модуля Tasks (а не отдельным top-level) — следует tab-bar каталога. (3) Фильтр reported by — выведен из колонки (в каталоге как лейбл фильтра не зафиксирован явно).
  • Edge cases: empty — «No issues»; issue без linked task — Linked Task/Linked Task Status пустые (это валидно: не каждый issue порождает задачу — см. UC-3); длинные Description — усечение с тултипом; нет прав на юнит — строка не в выборке (object-level default-deny); каскад фильтров неоднозначен — см. F (filter-hierarchy-assignee).

S40 — Issue detail [desktop]

  • Назначение: карточка одного инцидента — полная атрибутика + вложения + связь с maintenance-задачей.
  • Источник (Miro): «Copy of Copy of Copy of Copy of Templates» id 3458764672846665942 (1×). controls: — (в каталоге кнопки не размечены, кроме текстовой + add attachment) → трактуем как read/detail-view с инлайн-добавлением вложения.
  • Layout: header (Issue + issue_id 120324, Reported at, Unit) → форма-карточка полей (две колонки) → блок Linked Task → блок Attachments.
  • Данные на экране (поля, дословно):
    • issue_id120324.
    • UnitVilla Alaya.
    • Reported at11:00 12 May 2026.
    • Department:Operations.
    • Reported by:Sarah Martinez.
    • Subdepartment:Maintenance.
    • Issue Name:AC Maintenance.
    • Room: — комната/area юнита.
    • Description: — текст.
    • Infrastructure Item: — связанный infra-item (опционально; см. E01 Infrastructure).
    • Priority:Standard (+ 🟡 шкала ниже).
    • Linked Task: — связанная maintenance-задача.
    • Attachments: — список файлов/фото + + add attachment.
  • Контролы и действия:
    • + add attachment (button) → загрузить файл/фото к issue (мутация: append Attachment).
    • Linked Task (ссылка/значение) → открыть связанную задачу (E03), либо + create task если не создана 🟡 (UC-3: issue порождает linked maintenance Task).
    • Room / Infrastructure Item / Subdepartment / Priority (dropdown при редактировании 🟡) → правка атрибутов.
    • Description (input) → правка текста.
  • Состояния/вкладки: read (просмотр) / edit (правка полей) 🟡; Linked Task — пусто vs привязана (со статусом); Attachments — empty vs список; loading/error.
  • Связи (data-flow):
    • читает: Issue (+ Unit, UnitArea/Room, InfraItem, Department/SubDepartment, Employee, Attachment, связанный Task).
    • источники: создаётся отсюда, либо из вкладки Issues карточки юнита (S17, E01), либо из mobile-исполнения (E04).
    • уходит: создание linked task → Task (E03), которая при Finished стекает в Maintenance Report (S24, E06).
  • Мутации: create/update Issue (атрибуты, description, priority, room, infra-item); append/remove Attachment; create linked Task (transition: issue → linked maintenance task) 🟡.
  • Права: Operations/Coordinator своего department — create/update + создание задачи. Accounting/Owner Services — read. Vendors — read назначенного 🟡 (F filter-hierarchy-assignee).
  • 🟡 [не было додумано]:
    • Edit-режим и create-task action — в каталоге S40 контролов нет (кроме + add attachment); чтобы экран был функционален в UC-3, добавлены: правка полей и кнопка создания связанной задачи. Обоснование: без них issue нельзя завести/связать — это назначение эпика.
    • Priority шкала — в данных только Standard; предполагаю набор Low / Standard / High / Urgent (electric-green→amber→red токены). Подтвердить у заказчика.
    • Required флаг (F issues-req-and-not-req) — sticky-note «issues both req and not req»; семантика (photo-required? task-required?) не определена → поле не вводим в скелет, помечаем как открытый вопрос.
  • Edge cases: issue без linked task (валидно, UC-3 — не каждый issue → задача); attachment загрузка fail → inline-ошибка, issue сохраняется; Infrastructure Item/Room пустые (issue не привязан к конкретному infra-item); длинный Description — скролл; нет прав → read-only.

Cross-screen relations (внутри эпика)

S15 (Issues list) ──клик по строке──► S40 (Issue detail)
S15 «Linked Task» ──────────────────► Task (E03) [если создана]
S40 «+ create task» ────────────────► Task (E03)  [UC-3]
S40 «+ add attachment» ─────────────► Attachment (append)

Cross-epic relations (НЕ пере-специфицируется здесь)

  • S06 / S17 — вкладка Issues внутри карточки юнита (эпик E01). S17 — тот же реестр инцидентов, но scoped к одному юниту (колонки Issue, Description, Reported at, Department, Associated Task, Task Status, Task Report). S15 = глобальный надмножество того же Issue-набора. Спецификация карточки юнита и её вкладок — в E01.
  • S24 — Maintenance Report, вкладка Issues (эпик E06). Issues месяца по юниту с колонками Associated Task / Task Status / Task Report / Report Status. Спецификация компиляции отчёта — в E06.
  • Ключевая связь (UC-3): Issue (S40) → создаёт linked maintenance Task (E03) → задача исполняется (mobile, E04) → при Finished строка issue+task стекает в Maintenance Report (S24, E06) и попадает в месячную отчётность по юниту. Колонки Linked Task/Linked Task Status (S15) и Associated Task/Task Status/Task Report (S17/S24) — проекции этой же связи на разных уровнях scope.

Решения заказчика (2026-06-22)

Ответы со встречи Akira × Sergey (реестр 00-client-questions.md). Перекрывают соответствующие 🟡-допущения ниже.

  • Q-08 · required/not-required — РЕШЕНО (resolves finding issues-req-and-not-req): «required/not-required» относится НЕ к флагу на issue, а к типу темплейтаInspection vs Task (детали — E02-решения). Issue авто-создаётся из пункта инспекции с ответом «нет» (Auto Issues). Отдельный «required»-флаг на сущность Issue в скелет не вводим — вопрос закрыт через тип темплейта.
  • Q-09 · priority (S40 Priority) — РЕШЕНО: шкала Low / Standard / High / Emergency, дефолт Standard. Urgent → Emergency. Единый enum с E03. → Tier B U1.

Дозумано на уровне эпика 🟡

  • Edit/create-task контролы на S40 — в Miro у S40 размечен только + add attachment; для замыкания UC-3 добавлены правка полей и создание связанной задачи. Минимальное отклонение, без него эпик нефункционален.
  • Linked Task / Linked Task Status семантика — трактованы как ссылка на Task + его status-чип; содержимое в каталоге — заглушки (F placeholder-copy).
  • Priority набор значений — выведен (только Standard в данных); подтвердить.
  • Фильтры S15 (department / sub department / reported by) — выведены из колонок и общей конвенции fast-filters/filters; каскад department→cluster→assignee — открытый F (filter-hierarchy-assignee).
  • Required-флаг issue (F issues-req-and-not-req) — намеренно НЕ внесён в скелет полей до прояснения семантики.