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