Notal System: справочники

В Notal System есть сущности "Задача", "Документ", "Пользователь", задачи организованы в бизнес-процесс, который описывается через "Состояния" и "Переходы". По сути, это основной конструктор, из которого все там строится. В этом наборе не хватает одной важной возможности - нет Справочников, к примеру - списка Контрагентов. Для того, чтобы реализовать эту возможность, рассмотрим их назначение и возможности использования.

Справочники, назначение
Справочники по сути это списки объектов, имеющих много реквизитов, эти объекты имеют какой-либо самостоятельный смысл (описывают объективную реальность (желательно чтобы её)), существуют достаточно продолжительное время в относительно неизменном виде и используются разными способами (это - прямое следствие их объективной реальности). К примеру, сущность "Пользователи" вполне удовлетворяет этому определению.
Другими примерами справочников (вполне тривиальными) являются:

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

Способы использования справочников
1. Хранение информации. Список контактов полезен сам по себе, особенно если в нем организован поиск и отбор по реквизитам. Считаем хранение долгополезной информации базовой функцией справочников.
2. В качестве реквизита других объектов. К примеру, у задачи/документа мы можем завести допреквизит Клиент типа "справочник.Контрагенты" и иметь под рукой нужную справочную информацию. Более интересное использование - поиск всех задач/документов, у которых одним из реквизитов (или определенным реквизитом) является данный элемент данного справочника.
3. Для формирования документов по шаблону. Сейчас мы умеем создавать документ на основе шаблона, передавая в него контекст архива и/или задачи. Если у документа уже будут заданы и заполнены реквизиты типа справочник (или у задачи), то возможности для заполнения текста документа значительно расширяются.

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

Общая конструкция справочников
Надо иметь общий список справочников, из которого каждый справочник можно открыть в списке. Список одноуровневый. Из списка можно открыть элемент справочника для просмотра или редактирования.
Каждый справочник имеет свей id (число) и Наименование (к примеру, id=1 "Контрагенты"). Управление доступом осуществляется на уровне справочника в целом Т.е. если пользователь имеет доступ к справочнику "Контрагенты", то ко всем его элементам в равной степени. Управление доступом осуществляется по следующим параметрам:

• Просмотр справочника в списке (используется в т.ч. для заполнения реквизитов задачи или документа)
• Просмотр элемента со всеми его реквизитами
• Добавление нового элемента
• Редактирование элемента справочника (удаление не предусмотрено)

Справочник имеет свой набор реквизитов, которые могут иметь тип:

• Число
• Строка
• Дата
• Справочник определенного типа
• (возможно) Пользователь

Отображение в списке каждого реквизита может настраиваться (id виден всегда). Так же каждый реквизит может использоваться для отбора (числа и даты по интервалу значений; строки по "содержит", "не содержит", "начинается с", "не начинается с"; справочники по конкретному элементу) - это вполне заменит многоуровневость списков.
Сортировку предполагаем только по реквизитам типа строка, число, дата (в т.ч. по id и наименованию). Желательно иметь быстрый поиск по мере набора на клавиатуре (если несложно реализовать).
Для редактирования элементов и для просмотра применяется одна форма - самая простая, типа той, что мы используем для допреквизитов задачи. Позже можно задуматься над редактором форм.
Элемент справочника всегда имеет экранное представление в виде пары id+Наименование. Надо предусмотреть стандартные кнопки открытия списка для выбора элемента и открытия реквизита (выбранного элемента) на просмотр. Это должно быть сделано одинаково во всех местах, где справочник может использоваться как реквизит - в задачах, в документах и в справочниках (когда один справочник имеет реквизит типа другой справочник).

Стандартные отчеты по справочнику
1. Печатная форма списка. Должна учитывать установленные видимость реквизитов, сортировку и отбор.
2. Печатная форма элемента справочника. Очевидно.
3. Объекты со ссылками на данный элемент справочника. Выбираем элемент справочника и смотрим все задачи, все документы и все другие справочники, у которых данный элемент выбран в качестве какого-либо из реквизитов. Настройки данного отчета: выбор типа и ограничения объектов для поиска: к примеру, задачи данного бизнес-процесса, задачи в активных состояниях, только документы или документы данной категории. В частности, так можно посмотреть все подчиненные элементы данного элемента справочника - к примеру, все Контакты данного Контрагента.
4. Объекты с косвенными ссылками на данный элемент справочника. Примерно то же, что и предыдущий отчет, но сначала мы находим все элементы всех справочников, которые имеют данный элемент своим реквизитом, а потом строим предыдущий отчет уже по множеству найденных элементов. Это имеет смысл, если у нас есть конструкция типа "подчиненный справочник" - у справочника "Контакты" есть реквизит "Контрагент", то есть фактически мы имеем Контрагента и его Контакты (работников). К примеру, к Письмам (категория документов) у нас привязан только Контакт - нам интересно собрать всю переписку с данным Контрагентом. То есть по Контрагенту мы находим все его Контакты, а потом по этим Контактам - все документы.

Специальное использование справочников
Справочник Контактов надо использовать для отправки писем: создали документ с данным контактом и сразу отправили его по электронной почте по адресу, указанному в Контакте.
Можно рассмотреть возможность привязки элемента справочника к исполнителю и наоборот - привязку исполнителя к элементу справочника. То есть к пользователю мы можем привязать контакт и хранить там расширенную информацию о пользователе, а можем к контакту привязать пользователя, т.е. с этим контактом работает данный пользователь. Это требует додумывания.
Формирование и хранение выборок из справочников. Из справочника Контрагенты по определенным критериям выбрали возможных клиентов, разбили список на несколько частей и каждой части назначили исполнителя, который обзвонит этх потенциальных клиентов. Что это за объект - такая выборка и как с ней работать - требует додумывания.

Импорт/экспорт через XML
Требуется импорт справочников через XML - к примеру, выгрузкой из 1С. Критерии выгрузки - не важно. Проверка дубликатов при загрузке, причем дубликаты могут выявляться по реквизитам, не по id или Наименованию - к примеру, Контрагетов проверяем по ИНН.
Также желательно иметь экспорт справочников в XML.

Необходимые изменения, напрямую не связанные со справочниками
Поскольку одним из основных использований справочников является заполнение документов по шаблону, то надо сменить очередность действий при создании документа:

• нажимаем кнопку [создать новый]
• выбираем шаблон
• заполняем/редактируем описание документа
• заполняем реквизиты (допполя) документа
• и только теперь формируем документ по шаблону

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

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

Перехват событий в Open Office

Задача: при возникновениив Open Office определенного события вызывать макрос. К примеру, при создании нового документа вызывать макрос ItIsNewDocumentWow.

Понятно, что этот макрос должен лежать в какой-либо библиотеке (не в документе).

Решение 1:

• в интерфейсе Writer (или другой программы из Open Office) в меню выбираем Сервис / Настройка...
• Откроется окно Настройка, вкладка События. В ней перечислены все возможные события, которые отлавливает Open Office. Внизу под окном со списком есть поле Сохранить в - выбираем в нем OpenOffice.org (или можно выбрать документ - тогда событие будет перехватываться только если оно происходит в этом документе (впрочем, не совсем так - есть любопытные ошибки)).
• Выбираем нужное событие, ставим на него курсор и нажимаем кнопку [Макрос...].
• Выбираем макрос и жмем [Ok].
• В окне Настройка жмем [Ok].

Решение 2 (редактируем конфигурационный файл, годится доя OpenOffice 3.3):

• Закрываем все программы Open Office, в том числе в трее.
• В папке C:\Documents and Settings\Имя пользователя\Application Data\OpenOffice.org\3\user\ открываем в текстовом редакторе файл registrymodifications.xcu
• после какого-либо тега < /item > вставляем следующий текст:
  < item oor:path="/org.openoffice.Office.Events/ApplicationEvents/Bindings" >< node oor:name="OnNew" oor:op="replace" >< prop oor:name="BindingURL" oor:op="fuse" >< value >vnd.sun.star.script:Библиотека.Модуль.ItIsNewDocumentWow?language=Basic&location=application< /value >< /prop >< /node >< /item >
• Сохраняем файл.

PS. Данный механизм мы используем для построения этого функционала.

UPD. К сожалению, Решение 2 в OpenOffice 3.0 не работает - иначе устроено хранение настроек по сравнению с версией 3.3.

UPD 2. Решение 3 (общее программное решение, найдено на community.i-rs.ru)
Код функции:

Sub AttachBasicMacroToEvent(EventName as String, SubPath as String)
  Dim PropValue(1) as new com.sun.star.beans.PropertyValue
  Dim DocEvents As Object
  PropValue(0).Name = "EventType"
  PropValue(0).Value = "Script"
  PropValue(1).Name = "Script"
  PropValue(1).Value = "vnd.sun.star.script:" & SubPath & "?language=Basic&location=application"
 
  oGEB = CreateUnoService("com.sun.star.frame.GlobalEventBroadcaster")
  oEvents = oGEB.getEvents()

  oEvents.ReplaceByName(EventName, PropValue())
End Sub

Вызов функции осуществляется так (для нашего случая - создание нового документа): AttachBasicMacroToEvent("OnNew", "Библиотека.Модуль.ItIsNewDocumentWow")

Клиент Notal System - перехват событий в офисных программах

Постановка проблемы
Большинство документов СЭД (системы электронного документооборота) редактируются в офисных программах - нас интересуют ставшие стандартом де-факто Ms Office и Open Office. В них требуется научиться делать следующие вещи:

• Перехватывать закрытие документа
• Перехватывать печать документа
• Отличать документ, полученный из Notal System, от просто документа на локальном компе
• Различать взятые из Notal System документы по типу - взятые на просмотр и взятые на редактирование
• Различать, из какой именно базы Notal System взят документ - пользователь может с одного компа работать с несколькими базами

Если мы можем перехватить печать документа и можем понять, что он получен из Notal System, то дальше можем после печати сохранить новую версию в СЭД или более интересные штуки типа логирования печати и т.п.

Требования к опознанию документов как взятых из СЭД Notal System
Считаем, что вмешиваться во внутреннюю структуру документа мы не можем - для офисных документов это в принципе возможно, но хотелось бы иметь механизм, который бы не зависел от типа файла и мог бы быть распространен на другие типы файлов (к примеру, на инженерную графику - t-flex и т.п. имеют встроенные языки программирования, так что в будущем и на них можно портировать те же механизмы.
То есть у нас имеется не так много способов различать файлы:

• Складывать взятые из СЭД файлы в определенную папку (или структуру папок)
• Записывать имя файла в БД на локальном компе и потом сверяться с этими записями
• Всю нужную информацию кодировать в имени файла

Поскольку СЭД Notal System работает в веб-интерфейсе, то не всё подконтрольно: разные браузеры складывают документы в разные папки, причем не всегда это можно настраивать. Кроме того, использовать локальную БД нежелательно, поскольку это переусложнит клиентскую часть и может потеряться гибкость веб-технологий.
Опознавать документ будем по имени файла, причем это опознание должно быть устойчиво к некоторым модификациям имени файла которые делают браузеры: к примеру, при повторном скачивании файла браузеры по-разному модифицируют его имя - Opera добавляет в конце " (1)", " (2)" и т.д., Mozilla Firefox добавляет "-1", "-2" и т.д.

Структура имени файла документа из Notal System
Различать разные базы Notal System будем по ключевому числу NN - целое трехзначное число, желательно простое или произведение двух двузначных простых чисел. Зададим его и тогда формат взятого из Notal System документа будет таким (жирным выделены константные части:

iiii_vvvE=AAAAAAABBB=

где iiii - id документа в Notal System (переменое число знаков, цифры, не может начинаться с 0),
vvv - номер версии документа (переменое число знаков, цифры, не может начинаться с 0),
E - указатель на то, что документ взят на редактирование; для взятых на просмотр ставим знак V,
AAAAAAA - случайное число 7 цифр с ведущими нулями, если требуется. Должно быть больше 1000.
BBB - проверочный код, 3 цифры с ведущими нулями, если требуется; вычисляется по формуле BBB = AAAAAAA mod NN, т.е. остаток от деления AAAAAAA на ключевое число NN.
Знаки "_" и "=" задают структуру имени файла. Всё, что идет после второго знака "=", при аналие отбрасывается.
Структура имени файла позволяет узнать id документа и узнать, взят ли документ на редактирование или только на просмотр. Номер версии документа для работы программы не важен, но полезен для пользователя. Случайное число в имени файла гарантирует, что дважды взяв документ из СЭД мы получим разные имена файлов. Проверка соотношения чисел AAAAAAA и BBB позволяет с большой долей надежности установить базу Notal System, из которой взят документ.

Расчет вероятности ложного опознания базы-источника документа
Считаем, что сама специфическая структура имени файла однозначно указывает на то, что файл взят из СЭД Notal System. Пусть на локальном компьютере пользователя зарегистрированы две базы с ключевыми числами NN₁ и NN₂. Тогда вероятность того, что одновременно выполняются два соотношения

• BBB = AAAAAAA mod NN₁
• BBB = AAAAAAA mod NN₂

равна 1/НОК(NN₁, NN₂), где НОК - наименьшее общее кратное. Поскольку мы выбираем NN₁ и NN₂ простыми, то формула упрощается до 1/(NN₁*NN₂). Поскольку оба числа трехзначные, то полученная вероятность гарантированно меньше 10^-4 и почти всегда меньше 10^-5, что позволяет нам не заботиться о ложных срабатываниях (по крайней мере в первой версии клиентской части Notal System).

Необходимые доработки серверной части Notal System

• Добавить в раздел общей информации системы ключевое число
• Создать механизм задания ключевого числа - вручную или случайно из списка подходящих простых чисел (контроль того, что все эти числа для установленных на нашем сервере баз различны, осуществляем пока вручную)
• Написать функцию API, которая запрашивает у базы ее ключевое число (понадобится для конфигурирования ini-файла клиента)

Информация в ini-файле на машине клиента
В файле notalconfig.ini, расположенном в папке C:\NotalSystem\conf\, раздел каждой базы (имя раздела [base*], где "*" означает любой текст без пробелов) должен содержать следующие строки:

URL = http://test.notalsystem.ru/ - веб-адрес базы Notal System
KeyNumber = 449 - ключевое число
Name = "Тест" - название базы: произвольный краткий текст, нужен для показа в диалоговых окнах и т.п.

Сейчас считаем, что пользователь руками редактирует ini-файл, позже можно сделать конфигуратор клиента.

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

• Перехватываем закрытие документа и определяем базу
  • Если он взят на редактирование и изменен, то предлагаем отправить новую версию документа в СЭД
• Перехватываем печать документа и определяем базу
  • Если он взят на редактирование и изменен, то печатаем и после этого отправляем новую версию документа в СЭД. Вариант: спрашиваем пользователя, делать ли это, если нет, то не отправляем новую версию, но и не печатаем.
  • Если он взят на просмотр и изменен, то не печатаем. Вариант: предупреждаем об этом пользователя, проверяем, что он имеет право редактировать этот документ, предлагаем ему сохранить отредактированную версию в СЭД (тут используется механизм, который мы используем для добавления новых версий документов из 1С, т.е. не беря предварительно документ на редактрирование.
  • Если документ не был изменен, то печатаем без каких-либо иных действий.

Позже к этому функционалу можем добавить логирование печати (потребуются соответствующие функции API).

Особенности реализации перехвата событий в Ms Office
Нас интересуют только Ms Word и Ms Excel. В этих программах перехват событий организован по-разному.
В Excel подключенная надстройка загружается как рабочая книга, так что в контейнере ThisWorkbook размещаем предопределенную функцию Workbook_Open(), а в ней включаем перехват событий через специальный класс.
В Word в шаблоне, расположенном в папке Word\STARTUP, создаем модуль AutoExec с процедурой MAIN(), которая запускается при загрузке Word. Перехват событий в ней организуется аналогично Excel.

Особенности реализации перехвата событий в Open Office
В Open Office для всех типов файлов работает единый механизм, организация перехвата событий там требует отдельного описания.

Распечатка документов из СЭД: проблема несовпадения

У нас на заводе автоматизированы несколько бизнес-процессов на Notal System - системе управления задачами и документооборотом. Вот в одном бизнес-процессе - ремонте модельной оснастки - обнаружилась засадливая проблема. Последовательность действий такова (упрощенно):

• все начинается с создания дефектной ведомости - документа с описанием проблемы и необходимых действий (текстовый документ в формате Open Office)
• создается задача и к ней цепляется дефектная ведомость
• дефектная ведомость распечатывается и подписывается всяким начальством
• задача передается на исполнение
• ...(потом много чего происходит)...
• после выполнения работ задача поступает в ОТК, который открывает дефектную ведомость и по ней проверяет, все ли работы выполнены.

И вот тут обнаруживается проблема - иногда оказывается, что дефектная ведомость пуста. То есть на бумаге-то она заполнена, а в электронном виде - нет. Все прелести электронного документооборота - псу под хвост.
В чем причина этой проблемы? Чисто технически, дефектная ведомость создается по шаблону в Notal System, то есть заполняется минимальный набор реквизитов, а собственно содержательная часть - дефекты и необходимые работы - являются неформализованной информацией и пишутся технологом в текстовом редакторе. То есть созданный в СЭД (системе электронного документооборота) по шаблону документ (файл) открывается на редактирование, редактируется, распечатывается и в СЭД отправляется новая версия. Вот в этой последней последовательности действий возможны ошибки:

• документ взят на редактирование, отредактирован, распечатан, но новая версия в СЭД не отправлена (в СЭД такой документ будет виден как взятый на редактирование)
• документ взят из СЭД на просмотр, отредактирована локальная копия, распечатана. В СЭД тогда будет только первоначальная, пустая по сути, редакция документа.

Что с этим делать? Вариантов несколько.
Радикальный вариант. Полностью отменить бумажные документы и перейти на электронные. Не годится по следующим причинам:

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

В общем, отметаем это решение за излишнюю радикальность.
Автоматизированное порождение конечного документа. Это как распечатка накладной из 1С: там все заполняешь в диалоговом окне, а потом нажимаешь на кнопку [Печать] и формируется печатная форма. Решение тоже не годится - слишком уж вариативно содержание дефекой ведомости, там могут быть и таблицы, и эскизы. То есть если бы дефектная ведомость была бы хорошо формализуемым документом, то она и порождалась бы из системы планирования производства, а не из СЭД. В конце концов, всегда есть такие категории неструктурированных документов - те же письма, к примеру. Надо решать задачу на уровне СЭД при условии, что документ будет редактироваться пользователем в текстовом редакторе или электронных таблицах - грубо говоря, в Ms Office или Open Office.
Административные и воспитательные меры. Что если воспитать/убедить/запугать пользователей, чтобы они отрабатывали правильную последовательность действий до конца? Это сделать надо, конечно, но человек вообще склонен делать ошибки - одна эта мера явно недостаточна.
Модификация функции печати. Что если при печати перехватывать это событие и автоматически обновлять версию документа в СЭД? Вот это - решение! Надо сделать следующее:

• в редакторе опознавать документ как взятый из СЭД (мы же не хотим, чтобы пользователь не мог нормально работать с файлами на своем локальном компе);
• при открытии в СЭД документа в режиме просмотра запретить его редактирование в текстовом редакторе - то есть документ распечатать можно, а изменить и потом распечатать - нельзя;
• при печати документа если он взят на редактирование в СЭД сохранять в ней новую версию документа. То есть распечатал - документ закрылся и отправился в СЭД.

Осталось научиться перехватывать события печати и открытия документа в Open Office (в Ms Office умею), и запрограммировать клиентскую часть Notal System.

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

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

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

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

Редактирование набора критериев выполняется в отдельном окне.

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

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

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

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

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

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

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

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

Все это надо разместить в интерфейсе пользователя с правом редактирования (по аналонии со сменой пароля).

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

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

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

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

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

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

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

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

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

• автору или владельцу задачи полезно узнать, что его задача отрицательно завершена
• исполнителю полезно узнать, что задача передана другому
• возможным исполнителям полезно узнать, что в накопителе (ждущем состоянии) появилась новая задача

Все это решается механизмом внутренних уведомлений системы с возможностью отправлять эти уведомления вовне по e-mail или через SMS.

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

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

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

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

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

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

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

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

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

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

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

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

• Движение
• Служебный
• Пользовательский

Выбираем один или несколько типов комментария.

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

• Активное
• Ждущее
• Финальное (без разделения)
• Финальное положительное
• Финальное отрицательное
• Любое состояние
• (Конкретное состояние)

Выбираем один вариант. При движении задачи тем самым мы можем отследить попадание задачи в определенное состояние (или состояние определенного типа), но не можем отследить уход задачи из данного состояния.

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

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

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

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

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

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

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

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

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

Можно выбрать несколько пунктов или не выбирать ни одного.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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