PRD: восстановление и развитие Service Desk Artron

Версия 0.1, 19.10.2026. Статус: проект требований для согласования с владельцами Service Desk. Этот документ описывает будущие изменения; production в рамках аудита не менялся.

1. Проблема, цель, границы

Сейчас клиент создаёт обращение по договору и объекту обслуживания, сотрудник назначает инженера, фиксирует реакцию и решение, ведёт историю, закрывает заявку; руководитель смотрит списки и статистику. Поток ценен, но неавторизованный обычный вход отвечает 500, изменяющие маршруты недостаточно защищены в собственном коде, экспорт ссылается на отсутствующую библиотеку, интерфейс перегружен таблицами и фильтрами. Подробнее: аудит, карта процессов.

Цель продукта: пользователь за 1–2 минуты понимает состояние своего обращения и следующий шаг; сотрудник видит очередь по SLA и может безопасно выполнить работу; права, история и сроки сохраняют корректность при обновлениях.

Результат первой программы работ: восстановлен вход и экспорт, все изменения проходят единый серверный контроль; ключевые процессы покрыты проверками; новый интерфейс внедрён по ролям без потери старых данных и ссылок.

В границах: клиентский кабинет, рабочее место менеджера/администратора, карточка и создание обращения, уведомления, SLA, экспорт, статистика, QR-вызов инженера, интеграционные контракты в части Service Desk.

Вне первой программы: замена общей установки Битрикс, полная миграция данных в иную платформу, изменение правил 1С и CRM без владельца интеграции, удаление исторических данных, переработка других сайтов Artron. Это отдельные решения после инвентаризации.

2. Пользователи и задачи

Роль	Основная задача	Что нужно в интерфейсе
Клиент/заявитель	Описать проблему и понять статус	Простое создание, договор/объект с понятными названиями, текущий статус, следующий шаг, сообщения
Менеджер Service Desk	Разобрать очередь и не пропустить SLA	Очередь с приоритетом, фильтр по закреплённым договорам, назначение, история и уведомления
Инженер	Получить контекст выезда и зафиксировать работу	Мобильная карточка с оборудованием, адресом и разрешёнными действиями
Администратор	Контролировать договоры, показатели и доступ	Все разрешённые данные, аудит изменений, экспорт, правила уведомлений
Руководитель/аналитик	Оценить загрузку и нарушения сроков	Сводка по соглашениям, динамика и причины просрочек с датой обновления

Фактическая матрица полномочий менеджера и инженера требует подтверждения владельцем процесса; код различает группы 16 и 17 и UF_SERVICEDESK/UF_CLIENT, но смысл каждой операции должен быть формализован.

3. Пользовательские сценарии и измеримая приёмка

Все AC проверяются на тестовой копии с обезличенными договорами, несколькими ролями и фиксированным календарём, затем smoke на production без изменяющих сценариев до окна выпуска. Полный список тестов — TEST_PLAN.md.

ID / приоритет	User story и требование	Критерии приёмки
R-01 / P0	Как неавторизованный пользователь, я открываю обычный URL и вижу вход	`GET /` и защищённые страницы возвращают страницу входа/корректный редирект без HTTP 500; после входа пользователь попадает в разрешённый раздел; ссылка выхода завершает сеанс.
R-02 / P0	Как владелец заявки, я могу изменить только свою заявку; как сотрудник — только разрешённую	Каждая команда требует POST, валидный sessid, авторизацию, роль и проверку договора/владения объектом; чужой ID, чужой договор, неразрешённое поле, GET и просроченный sessid дают 403/422 без изменения заявки, истории и уведомлений.
R-03 / P0	Как клиент, я создаю заявку по доступному соглашению	Сервер проверяет активность и принадлежность договора, связь объекта с ним и обязательные поля; подмена ID не создаёт заявку; два параллельных создания получают разные номера; при сбое истории/заявки не остаётся частичной записи.
R-04 / P0	Как сотрудник, я последовательно веду статус и закрываю заявку	Переходы статусов определены таблицей переходов; запрещённый переход возвращает понятную ошибку; повтор отправки не создаёт второго изменения/уведомления; закрытие записывает код, автора, время и историю один раз.
R-05 / P0	Как пользователь, я доверяю срокам реакции и решения	Для утверждённого набора не менее 30 примеров (график, выходные, праздники, граница смены, перенос, часовой пояс) новый расчёт совпадает с согласованным ожидаемым результатом; на старых заявках дата не меняется без отдельного бизнес-решения.
R-06 / P1	Как клиент, я вижу ясный список и карточку	Список показывает номер, тему, статус, объект, последний шаг, сроки; карточка отдельно показывает историю, сообщения и доступные действия; на 1366px основные действия и статус видны без горизонтальной прокрутки, на 390px нет обрезанных кнопок/текста.
R-07 / P1	Как сотрудник, я нахожу приоритетную заявку	Поиск по номеру, фильтры статус/соглашение/SLA/инженер имеют видимые активные значения и кнопку сброса; результаты, счётчик и URL/сохранённый фильтр согласованы; тестовый набор 3000 заявок открывается не более чем за 3 секунды по p95 на согласованной среде.
R-08 / P1	Как пользователь, я получаю нужное уведомление	Матрица событий/получателей утверждена; одно событие отправляется не более одного раза каждому получателю; ошибки доставки регистрируются с возможностью повтора; настройки уведомлений меняются только по авторизованному POST с sessid.
R-09 / P1	Как сотрудник, я экспортирую отфильтрованный список	XLSX скачивается с корректным MIME/именем, открывается табличным редактором, содержит только разрешённые и видимые по фильтру записи; даты/номера сохраняют формат; тесты 0, 50 и 3000 строк проходят без 500.
R-10 / P1	Как руководитель, я вижу достоверную статистику	Сводка показывает период, время обновления, открытые/просроченные обращения и исходные фильтры; числа сверяются с контрольной выборкой БД; неудачный фоновый запуск выдаёт событие мониторинга, а не тихую пустую таблицу.
R-11 / P1	Как инженер, я открываю QR/ссылку и фиксирую разрешённое действие	Код не раскрывает лишние данные, имеет срок/область действия, однократность либо защиту от повторов; запись времени выполняется только POST после подтверждения; недействительный/отозванный код не изменяет данные.
R-12 / P1	Как администратор интеграции, я безопасно обслуживаю CRM и 1С	Секреты хранятся вне исходников и логов, TLS проверяется, ошибки REST видны в мониторинге; документированы владелец, вход/выход, формат, периодичность и повтор обмена; тестовый сбой не создаёт дубликатов.
R-13 / P2	Как пользователь, я понимаю сообщения об ошибках	Валидация указывает поле и действие исправления; пустой список отличает отсутствие заявок от нулевого результата фильтра; успех создания/закрытия подтверждается номером и ссылкой, без вывода технического PHP текста.

4. Дизайн и информационная архитектура

Навигация первого уровня: Очередь/Мои обращения, Создать обращение, Статистика (если роль позволяет), Уведомления. Карточка состоит из заголовка с номером и статусом, блока «Что дальше», SLA с двумя сроками и явной шкалой, оборудования/договора, переписки/истории, разрешённых действий. В создании показывать выбор договора → объекта → описание/тип → проверку перед отправкой; при отсутствии объекта дать ясный вариант обращения по договору. Для менеджера таблица начинается с 6–8 полезных колонок, остальные в настройке вида/карточке. Цвет статуса всегда дублируется текстом; ошибки доступны с клавиатуры и озвучиваются.

Локальные интерактивные концепты демонстрируют структуру и поведение на синтетических данных. Это предложение, а не утверждённый дизайн. Перед реализацией провести 5 коротких проверок задач с клиентом и менеджером; измерить: создание без подсказок ≥ 4/5, поиск нужной заявки ≤ 30 секунд у ≥ 4/5, понимание следующего шага ≥ 4/5. Контраст текста ≥ WCAG AA, клавиатурный путь по основным действиям без ловушек.

5. Архитектура целевого решения

Сохранить Битрикс и инфоблоки на первом этапе. В /local/ создать слой команд (CreateTicket, UpdateTicket, CloseTicket, RecordEngineerTime), единую политику доступа, репозитории данных и сервис SLA. Публичные URL служат тонкими контроллерами с POST/sessid/валидацией. История и изменение заявки выполняются атомарно; уведомление уходит после успешного commit через очередь/надёжное событие с idempotency key. Чтение списка и карточки отделено от команд. Структуру ID описать в конфигурации/миграциях и валидировать при развёртывании; не менять ID вручную в production. Новые классы и шаблоны размещать в /local/, ядро /bitrix/ не изменять.

Логирование: request ID, действие, actor ID, ticket ID, результат, ошибка без текста обращения и секретов. Мониторинг: 5xx, ошибки cron/очереди/REST, длительность списка, число просроченных событий уведомлений. Доступ к логам ограничить.

6. Последовательность работ и критерии выпуска

Этап	Объём	Выходной артефакт и gate
0. Подготовка	Владелец правил, тестовая копия и обезличивание, карта 1С/CRM, базовые метрики, резервная копия/план отката	Утверждены матрица ролей, состояния, SLA-примеры и перечень интеграций; тестовая среда повторяет релевантные версии PHP/Битрикс
1. Стабилизация	Вход/500, защита всех изменяющих маршрутов, секрет/TLS, удаление/закрытие служебных URL после оценки, номера/атомарность	Проходят R-01–R-05, R-12 security checks; регрессия общих сайтов и авторизованных ролей без критических дефектов
2. Надёжность	Экспорт, статистика/cron, уведомления, наблюдаемость	Проходят R-08–R-10; контрольная рассылка и сверка статистики на тестовом окружении
3. UX	Списки, карточка, создание, мобильный экран инженера, доступность	Проходят R-06, R-07, R-11, R-13 и короткая проверка задач; выкладка по ролям с возможностью возврата прежнего шаблона
4. Упрощение кода	Вынос SQL и доменной логики, удаление дублей/мёртвых веток, решение по неустановленному модулю	Профилирование и регрессия подтверждают отсутствие изменения бизнес-правил и ухудшения p95

Оценки сроков возможны только после этапа 0: правила SLA и обменов пока не определены, а общая установка требует координации с владельцами соседних сайтов. Нельзя считать страницу «готовой» по HTTP 200: проверяются экран после входа, роль, изменяющий сценарий в тестовой среде, история, уведомление и повтор.

7. Миграция, риски и решения

Общая установка: изменения shared local/php_interface/sd и шаблонов разворачивать с регрессией других сайтов и планом отката. Релиз по небольшим пакетам.
Исторические данные: не переписывать SLA задним числом; новые структурные поля вводить как добавочные, старое описание/историю читать через адаптер. Перед изменением схемы сверить числа элементов и связи.
Интеграции: 1С и CRM имеют собственных владельцев. Изменение формата/ключа только после контракта, стенда и согласованной ротации; повторная обработка идемпотентна.
Доступ: при ужесточении проверить существующие автоматические клиенты/QR и обеспечить разрешённую замену, иначе могут прерваться операции инженеров.
Дизайн: тестировать реальные задачи до финальной верстки, включить возможность поэтапного переключения без разрыва привычных ссылок.

8. Открытые продуктовые решения

Кто является владельцем обращения: автор, все пользователи договора или оба? Какие операции доступны каждому?
Каковы утверждённые статусы, переходы и коды закрытия; может ли клиент закрывать и переоткрывать?
Какие календари и часовые пояса применяются по договорам; пересчитывается ли SLA после изменения договора/типа/даты?
Кто отвечает за актуальность договоров/оборудования из 1С, а кто за согласование CRM-заявки из QR?
Какие уведомления обязательны, какие можно отключать, какой срок доставки считается допустимым?

До ответов эти правила нельзя произвольно «улучшить» кодом: сначала зафиксировать решение и контрольные примеры.

Продуктовые требования