понедельник, 24 сентября 2012 г.

Трекер Notal System: рассылка уведомлений (часть 2)

Интерфейс редактирования наборов критериев

Каждый набор критериев должен иметь уникальный номер (присваивается автоматически), для удобства каждый набор снабжаем именем. Наборы критериев должны быть видны в виде таблицы. Для редактирования наборов критериев должны быть кнопки:

  • Создать новый
  • Копировать (создать новый копированием)
  • Редактировать
  • Удалить
Редактирование набора критериев выполняется в отдельном окне.

Эту таблицу наборов критериев в конфигураторе разместить в бизнес-процессе отдельным пунктом (по аналогии с ролями).

В интерфейсе пользователя сделать аналогичную страницу со входом с панели пользователя, но там добавить выбор бизнес-процесса. Или можно сделать несколько таблиц на странице - по бизнес-процессам (как удобнее реализовать).

Интерфейс редактирования одного набора критериев (специальное окно) должен включать в себя две части:

  • Раздел критериев фильтрации комментария, состоящий, в свою очередь, из подразделов по типу комментария, по состоянию и по тегам (см. описание критериев).
  • Раздел адресатов, тоже состоящий из двух подразделов - по ролям и по выделенным пользователям. Этот раздел отсутствует в интерфейсе пользователя - там адресатом является этот самый пользователь.

Отправка уведомлений по почте и через SMS - общие принципы

Это надстройка для системы, рассылать будем (или не будем) все те извещения, которые есть для пользователя в системе. Никакой дополнительной фильтрации не предусмотрено.

Пользователь сам устанавливает, будет ли он получать уведомления на почту и/или через SMS. Это потребует дополнения информации о пользователе следующими полями:

  • Адрес электронной почты
  • Мобильный телефон
  • Флаг "Получать уведомления на почту"
  • Флаг "Получать уведомления через SMS
  • Префикс почтовых сообщений (см. ниже)
Все это надо разместить в интерфейсе пользователя с правом редактирования (по аналонии со сменой пароля).

Отправка уведомлений по почте

Письмо делается на основе внутреннего уведомления системы и содержит его текст полностью. Необходимые дополнения:

  • Текст письма должен содержать ссылку на открытие задачи
  • Заголовок письма начинается с префикса (см. след пункт) и содержит аббревиатуру бизнес-процесса и номер задачи
  • Префикс письма нужен для возможности настройки пользователем сортировки входящих писем его почтового ящика. Поэтому пользователь может сам задать префикс для уведомлений. Если пользователем префикс не задан, используем "Notal System: ".
  • Отправитель - ? Входящая почта все равно приниматься не будет - лучше чтобы не было возможности ее отправить.

Отправка уведомлений через SMS

Пока не ясна востребованность этого, да и много смс - не больно хорошо. Если появится возможность это сделать, то реализуем, оставив администратору бизнес-процесса и пользователю заботиться о том, чтобы количество таких извещений было невелико. Возможно, в будущем придется в набор критериев уведомлений вводить соответстсвующий флажок "отправлять SMS", чтобы можно было так извещать только о важных событиях.

В настоящий момент не реализуем и считаем, что вопрос требует додумывания.

воскресенье, 23 сентября 2012 г.

Трекер Notal System: рассылка уведомлений (часть 1)

Постановка проблемы

Пользователям полезно оперативно получать информацию о происходящем с задачей, особенно если эта задача не у них на исполнении. К примеру:

  • автору или владельцу задачи полезно узнать, что его задача отрицательно завершена
  • исполнителю полезно узнать, что задача передана другому
  • возможным исполнителям полезно узнать, что в накопителе (ждущем состоянии) появилась новая задача
Все это решается механизмом внутренних уведомлений системы с возможностью отправлять эти уведомления вовне по e-mail или через SMS.

События, которые могут являться основанием для уведомления

В настоящий момент считаем, что уведомления касаются только задач, т.е. все происходящее с документами из рассылки исключаем (при необходимости это будет описано в отдельном документе).

Все, что происходит с задачами, отражается в соответствующем комментарии к задаче. То есть именно событие возникновения нового комментария должно являться стартом процесса рассылки: проверить, не удовлетворяет ли данный коммент критериям уведомления.

Содержание уведомлений и их хранение

Уведомление должно содержать дату и время коммента, бизнес-процесс и номер задачи, автора действия, содержание события (по типам комментариев) и текстовую часть комментария, а также пользователя-адресата. То есть один комментарий может породить множество уведомлений, различающихся только адресатами.

Уведомления должны быть организованы как таблица базы данных, которая отображается разными способами: в пользовательском интерфейсе Notal System, как исходные данные для отправки почты или SMS. Для последних стоит завести соответствующие поля таблицы, в которых отмечать, что соответствующее сообщение отправлено.

Редактирование уведомлений не предусмотрено. Чистка истории уведомлений "ранее выбранной даты" может быть реализована в интерфейсе конфигуратора для пользователя с полными правами администратора.

Создание уведомлений: критерии отбора событий

Как сказано выше, уведомления имеют в основе появление комментария к задаче. Поскольку не каждый комментарий стоит того, чтобы делать из него уведомление, то необходим набор критериев, удовлетворив которым коммент породит уведомление. По аналогии со спам-фильтрами надо иметь возможность задать несколько наборов критериев для уведомлений. Каждый такой набор может иметь свой список адресатов.

Набор критериев создается для конкретного бизнес-процесса.

Комментарий должен соответствовать всем критериям набора, чтобы породить уведомление.

Первый критерий - тип комментария. Мы имеем комментарии трех типов:

  • Движение
  • Служебный
  • Пользовательский
Выбираем один или несколько типов комментария.

Второй критерий - состояние. Мы можем указать конкретное состояние или определенный тип состояния:

  • Активное
  • Ждущее
  • Финальное (без разделения)
  • Финальное положительное
  • Финальное отрицательное
  • Любое состояние
  • (Конкретное состояние)
Выбираем один вариант. При движении задачи тем самым мы можем отследить попадание задачи в определенное состояние (или состояние определенного типа), но не можем отследить уход задачи из данного состояния.

Третий критерий - теги задачи. Мы можем указать перечень тегов и способ их обработки "и"/"или". Если теги не выбраны, то критерий считается удовлетворенным.

К каждому комментарию применяются все имеющиеся наборы критериев - даже если удовлетворяет одному, то у другого набора могут быть другие адресаты.

Адресаты уведомлений

В каждом наборе критериев должен быть указан адресат или механизм создания адресатов. Имеем три варианта:

  • Конкретный адресат
  • По ролям
  • По выделенным пользователям задачи

Вариант конкретного адресата наиболее прост и должен быть реализован в интерфейсе пользователя, при этом адресатом является он сам. Т.е. это для того, чтобы пользователь мог сам настроить себе рассылку уведомлений.

Второй вариант - указание адресатов по ролям. Указываем одну или несколько ролей, пользователи с которыми должны получать уведомления.

Третий вариант - указание выделенных пользователей задачи. К выделенным пользователям задачи относятся:

  • Автор
  • Владелец
  • Основной исполнитель
  • Текущий исполнитель
  • Исполнитель до совершения движения - имеет смысл, если задача при движении меняет исполнителя.
Можно выбрать несколько пунктов или не выбирать ни одного.

Второй и третий вариант могут присутствовать одновременно. Эти варианты адресатов доступны при создании рассылки в интерфейсе конфигуратора. Права на создание/редактирование рассылки есть у администратора бизнес-процесса.

Автору действия не отправляется уведомление, даже если он удовлетворяет критерию адресатов рассылки. Это логично - он сделал действие, его незачем уведомлять о нем.

Адресат уведомления должен иметь право просмотра задачи. То есть по предыдущим критериям определяется набор пользователей, кому отправить уведомления, и этот набор прогоняется через фильтр прав на просмотр задачи - если пользователь не имеет права смотреть задачу, то ему и незачем получать уведомления о ней.

Список адресатов, полученный из одного или нескольких наборов критериев, может содержать повторяющихся адресатов (к примеру, пользователь может быть одновременно Автором и Владельцем). Необходимо исключать дублирующихся пользователей.

Заблокированные пользователи не могут получать уведомления - уведомления для них просто не должны создаваться.

Интерфейс просмотра уведомлений

На панели пользователя зарезервирована ссылка на уведомления - просматривать их будем на специальной странице, где они выводятся в обратной хронологической последовательности. Количество показываемых уведомлений и навигация просмотра - как удобнее реализовать. Желательно наличие фильтров уведомлений по следующим критериям:

  • Бизнес-процесс
  • Тип комментария
  • Тип состояния

Уведомление должно являться ссылкой на открытие соответствующей задачи в новом окне (по аналогии с реестром задач).

Интерфейс редактирования наборов критериев

Для удобства каждый набор снабжаем именем, нумеруем все наборы по порядку. Наборы критериев должны быть видны в бизнес-процессе в виде таблицы (в интерфейсе конфигуратора ясно, где расположить в интерфейсе пользователя?).

(продолжение следует)

вторник, 11 сентября 2012 г.

Open Office Basic - функция Shell

Клиентская часть трекера Notal System встроена в Open Office и потому писалась на опенофисофском бэйсике. С ним какая проблема - пишут на нем мало, так что найти решение каких-либо проблем в сети не получается. Вот решил выкладывать сюда записки - больше себе для памяти.

Функция Shell и перенаправление вывода в файл

Плюсом OO-реализации этой функции является то, что в отличие от VBA она имеет синхронный режим, т.е. следующая команда будет отрабатываться только после завершения Shell (полезно, если используешь ее для вызова внешней программы для кодировки большого файла - время работы предсказать трудно и измеряться оно может секундами). Но есть засада: если надо вызвать внешнюю программу и перенаправить вывод в файл, то файл-то создается, но нулевой длины. Комбинация с Environ не помогает.

РЕШЕНИЕ: написать bat-файл с нужной командной строкой с перенаправлением вывода и уже его вызывать через Shell.

PS. Для таких записок завожу отдельный тег "OO Basic"

понедельник, 10 сентября 2012 г.

Notal System - наш трекер

Давно не писал сюда, возобновляю. За прошедший почти год трекер получил имя Notal System, получил свой сайт notalsystem.ru и свою wiki, где раполагается документация. На основе Notal System на нашем заводе автоматизированы три бизнес-процесса, один из них - маркетинговая подготовка производства (о ней как-нибудь напишу подробнее). Сейчас этот трекер внедряется в двух сторонних организациях - в общем, нормальная жизнь продукта. Какие плюсы:
  • наглядное представление бизнес-процесса в виде диаграммы состояний - это понятно даже коммерсантам
  • веб-интерфейс
  • интеграция с офисными программами - Ms Office и Open Office
  • наличие API, что позволяет интегрировать с любыми программами, способными отправлять и принимать веб-запросы (у нас на заводе интегрировано с 1С)
  • удобно использовать для управления инцидентами - можно реализовать ITIL, к примеру
Некоторые недостатки (временные, разумеется):
  • пока не сделано управление временем - у задачи нет срока исполнения. Это не мешает текущему управлению в том смысле, что можно посмотреть, сколько задача находится у исполнителя, не превышен ли норматив; а вот планировать на будущее пока неудобно
  • во встроенном электронном архиве документы хранятся с историей версий, но пока не реализованы состояния документа - черновик/утвержден/отменен и т.п.
В общем, есть куда развиваться. Да, если вам интересно попробовать поработать с Notal System, то пишите мне на notal@nm.ru - сделаем вам свою базу, срок пробного использования два месяца.