Вот он тот финальный вариант HelpDesk который у меня получился. Использовался Drupal и местами самописанный код. Уже писал — HelpDesk на Drupal часть 1, HelpDesk на Drupal часть 2. И так начнем понемногу.
Стартовая страница написана отдельно от основного хелпдеска, играя роль страницы основного портала где система электронной поддержки является её частью, то есть обычным сервисом.
Суть состоит в следующем, при входе на портал мы определяем от куда пришел к нам пользователь, в моём случаи это Ставрополь и КМВ, далее мы выводим в зависимости от локации сообщение (новость), и собственно ссылки на сам HelpDesk.
Всё это реализовано для локального портала.
При нажатии на ссылку пользователь попадает в хелпдеск своего региона и работает там.
В хелпдеск другого региона он попасть не может, так как это запрещено, и автоматически будет переадресован в свой регион.
Дальше будем использовать Drupal. Как видно на картинке простой друпал со стандартной темой.
Так как в качестве авторизации пользователей я использую Active Directory мне пришлось сделать так чтобы при первом входе на сайт пользователю автоматически была создана учетная запись согласно его учётки в Active Directory.
Автоматически создавать пользователя при входе и назначать ему определённую группу можно с помощью модуля Auto Assign Role.
После чего пользователь может начинать работать в системе.
У себя я делю всех на три групп:
- Пользователи
- Исполнители
- Администраторы
Пользователи создают заявки, исполнители отрабатывают, а администраторы следят.
Интерфейс управления заявками выглядит одинаково. Реализовано это с при помощи модуля Support.Ничего сложно в его настройке так нет, если возникнут вопросы пишите в комментариях.
Интерфейс управления заявками позволяет сортировать заявки по статусам для удобства. По умолчанию выводятся открытые заявки которые могут иметь статусы: новая, принята к исполнению и отложена.
Исполнитель всегда может обратиться к нужной ему заявке и внести необходимые изменения. Форма создания заявки стандартная, состоит из краткого описания проблемы и дополнительного описания.
Для Ставропольских пользователей присутствую категории заявок, если пользователь указывает категорию то заявка автоматически назначается определённому исполнителю, на КМВ исполнители сами принимают заявки по мере того кто может выполнить максимально быстро.
После выполнения заявки исполнитель устанавливает статус «Выполнена», после чего у пользователя данная заявка отображается как отработанная и пользователь подтверждая то что работа выполнена закрывает заявку устанавливая ей статус «Закрыта». Если же пользователь забыл закрыть заявку а она висит как выполнена, то заявка автоматом закрывается по прошествии семи дней.
Вот значит, так же реализована система уведомлений по электронной почте, личный профиль и рейтинг исполнителей.
Вот вроде вкратце изложил, если есть вопросы пишите в комментариях, отвечу в всем. В планах сделать ещё SMS уведомления исполнителей о новых заявках, если реализовать получится обязательно напишу, уже кстати нашел 2 способа реализации этой проблемы.
Занялся настройкой модуля модуля Support. Столкнулся с несколькими проблемами.
1. Не нашел где перевести статусы тикетов
2. Не отобразились дополнительные поля в форме заявки при добавлении их через CCK (ну и интересно как они по категории распределяются автоматом исполнителям).
3. Не удалось реализовать рейтинг исполнителей.
4. Пользователи автоматом импортируются и авторизуются через AD. С помощью модуля Realname на сайте отображаются их имена в развернутом виде, а не по логину. Не получилось привязать realname к Support.
Может сможете подсказать. Зарание спасибо.
1 — статусы переводятся в базе в таблице support_states
2 — я использовал таксономию для дополнительных полей, и заявки у нас видны для всех исполнителей, они уже сами принимают тек которые относятся к их служебным обязаностям
3 — рейтинг пользователя реализовывается через UserPoints и Fivestar
4 — тут скорее всего в настройках Realname что то, Rebuild realname делал ? (user/realname/recalc), возможно посморти еще права доступа
Спасибо, перевел статусы.
Через таксономию поля добавились (интересно всё же через CCK можно это сделать?)
Похоже, что поддержка RealName пока не реализована в модуле (придётся довольствоваться логинами)
Не получилось расставить права так чтобы пользователи могли закрывать выполненные заявки. У меня сейчас расставлены права след образом:
Пользователи:
1. access tickets
2. можно выбрать приоритет
3. создание запросов
4. удаление своих запросов
5. редактирование своих запросов
Исполнители:
то что и у пользователя+:
1. назначение запросов себе
2. просмотр запросов других пользователей
Ну и админ.
Исполнители меняют статус заявок, а пользователи не могут…..
Еще на сколько я понял статусы заданий выполняются через комментарии или через редактирование самого тикета, что не очень то и удобно.
У меня у пользователей выставлены: access tickets, can select priority, can select state, create tickets.
У исполнителей: access tickets, can administer state, can assign tickets to self, can select client, can select priority, can select state, view other users tickets.
А еще момент я добавил еще один статус «Выполнена» который выставляет исполнитель после отработки заявки, а потом пользователь проверяя ставит «Закрыта»
Разглядывая общую схему сталкиваюсь с вещами, которые, наверное, очень полезны при правильном системном подходе к обработке заявок, но интуитивно неочевидны.
Свойства заявки «срочность», «статус» и «приоритет» — с этими всё ясно.
А что такое «влияние»? Можно пример практического использования этого поля?