Передача workflow и доступы команды
Редакционный процесс уже описывает вход, нормализацию, маршруты, подборку и диагностику. Теперь его должен понять другой участник без устных пояснений автора. Подготовим пакет передачи: файлы примера, ответственность за изменения, ожидаемые права и перечень неподключённых частей. Результат позволит продолжить работу, не принимая учебную модель за готовую производственную интеграцию.
Введём две синтетические роли. Анна принимает решения о содержании, Максим поддерживает преобразования и маршруты. Это учебные участники, а не приглашённые пользователи n8n. Аккаунты, credentials, API-ключи и доступы в этой серии не создавались. Собственные приложения содержат только редакционные данные и явно ожидаемые состояния.
Собственные файлы этого шага доступны в архиве fixtures и контрактов серии, папка lesson-09. Это приложения к объяснению, а не готовый экспорт workflow.
Ответственность до настройки доступа
Анне нужно понимать, почему P-003 находится в ручной очереди и что потребуется для принятия новой темы. Максиму нужно знать, какие поля обязательны и какие случаи нельзя потерять. Эти задачи различаются. Редакторское право одобрить материал не обязано означать право изменить webhook или секрет внешнего сервиса, а возможность редактировать узел не означает полномочие публиковать статью.
Опишем действия, а не сразу названия платформенных ролей. Анна читает карточки, уточняет содержание и принимает редакционное решение. Максим меняет нормализатор, сопоставляет fixtures и объясняет изменение схемы. Отдельный ответственный за экземпляр выбирает доступные роли и подключения. В учебной модели эта последняя роль никому не назначена, поскольку реального экземпляра нет.
| Учебная роль | Предметная задача | Нужные материалы | Отдельное разрешение |
|---|---|---|---|
| Редактор | Рассмотреть предложение | Карточка и причина очереди | Одобрение содержания |
| Поддерживающий workflow | Изменить правило | Контракт, схема, fixtures | Изменение рабочего процесса |
| Ответственный за экземпляр | Настроить доступ | Политика аккаунтов и сервисов | Подключение credentials |
| Новый участник | Понять ограничения | Пакет передачи | Доступ по назначенной задаче |
Такое описание не обещает, что платформа реализует любое желаемое разделение одной кнопкой. В конкретном тарифе могут отсутствовать нужные роли или granular-права. Тогда выбирается другой процесс совместной работы: например, передача обезличенного проекта и отдельное внесение изменения ответственным. Не следует компенсировать отсутствие функции общим паролем или передачей широкого токена.
Sharing зависит от установки
В n8n разделение доступа к workflow связано с возможностями экземпляра. Текущая документация указывает workflow sharing для всех Cloud-планов и self-hosted Business/Enterprise. Workflow в проекте получает доступ через участников проекта, а не обязательно через добавление человека к отдельной схеме. Руководство sharing описывает эти условия и различия.
Также важно различать использование credential и просмотр его значения. Предоставленный доступ к workflow может позволять выполнять узлы с уже используемыми credentials. При этом редактирование узлов с явно нерасшаренными credentials ограничивается. Нельзя считать скрытое поле токена гарантией отсутствия полезных для злоупотребления возможностей: действие от имени подключённого сервиса тоже является полномочием.
Для нашего процесса доступов к сервисам пока нет. Передача fixtures Максиму даёт знание правил, но не возможность отправлять запросы в настоящую редакционную систему. Если позже появится credential записи задач, нужно отдельно решить, кто вправе его использовать и в каких схемах. Политика должна учитывать операцию внешнего сервиса, а не только видимость строки с секретом.
Что входит в пакет передачи
Пакет начинается с договора входа и ожидаемого результата. Затем идут исходные три предложения, нормализованные items и таблица маршрутов. Подборка объясняет новую форму данных после Aggregate. Случаи ошибок и диагностики показывают, что делать с неизвестной темой, неверным типом и потерянным идентификатором. Это последовательные части одного примера, а не набор независимых полезных заметок.
{
"project": "ProfessorWeb",
"example_execution": "not_run",
"external_connections": [],
"credentials": [],
"published": false,
"approval": "human_decision_required"
}Такой объект кратко сообщает статус пакета. Он не является экспортом workflow n8n и не должен импортироваться как готовая схема. Полный handoff.json перечисляет собственные приложения и открытые границы. Среди них — выбор окружения, построение canvas, аутентификация webhook, накопление событий, дедупликация и подключение обработчика ошибок.
Передающий человек должен также указать, какие части проверены лишь чтением. В нашем случае объяснения и файлы подготовлены, текущие документы сверены, но пример не выполнялся. Нет оснований обещать готовый webhook, успешный retry или видимое уведомление. Такая запись экономит время следующему участнику: он начинает с известных ограничений, а не ищет отсутствующий рабочий endpoint.
Экспорт workflow требует чтения
Настоящий workflow можно экспортировать в JSON, но экспорт не следует считать заведомо безопасным для публикации. В нём присутствуют имена и идентификаторы credentials, а HTTP Request может содержать авторизационные заголовки, например после импорта команды cURL. Документация экспорта предупреждает о необходимости удалить или обезличить такую информацию перед передачей.
Дополнительно прочитайте закреплённые данные, фиксированные значения и адреса получателей. Даже без credential внутри узла может находиться чувствительный текст или ссылка на внутреннюю систему. Файл нужно оценивать целиком по содержанию. В наших собственных приложениях таких реальных подключений нет; приватные материалы подготовки курса в читательский пакет не входят.
Готовый шаблон из библиотеки тоже требует предметного разбора. Он может выполнять ненужные внешние действия, использовать другое определение пригодности или принимать решение, которое у нас оставлено редактору. Для P-003 обязательно должен сохраняться ручной исход. Если шаблон молча удаляет неизвестную тему, удобство импорта не делает его подходящим для задачи ProfessorWeb.
API для обслуживания, а не обязательный шаг
n8n имеет собственный API для программного управления ресурсами. Его доступность и полномочия ключа зависят от условий экземпляра. Авторизация использует заголовок X-N8N-API-KEY; scoped-ключи описаны для Enterprise, а вне этого режима ключ имеет широкие права своего аккаунта. Документация API-аутентификации объясняет эти границы.
Для передачи нашего процесса API не требуется. Мы не генерируем ключ ради чтения курса и не предоставляем команду изменения рабочего workflow. Если позднее появится задача автоматической инвентаризации схем, сначала нужно определить перечень разрешённых операций, срок действия доступа и место хранения результата. Чтение списка схем и публикация новой версии имеют разные последствия, хотя используют один интерфейс.
Итоговый пакет сохраняет три исходных предложения, их объяснимые маршруты и отдельное человеческое одобрение. Предложите новому участнику проследить P-003 от исходной строки web3 до manual_review и назвать, что ещё требуется для её принятия. Если он может сделать это по файлам и понимает, почему публикации не было, договор процесса передан достаточно ясно для следующего этапа реализации.