Добрый день
Необходимо, чтобы пользователь из портала мог создавать как UserRequest, так и Incident. В конфигурационном файле есть опция portal_tickets - в случае задания одного типа тикета все работает, а в случае выбора обоих типов (запрос и инцидент) нет возможности выбора, по умолчанию создается UserRequest.
Подскажите, как можно реализовать данную возможность?
Смотри itop/portal/readme.txt, там описаны шаги по добавлению новых типов тикетов на портал. Конфиг portal_tickets - это первый шаг. Кроме этого есть ещё с десяток констант, которые нужно определить. Определять их можно в itop/portal/index.php, но я бы рекомендовал вынести все константы в отдельный конфиг-файл портала и подключить его к index.php.
Просто такой тип тикета уже ж есть в системе и успешно отрабатывает. Не решали подобную задачу? В результате у пользователя будет возможность выбора типа тикета перед типом услуги?
В системе он есть, но чтобы он стал доступен через портал, нужно его “включить”, как написано в readme.txt: How to add a type of ticket (example: Incident) и т.д. 7 пунктов.
Решал и решил. У меня на портале создаются два кастомных типа тикетов вместо UresRequest.
Не совсем очевидно: когда ты создаёшь подкатегории услуг, там есть поле Тип запроса (request_type). Этот тип запроса и определяет то, что будет создаваться на портале (Incident или User Request) при выборе этой подкатегории. Отдельного поля выбора типа тикета нет.
Какие значения можно присваивать константам, описанным в itop\portal\readme.txt, можно посмотреть в itop\datamodels\2.x\itop-request-mgmt-itil\datamodel.itop-request-mgmt-itil.xml.
How to add a type of ticket (example: Incident)
- Add it to the list of supported tickets classes: itop-config.php/portal_tickets
- Define PORTAL_SET_TYPE_FROM (if not already done) as the attribute of ServiceSubcategory, that will define the request type, depending on the user selection
- Map the different values of this request type (in class ServiceSubcategory) to the supported ticket classes
YOU MUST MAKE SURE THAT ANY OF THE VALUE HAS A MAPPING SO AS TO EXCLUDE SUBCATEGORIES IF THE CORRESPONDING CLASS ARE NOT ENABLED IN THE CONFIG. - Make sure that the queries PORTAL_SERVICE_SUBCATEGORY_QUERY and PORTAL_VALIDATE_SERVICESUBCATEGORY_QUERY will not exclude the expected type
- Define the various constants for this class (PORTAL__XXXX).
- Adjust PORTAL_TICKETS_SEARCH_CRITERIA. Those criteria are common to all types of tickets. Giving too many criteria can lead to confusion.
- Test, test and re-test!!!
- Отредактировали в config-itop.php:
‘portal_tickets’ => ‘UserRequest’, ‘Incident’, - В web интерфейсе в разделе Управление услугами - Подкатегории услуг создал записи с типами запроса Incident и UserRequest.
3…6 Не понятно где это искать - толи в Web, толи в php/xml коде…
Поясните плиз
- portal_tickets - CSV list of classes supported in the portal.
'UserRequest', 'Incident'- не правильно, ‘UserRequest,Incident’ - правильно. - Уже сделано.
- Ты сделал.
- Искать в
itop\datamodels\2.x\itop-tickets\datamodel.itop-tickets.xml, но тебя это не должно касаться, если ты это не менял. - Дальше нужно определить константы
PORTAL_INCIDENT_ЧТО-ТО-ТАМ, можно прям в index.php портала, но если у тебя стоит модульitop-incident-mgmt-itil, то они уже должны быть определены. - Ещё одна константа из п.4, но её трогать тоже не обязательно.
В общем, похоже тебе нужно поправить п.1.
Версия iTop 2.1.0?
Да, iTop 2.1.0
Тупил в мелочи - да, все заработало. Спасибо большое. Жаль, что у пользователя при создании тикета не спрашивает тип (запрос, инцидент) - если юзер по подкатегории не разберется и направит заявку не в ту очередь, то в админке потом нельзя уже будет сменить тип тикета.
Ну тут есть три варианта:
- Более конкретно называть подкатегории и использовать поле Описание (оно тоже выводится на портале). Подключение нового телефона и Не работает телефон вполне однозначно трактуются как Запрос и Инцидент соответственно.
- Использовать услуги с одними типами тикетов, т.е. для инцидентов одна услуга, для запросов - другая.
- Позволять пользователям портала создавать только запросы, а инциденты на основе поступивших запросов (только если инцидент реально присутствует) пусть открывают инженеры. В этом случае функционал используется наиболее полно и привильно. Несколько запросов могут быть вызваны одним инцидентом, что будет отражено через связи между тикетами. При изменении и решении инцидента будет происходить автоматическое решение запросов.
Сложно рассуждать, не зная специфики вашей компании. У нас используется третий вариант.
Хотел приспособить четвертый вариант - при выводе подкатегорий в портале отделять их заголовками, как в случае отображения открытых заявок. Т. е.:
Запрос:
…подкатегории…
Инцидент:
…подкатегории…
Формируется все это в /portal/index.php:
function SelectServiceSubCategory()
Только вот не придумаю как лучше реализовать… Менять sql запрос или при выводе определять класс тикета. Не смотрели в эту сторону, не подскажете в таком варианте решение?
Думаю, лучше поправить SelectServiceSubCategory(). Я бы в блоке while($oSubService = $oSet->Fetch()) вместо непосредственного добавления html на страницу сформировал бы две переменные с html-фрагментми (запросы и инциденты), которые после окончания while вывел бы у нужном порядке.
Именно так и реализовал. Спасибо
В случае такой организации инженерам приходится самим копировать/заполнять поля Incident’а или можно как-то организовать перенос заполненных полей из UserRequest?
А какие поля можно было бы копировать? Мне кажется, таких нет.
К примеру, пришел запрос от пользователя “Не могу попасть в Одноклассники”. Инженер проверил, что дело не в кривых руках пользователя, который неправильно набирает адрес сайта, а просто лежит канал, и после этого регистрирует инцидент “Упал линк до провайдера”. Пришёл еще один запрос “Не могу проверить почту”, и инженер привязывает его к созданному ранее инциденту. Дублирующихся полей нет, поскольку запрос и инцидент используются для разных целей и дополняют друг друга. Пользователи не знают и не должны знать об упавшем линке, а IT отделу все равно, на какие сайты не могут попасть пользователи. После восстановления линка инженер закрывает инцидент, а все привязанные запросы закрываются автоматически.
Когда инцидент и запросы связаны, в них отображаются ссылки друг на друга.
Возник еще один вопрос: как Incident’у установить статус rejected. Для UserRequest статус rejected устанавливается после статуса waiting for approval. А как быть с Incident’ом? В моделе данных он описан, а как его в web интерфейсе назначить - так и не нашел…
У меня в стардатрном iTop 2.1.0 для статуса инцидента такие варианты: ENUM('assigned','closed','escalated_tto','escalated_ttr','new','pending','resolved'), По умолчанию: "new", Null НЕ разрешён. Модуль ITIL Incident Mgmt.