BlizD
Развитие подсистемы "Регистрация обращений пользователей" + "Проекты"
Дорый день. Коллеги, кто хочет/может подхватить - буду только рад, т.к. основная цель - перестать морочиться с накатыванием обновлений и иметь максимально "типовую" конфигурацию (многие в чате пишут "не хватает" и многое из этого уже есть реализовано): У себя используем программу не только как задачи для программистов, а сначала регистрируем обращение от пользователя, его обрабатівает первая линия и или закрывает как как свою задача (консультация или помощь в настройках и т.п.) или создает задачу на программиста (разработчика), по которой он отчитывается. Из-за большой нагрузки в последнее время - самостоятельно дорабатывать (развивать) не успеваем (сейчас её развитие заморозили), по-этому приняли решение выложить свою рабочую конфигурацию (обновлена до вер. 1.0.4.038) "как есть" и предложить сообществу поучаствовать в развитии с последующим включением в типовые релизы.
Кратко, что сейчас в ней есть и работает:
- ws для регистрация обращения пользователя из любой другой программы (саму обработку - приведу в универсальный (независимый) вид и выложу)
- возможность саморегистрации нового пользователя (с двухфакторной проверкой по AD (пароль) и через e-mail)
- Для каждой конфигурации - список подсистем (иногда полезно понимать какая подсистема "хромает" и по ней больше всего обращений)
- Рассылки по "обращениям" - подключены к справочнику "Шаблоны писем" (БСП)
- В обращении можно указать несколько конфигураций и несколько "плановых" исполнителей. На основании этих данных - создаются задачи (задача в разрезе одной конфигурации и одного исполнителя (тут штатное поведение конфигурации)). Пользователи (заявители) не могут "нарезать" задачи исполнителям - это работа администратора.
- Как только все задачи по обращению в статусе "Готово" - обращение автоматом переходит в статус "Готово" и выполняется рассылка оповещений.
- Заявитель видит все задачи по его обращению и их статусы. (разграничение прав "в иерархии" - в данный момент - хромает - список отображает только в плоском виде).
- В работе с почтой - реализован парсинг "префикса" номера задачи (сделано для того, чтобы по теме письма определить "это задача" или "это обращение"
- Есть справоник "Направление" - по задумке - это укрупненный вид работ 10, Есть ws по которому отдается консолидированный отчет о занятости исполнителей (в фактических часах) в разрезе "Организация/Дивизион/Направление/Исполнитель" (у нас такая орг структура).
Задел подсистемы "Управление проектами" (описываю основные вехи "как задумывалось"): 1 Внесено понятие Проектной команды: отдельно методологи и разработчики. Один из каждой команды "старший" и он участвует в подготовке ТЗ. 2 Точки входа в "Проект" - две: из обращения от пользователя или независимое создание нового проекта. 3 Новый проект должен пройти составление и согласование ТЗ 4 После того, как старший команды разработчиков "подпишется" под ТЗ проект считается "Утвержденным" и берется в работу - можно создавать задачи на исполнителей (это участники команды разработчиков). 5 По данной подсистеме - есть только заготовки метаданных (без форм)
Тем, кто подхватит: Все новые объекты и добавленные реквизиты (в существующих объектах) имеют префикс "слм_". Вклинивание в существующий код - обрамлено коментариями "кто и когда"
ссылка на скачивание cf: тыц
PS Описания подсистем в ближайшее время оформлю в гугл-докс и прикреплю к этой задаче (там более детально опишу какие возможности тут есть) PPS Если есть вопросы/замечания/предложения по данной конфигурации - задавайте - буду отвечать
Кратко, что сейчас в ней есть и работает:
- ws для регистрация обращения пользователя из любой другой программы (саму обработку - приведу в универсальный (независимый) вид и выложу)
Обработку не получается приести полностью к автономному виду (там необходим общий модуль по работе с Json, т.к. реализовывалась под "древнюю" конфигурацию, которая не умеет работать с Json).
Ссылка на скачивание: тыц