Постановка проблемы
Пользователям полезно оперативно получать информацию о происходящем с задачей, особенно если эта задача не у них на исполнении. К примеру:
- автору или владельцу задачи полезно узнать, что его задача отрицательно завершена
- исполнителю полезно узнать, что задача передана другому
- возможным исполнителям полезно узнать, что в накопителе (ждущем состоянии) появилась новая задача
Все это решается механизмом внутренних уведомлений системы с возможностью отправлять эти уведомления вовне по e-mail или через SMS.
События, которые могут являться основанием для уведомления
В настоящий момент считаем, что уведомления касаются только задач, т.е. все происходящее с документами из рассылки исключаем (при необходимости это будет описано в отдельном документе).
Все, что происходит с задачами, отражается в соответствующем комментарии к задаче. То есть именно событие возникновения нового комментария должно являться стартом процесса рассылки: проверить, не удовлетворяет ли данный коммент критериям уведомления.
Содержание уведомлений и их хранение
Уведомление должно содержать дату и время коммента, бизнес-процесс и номер задачи, автора действия, содержание события (по типам комментариев) и текстовую часть комментария, а также пользователя-адресата. То есть один комментарий может породить множество уведомлений, различающихся только адресатами.
Уведомления должны быть организованы как таблица базы данных, которая отображается разными способами: в пользовательском интерфейсе Notal System, как исходные данные для отправки почты или SMS. Для последних стоит завести соответствующие поля таблицы, в которых отмечать, что соответствующее сообщение отправлено.
Редактирование уведомлений не предусмотрено. Чистка истории уведомлений "ранее выбранной даты" может быть реализована в интерфейсе конфигуратора для пользователя с полными правами администратора.
Создание уведомлений: критерии отбора событий
Как сказано выше, уведомления имеют в основе появление комментария к задаче. Поскольку не каждый комментарий стоит того, чтобы делать из него уведомление, то необходим набор критериев, удовлетворив которым коммент породит уведомление. По аналогии со спам-фильтрами надо иметь возможность задать несколько наборов критериев для уведомлений. Каждый такой набор может иметь свой список адресатов.
Набор критериев создается для конкретного бизнес-процесса.
Комментарий должен соответствовать всем критериям набора, чтобы породить уведомление.
Первый критерий - тип комментария. Мы имеем комментарии трех типов:
- Движение
- Служебный
- Пользовательский
Выбираем один или несколько типов комментария.
Второй критерий - состояние. Мы можем указать конкретное состояние или определенный тип состояния:
- Активное
- Ждущее
- Финальное (без разделения)
- Финальное положительное
- Финальное отрицательное
- Любое состояние
- (Конкретное состояние)
Выбираем один вариант. При движении задачи тем самым мы можем отследить попадание задачи в определенное состояние (или состояние определенного типа), но не можем отследить уход задачи из данного состояния.
Третий критерий - теги задачи. Мы можем указать перечень тегов и способ их обработки "и"/"или". Если теги не выбраны, то критерий считается удовлетворенным.
К каждому комментарию применяются все имеющиеся наборы критериев - даже если удовлетворяет одному, то у другого набора могут быть другие адресаты.
Адресаты уведомлений
В каждом наборе критериев должен быть указан адресат или механизм создания адресатов. Имеем три варианта:
- Конкретный адресат
- По ролям
- По выделенным пользователям задачи
Вариант конкретного адресата наиболее прост и должен быть реализован в интерфейсе пользователя, при этом адресатом является он сам. Т.е. это для того, чтобы пользователь мог сам настроить себе рассылку уведомлений.
Второй вариант - указание адресатов по ролям. Указываем одну или несколько ролей, пользователи с которыми должны получать уведомления.
Третий вариант - указание выделенных пользователей задачи. К выделенным пользователям задачи относятся:
- Автор
- Владелец
- Основной исполнитель
- Текущий исполнитель
- Исполнитель до совершения движения - имеет смысл, если задача при движении меняет исполнителя.
Можно выбрать несколько пунктов или не выбирать ни одного.
Второй и третий вариант могут присутствовать одновременно. Эти варианты адресатов доступны при создании рассылки в интерфейсе конфигуратора. Права на создание/редактирование рассылки есть у администратора бизнес-процесса.
Автору действия не отправляется уведомление, даже если он удовлетворяет критерию адресатов рассылки. Это логично - он сделал действие, его незачем уведомлять о нем.
Адресат уведомления должен иметь право просмотра задачи. То есть по предыдущим критериям определяется набор пользователей, кому отправить уведомления, и этот набор прогоняется через фильтр прав на просмотр задачи - если пользователь не имеет права смотреть задачу, то ему и незачем получать уведомления о ней.
Список адресатов, полученный из одного или нескольких наборов критериев, может содержать повторяющихся адресатов (к примеру, пользователь может быть одновременно Автором и Владельцем). Необходимо исключать дублирующихся пользователей.
Заблокированные пользователи не могут получать уведомления - уведомления для них просто не должны создаваться.
Интерфейс просмотра уведомлений
На панели пользователя зарезервирована ссылка на уведомления - просматривать их будем на специальной странице, где они выводятся в обратной хронологической последовательности. Количество показываемых уведомлений и навигация просмотра - как удобнее реализовать. Желательно наличие фильтров уведомлений по следующим критериям:
- Бизнес-процесс
- Тип комментария
- Тип состояния
Уведомление должно являться ссылкой на открытие соответствующей задачи в новом окне (по аналогии с реестром задач).
Интерфейс редактирования наборов критериев
Для удобства каждый набор снабжаем именем, нумеруем все наборы по порядку. Наборы критериев должны быть видны в бизнес-процессе в виде таблицы (в интерфейсе конфигуратора ясно, где расположить в интерфейсе пользователя?).
(продолжение следует)
