Мы делаем приложение «Межпортальные задачи и коллабы», которое связывает задачи двух самостоятельных порталов Битрикс24. И один из вопросов, который возникает у команд чаще всего, звучит так: что будет с задачей, если она перестала соответствовать правилу обмена?
Отвечаем на примере нашего же приложения.
Где заканчивается область обмена
Область синхронизации задают по проектам, рабочим группам и существующим коллабам либо по выбранным ответственным. Для каждой связки порталов действует своё правило. Пока задача ему соответствует, пара задач обменивается изменениями.
Как только соответствие исчезло, приложение останавливает обмен для уже созданной пары. Важно, что это не удаляет вторую карточку и не создаёт новую, когда исходную задачу вернут обратно.
Причины выхода из области обычно три:
- Перенос в другой проект. Задачу по доработке сайта создали в проекте клиента, включённом в обмен с порталом подрядчика. После сдачи клиент переносит её во внутренний проект для финансового согласования — обмен для этой пары прекращается.
- Смена ответственного. В режиме по ответственным приложение проверяет назначенного исполнителя, а не постановщика и не автора. Ушёл менеджер в отпуск, задачу передали коллеге, которого нет в наблюдаемом списке, — пара вышла из синхронизации.
- Права и доступ. Проект закрыли для части сотрудников, задачу удалили, перестроили структуру. Вторая карточка при этом никуда не исчезает.
Что видит пользователь
После обработки изменения обмен по паре прекращается, а в зеркальной задаче появляется заметная пометка. Она честно предупреждает: две карточки больше нельзя считать актуальными копиями друг друга.
Несколько практических моментов, которые уточняют у нас постоянно:
- Остановка касается одной связанной пары, а не всех задач между порталами.
- Зеркальная задача остаётся в обычном рабочем контексте, если у сотрудника есть доступ. В ней могут остаться файлы, решения и история локальной команды — удалять её из-за остановки не нужно.
- Правки в остановленной паре не передаются второй стороне. Если перенос в закрытую рабочую группу был ошибочным, возврат задачи в исходную коллабу возобновит работу прежней пары.
Почему зеркало не удаляется вместе с исходной задачей
Это сознательное решение. После создания каждая из связанных задач существует на своём портале как самостоятельная карточка. Удаление одной задачи или потеря доступа к ней не передаёт второй стороне команду на удаление — иначе рабочая запись могла бы исчезнуть без отдельного решения людей, которые с ней работают.
Типовой сценарий: сотрудник удаляет задачу на портале клиента, приняв её за дубль. На портале подрядчика зеркальная задача не исчезает. Руководитель решает локально — закрыть её, перенести в другой проект или сохранить как запись о выполненной работе.
То же правило действует для файлов: если файл отсоединили на одной стороне, его копия на другой стороне автоматически не удаляется.
Возврат задачи в область обмена
Возврат не требует создавать ещё одно зеркало. Если задача снова попадает в выбранный проект, рабочую группу или существующую коллабу либо ей возвращают наблюдаемого ответственного, приложение продолжает прежнюю пару — при условии, что обе карточки доступны.
Перед возвратом стоит проверить четыре вещи:
- Исходная задача вновь соответствует правилу.
- Вторая карточка доступна и не удалена.
- Приложение установлено и активно на обоих порталах.
- Команда понимает, что менялось в период остановки — автоматической передачи изменений задним числом не будет, существенные правки лучше сверить вручную.
Порядок действий для команды
Чтобы перенос во внутренний проект не превратился в незаметный разрыв рабочего процесса, полезно заранее договориться:
- перед переносом из включённого проекта решить, нужна ли дальнейшая работа второй стороне;
- перед сменой ответственного сверить нового исполнителя с наблюдаемым списком;
- не ожидать передачи новых правок после остановки — читать пометку в зеркале;
- не удалять вторую карточку автоматически;
- после возврата в область сравнить сроки, описание и другие существенные данные в обеих карточках.
Такой порядок подходит и агентству с несколькими клиентскими порталами, и подразделениям, которые работают в самостоятельных порталах Битрикс24.
Если у вас задачи живут на двух порталах и страшно, что одна из них «выпадет» из обмена незаметно — начните с определения границ обмена. Это половина работы.
Top comments (0)