Тип: component · Статус: сведения требуют сверки с действующей установкой; архитектурные правила сформулированы как целевой контракт.

Раздел: Модули Open и их обязанности

Ticket, TicketArchive/List, Comment, Attachment, Event, subscriptions и utilities общего процесса. Тикетный процесс принадлежит Tickets; бизнес-состояние и операции заказа остаются у backend/domain-владельца.

Stage, StageComment, ExternalEvent, связанные заказы, бизнес-артефакты и domain-specific case management.

ST_REQUEST используется для проверки документов/курсов; generic Event фиксирует тикетное событие, но не подменяет результат внешнего провайдера.

• Заказ, Ticket и PROCESS
• ST_REQUEST: запросы документов и проверок

Изменения самой заявки и её предмета записываются структурированными комментариями tickets.change.v1 с прежними/новыми значениями, инициатором или конкретной системной операцией и временем. Текущее бизнес-состояние остаётся у предметного владельца. Исторические записи без доказательств не дополняются выдуманной историей.

NEG_REQUEST и ST_REQUEST относятся к разным событиям и не смешиваются. Пока новая заявка рассматривается, она не заменяет действующее активное отношение. Изменяемые условия отношения фиксируются JSON-вложением на момент составления заявки. Для неизменяемых редакций учитываются их ID/хеши; для редактируемых данных — принятый слепок значений. При архивировании комментарии и события переносятся в лог основного тела с timestamp и инициатором. Этот механизм не следует объявлять криптографической цепочкой или независимой контрольной точкой: такие усиления обсуждались отдельно и здесь не реализованы.

Код подготовлен, серверное применение новой визуализации не подтверждено. Вместо исходного JSON карточка показывает автора/автоматическую обработку, время и изменения «было → стало» с подписями полей и состояний. Пустые авторы не отображаются как None. Владелец модели регистрирует её метаданные через register_subject, владелец вложенного JSON-контракта — register_contract. Общий Tickets не импортирует модель потребителя/опционального модуля и не ищет произвольный объект по ID ради чтения журнала.

В каждой записи доступна кнопка «Скопировать JSON». Для структурированного сообщения копируются его исходные данные; для обычного комментария — JSON с телом, автором и временем. Доступ к буферу запрашивается только по клику. При отказе отображается выделенное readonly-поле для ручного копирования. Неизвестные JSON-схемы получают нейтральное описание и сохраняют исходные данные. HTML/JS внутри JSON не исполняются.

Это read-only представление после обычной проверки доступа к Ticket; GET и копирование не меняют статусы, LDAP, исходный журнал или права. Исторические тексты/прикреплённые слепки не переписываются. Новые модели, миграции и изменение мобильного API для визуализации не требуются. Нужны согласованное обновление Tickets и backend-метаданных, переводы ru/en, collectstatic и обычный restart. Проверены локальные no-DB регрессии, реальная регистрация метаданных, XSS-escaping и clipboard/fallback; это не приёмка произвольной серверной установки.