Интеграция

mxBoard универсален: ядро не знает ни про какие боты и трекеры. Всё, что специфично для вашей инсталляции, вешается плагином на события mxBoard и хранится в произвольном поле meta у карточки.

События

Пакет регистрирует системные события MODX. Плагин интегратора подписывается на нужные и получает данные карточки.

Событие	Когда	Доп. параметры
mxbOnTaskCreate	задача создана	channel
mxbOnBeforeTaskMove	перед переходом (можно вмешаться)	channel, целевая колонка
mxbOnTaskMove	карточка перемещена	channel, from, to
mxbOnTaskClose	карточка закрыта (вход в финальную колонку)	channel
mxbOnTaskComment	добавлен комментарий	channel, comment
mxbOnTaskUpdate	карточка отредактирована	channel
mxbOnTaskDelete	карточка удалена	channel
mxbOnDeadlineDispute	дедлайн оспорен	channel, proposed, reason
mxbOnDeadlineResolve	оспаривание дедлайна разрешено	channel, accepted
mxbOnPlanDispute	плановая трудоёмкость оспорена	channel, proposed, reason
mxbOnPlanResolve	оспаривание плана разрешено	channel, accepted
mxbOnTaskTake, mxbOnTaskRelease	зарезервированы (в v2 захвата нет — исполнитель назначается при создании)	—

События плана — с версии 2.8.1-pl

mxbOnPlanDispute и mxbOnPlanResolve вызываются с 2.8.0-pl, но зарегистрированы в MODX только с 2.8.1-pl: на 2.8.0-pl их не было в списке событий, и плагин на них повесить не получалось. Если оспаривание плана нужно интеграции — обновите пакет.

Каждый вызов события передаёт в плагин: task_id, task (все поля карточки массивом), user_id и перечисленные выше доп. параметры. channel — канал запроса: mgr (менеджер), api (REST), mcp (агент).

Подсказка

Исключение в плагине не роняет доску: кривой плагин интегратора логируется, но не срывает операцию.

Пример плагина

<?php
// Плагин на событие mxbOnTaskCreate — толкнуть уведомление во внешнюю систему.
use MODX\Revolution\modX;

if ($modx->event->name !== 'mxbOnTaskCreate') { return; }

$task = $scriptProperties['task'] ?? [];        // все поля карточки
$meta = is_array($task['meta'] ?? null) ? $task['meta'] : json_decode($task['meta'] ?? '{}', true);

// meta несёт данные интегратора: рабочий каталог, движок, топик мессенджера…
$repo  = $meta['cwd'] ?? null;
$topic = $meta['topic'] ?? null;

// …ваша логика: webhook, запуск агента, запись в трекер.

Поле meta

У карточки есть JSON-поле meta — туда кладётся что угодно: рабочий каталог, движок и модель агента, идентификатор топика в мессенджере, номер задачи во внешнем трекере. Ядро эти данные не интерпретирует — они только для ваших плагинов. Задаётся при task_create (параметр meta) и доступно во всех событиях.

Живая админка (SSE)

Одно SSE-соединение обслуживает две разные вещи: уведомления адресату и живое обновление интерфейса.

• Поток читает эндпоинт assets/components/mxboard/sse.php через нативный EventSource. Авторизация — по куке mgr-сессии (same-origin), не по токену.
• Соединение короткоживущее (mxboard.sse_lifetime, дефолт 25с — ради shared-хостинга); клиент переподключается сам и докачивает пропущенное по Last-Event-ID.
• Управляется настройками mxboard.sse_enabled, sse_lifetime, sse_poll_interval (см. Настройки).

Уведомления — событие notification

Колокольчик со счётчиком непрочитанных + всплывающие тосты. Событие жизненного цикла задачи материализуется в очередь mxboard_notification — по строке на участника задачи (автор + исполнитель), за вычетом того, кто действие совершил. Клик по уведомлению открывает задачу.

Живое обновление — событие board-event

Второй тип событий идёт напрямую из журнала mxboard_log, то есть охватывает все действия, а не только адресные уведомления. Открытая доска тихо перечитывает текущий проект, открытая карточка — свои данные и чат. Перезагружать страницу, чтобы увидеть чужой комментарий или переезд карточки, не нужно.

Обновление не сбрасывает работу пользователя: выбранный отдел и проект, фильтры, набранный, но не отправленный комментарий, выбранные файлы и режим редактирования остаются на месте.

Составной курсор

Уведомления и журнал живут в разных id-пространствах, поэтому Last-Event-ID стал составным — n<notification_id>:l<log_id>. Старый числовой курсор по-прежнему понимается (трактуется как id уведомления), так что вкладка, открытая до обновления, не ломается.

SSE — встроенная реакция доски «для человека». Для внешних интеграций используйте события//events (см. Агенты → Автоматизация).

Киоск-доступ «только канбан»

Часть пользователей может заходить в менеджер и попадать сразу на доску, не видя ресурсов, элементов, файлов и прочих разделов. Механика штатная для MODX — пакет лишь даёт готовый пресет.

Политика mxBoard Only

При установке создаётся политика доступа mxBoard Only — whitelist поверх AdministratorTemplate: гасится всё, включаются только frames, load, list, view, home, components, logout. Всё остальное закрыто автоматически (и не разъедется на будущих версиях MODX — шаблон приносит актуальный набор прав сам).

Пакет политику никому не назначает — назначение остаётся ручным.

Как включить киоск для группы-отдела

1. Пользователи → Управление правами → Политики доступа — политика mxBoard Only уже есть.
2. Группе-отделу добавьте Доступ к контексту: контекст mgr, политика mxBoard Only, минимальная роль Member (в API — authority = 9999, иначе доступ не применится). Отдельную группу заводить не нужно — политику вешают прямо на группу-отдел: суммирование прав MODX означает, что урезание не затронет тех, у кого есть более широкая (админская) политика.
3. Чтобы такие пользователи после входа сразу попадали на доску, впишите имена этих групп в настройку mxboard.kiosk_usergroups (плагин mxBoardKiosk). Sudo редирект не затрагивает.

«Видно кнопку» ≠ «есть доступ»

Виджеты дашборда вроде «Новый ресурс» могут отображаться, но реальное действие закроет политика. Права режет политика доступа, а редирект mxBoardKiosk — лишь про стартовую точку.