У меня есть задача, которую можно поручить группе кандидатов CG1. Теперь в CG1 10 пользователей, но, исходя из нескольких критериев, я хочу исключить одного пользователя из этих 10. Таким образом, исключенный пользователь не должен видеть задачу при запросе задач для назначения.
I used delegateTask.deleteCandidateUser(userId) on the creation of the task.
Но вышеперечисленное не сработало. Пожалуйста посоветуй.
Можете ли вы удалить пользователя из группы? Это будет предлагаемый подход. или создать новую группу без этого пользователя?
Это меняется каждый раз. Так что это специфично для этой конкретной задачи. Я не хочу, чтобы пользователь был удален из группы.
Вы можете удалить идентификационную ссылку для этого конкретного пользователя со стороны движка, чтобы она не соответствовала запросам.
Назначение динамической группы - это точный вариант использования слушателей задач (назначить событие). После 15 лет работы в BPM становится очевидным, что во всех случаях, кроме самых тривиальных (читайте демонстрацию), назначение задач обычно динамическое. Хотя пользователь может быть членом одной или нескольких групп, для назначения задач обычно требуется фильтрация за пределами уровня группы (на основе смены, географии, сертификатов или доступности). Для одного проекта я даже создал динамическое назначение задач и уведомление на основе матрицы RACI. Ответ Activiti на динамическое назначение - это слушатель задач.
У меня есть прослушиватель задач для создания события и события назначения. Итак, если я использую событие создания и использую delegateTask.deleteCandidateUser (userId), это не работает, а в событии назначения бесполезно, как использовать здесь прослушиватель?
Вам нужно сделать назначение пользователя в «назначить» даже слушателя. Это может показаться странным, но назначьте костры, прежде чем создавать.
Вы пробовали поиграть со слушателями задач? Идея состоит в том, чтобы сохранить назначение группы, но прикрепить слушателя к событию TASK_COMPLETED, где вы можете выполнять любую логику, которая вам нужна для авторизации, и генерировать исключение, если пользователю не разрешено это делать. Это будет работать как «последняя защита». против завершения неавторизованным членом группы и должен быть дополнен логикой уровня пользовательского интерфейса, которая скроет / заблокирует завершение до того, как это произойдет