Tasks 26.700.0–26.800.0: роботы с проверкой прав, чек-листы и новая длительность в REST

Tasks 26.700.0, 26.750.0 и 26.800.0 добавляют сортировку канбана, несколько чек-листов в действии создания задачи и робот «Добавить результат». Интеграциям потребуется проверить плановую длительность в REST, собственные действия БП и обработчики скрама. Роботы теперь проверяют права автора, а REST обновления шаблонов больше не принимает подмену пользователя.

Новое

Создавайте задачи с несколькими чек-листами

В 26.750.0 действие «Создать задачу» поддерживает до 10 чек-листов, по 50 пунктов в каждом, до 500 символов на пункт. Для программного заполнения используется плоское значение: элемент с префиксом [CHECKLIST] открывает очередной список, экранирование выполняется через \. Например, [CHECKLIST]Подготовка, затем строки пунктов, затем [CHECKLIST]Проверка и пункты второго списка. Публичные методы CBPTask2Activity::parseCheckLists(), readCheckListForm() и reduceCheckListItemsToStrings() разбирают и собирают этот формат.

Новый робот «Добавить результат» принимает текст и автора. Автором может быть один сотрудник или роль с одним человеком: responsible, scrum_master, scrum_owner. Перед записью проверяются права на результат. Ошибка возвращается в ErrorMessage; такой же выход появился у действий смены статуса и ответственного.

В дизайнере БП у задачи стали редактируемыми ответственный, плановая длительность, оценка времени, проект, родитель, предыдущие задачи и элементы CRM. «Получить информацию о задачах» получил сортировку, исключаемые ID и выходы TASKS_BLOCK_ITEMS_JSON, TASK_IDS, TASKS_INFO_HAS_MORE, Succeeded. Признак продолжения выдачи вычисляется запросом с одним дополнительным элементом.

Сортируйте канбан и ограничивайте селектор

С 26.700.0 в канбане вне группового режима можно выбрать сортировку по ID, названию, сроку, постановщику, ответственному, приоритету, оценке и датам. Выбор хранится в пользовательской опции tasks / kanban_field_sort.

В своих запросах задач используйте TaskQuery::SORT_ASC_EMPTY_LAST или SORT_DESC_EMPTY_LAST, чтобы пустые значения уходили в конец. Модификатор поддерживает срок, оценку, плановые даты и имена постановщика и ответственного. Проверка колонки — TaskQueryBuilder::supportsEmptyValuesLastOrder(); для неподдерживаемой колонки запрос откатывается на DESC.

Сущность task в entity selector получила опцию editableOnly. Например, в своём диалоге задайте entities: [{ id: 'task', options: { editableOnly: true } }], чтобы выбирать только редактируемые задачи. У TaskProvider есть новая точка расширения filterBrowsableTasks().

Учитывайте источник создания и часовой пояс

В 26.800.0 событие OnTaskAdd в пути V2 передаёт дополнительные FROM_AGENT, FROM_WORKFLOW, MANUAL_DEADLINE. Последний признак учитывает явный маркер срока, а без него — наличие дедлайна до подстановки значения по умолчанию. Свои обработчики могут различать создание из агента и бизнес-процесса.

Новый онбординг для зарегистрированных после старта функции пользователей считает только задачи из веба и мобильного приложения. После трёх задач подряд без срока или на себя он показывает соответствующий баннер; после трёх разных дней без вручную заданного срока — подсказку. Доступность управляется Tasks\Feature\OnboardingFeature.

С 26.700.0 даты в уведомлениях форматируются в часовом поясе получателя с учётом DST. Для своих сообщений есть Bitrix\Tasks\Util\DateTime\RecipientDateTimeFormatter с методами formatForRecipient(), formatTimeForRecipient() и formatManyForRecipient(). Результаты задач получили ссылку для скачивания всех файлов архивом.

Что сломается

Перепроверьте длительность из REST

В 26.700.0 tasks.task.get и tasks.task.list пересчитывают DURATION_PLAN из секунд в единицы DURATION_TYPE. Часы округляются через round(секунды / 3600). Дни считаются по длительности рабочего дня портала при MATCH_WORK_TIME=Y, иначе по 86400 секундам.

Тип mins в ответе становится hours: меняются и единица, и число. Пересчёт работает при пустом select, * и выборе нужных полей. Проверьте преобразования в своих отчётах, чтобы не считать полученные часы минутами.

Наследникам TaskWithIdProvider нужно привести переопределение к новой сигнатуре: getTasks(array $options = [], ?int $limit = null, int $offset = 0). Старая декларация несовместима с родительской.

Меняйте статус через отдельный API

С 26.750.0 Integration\Bizproc\Document\Task::updateDocument() молча отбрасывает STATUS, STAGE_ID и ADD_IN_REPORT. Для статуса используйте Task::updateDocumentStatus($taskId, $status, $modifiedById) или класс документа TaskStatusUpdate вместо обычного Task в составном ID документа БП.

Ошибка CTasks::Update(), CRM-связи или зависимости без автора и недостаточные права на эти связи теперь дают Main\SystemException вместо false. Добавьте обработку исключения в свои действия БП. Проверки учитывают и добавление, и снятие связей.

Робот «Изменить задачу» в проектах и скраме проверяет ACTION_TASK_EDIT автора. Изменение проекта, родителя или ответственного требует также ACTION_TASK_SAVE на новых значениях. При пустом ModifiedBy штатные действия берут запустившего процесс, если bizproc поддерживает этот метод; прежняя подстановка пользователя 1 больше не определяет автора. Робот, работавший без нужных прав, получит отказ.

Учтите изменения скрама и прямой записи участников

В 26.800.0 вложенная смена STAGE_ID при синхронизации и переносах скрама больше не вызывает отдельные OnBeforeTaskUpdate, OnTaskUpdate и запуск БП. Стадия добавляется в поля внешнего события. Проверьте обработчики, ожидавшие отдельное событие для переноса между бэклогом и спринтом.

Прямые операции CTaskMembers::Add, DeleteByUserID, DeleteByTaskID, updateForTask, DeleteAllByTaskID теперь бросают TaskNotExistsException для несуществующей задачи. Запись участников проходит под транзакционной блокировкой задачи.

В tasks.template.update параметр params.USER_ID с 26.800.0 игнорируется: запись идёт от текущего пользователя, чьи права проверены. Вложенные массивы в значениях фильтров UF_* отклоняются с InvalidFilterException; передавайте значения в поддерживаемой форме без таких вложений.