Задача: Если УЗ агента заблокирована, то ответственным (Assigned user) за все не закрытые обращения становится ответственный за группу (responsible), на которой находится обращение. Важно, чтобы этот руководитель подставлялся автоматически, вне зависимости от обновления открытого обращения. Т.е. тригером для обновления поля Assigned user должна быть блокировка сотрудника, который стоит в этом поле.
Есть идеи, как это реализовать?
Привет!
Я бы реализовал это через (новое) системное событие (event), скажем employee.dimissed на таблице employee, которое тригерится onAfter бизнес-правилом на таблице employee в случае изменения записи сотрудника (поле active меняется на false или locked_out меняется на true, в зависимости от способа реализации “блокирования учетной записи агента”).
Этот event следует обрабатывать через event script, который пробежится по незакрытым задачам (itsm_incident, itsm_request, itsm_request_task и т.д. по сценарию) свежезаблокированного сотрудника (его sys_id брать из event.instance) и изменит assigned_user на assignment_group.responsible, если этот самый responsible в группе сам не заблокирован. В противном случае (responsible заблокирован) я бы поместил задачу в очередь как новую (то есть менять state вместе с чисткой assigned_user) с соответствующей рабочей заметкой. А то мало ли массовое увольнение целого отдела…
С уважением, Никита
p.s. На всякий пожарный, я бы переасайнивал задачи (то есть приступал к обработке event) не сразу, а спустя какое-то время, например 1 час , вставив дополнительную проверку в event script, что наш пользователь действительно в момент выполнения event script остался заблокированным и его не разблокировали спустя пару минут, т.к. “промахнулись”. Для этого у нас есть отложенные системные события.
p.p.s. Если не хочется заморачиваться на events, то можно и async after бизнес правилом это делать, но тогда забудьте про “задержку на всякий пожарный” перед переасайниванием задач.
Всё Simple