в качестве примера, взял файлы из каталога ~/datamodels/2.x/itop-change-mgt/ скопировал в свой каталог /itop-citicket-mgmt, и переименовал в:
datamodel.itop-citicket-mgmt.xml
module.itop-citicket-mgmt.php
ru.dict.itop-citicket-mgmt.php
теперь в файле datamodel.itop-cmdb-ticket.xml требуется выкосить все лишнее и добавить нужное.
Правильным ли путем я пошел?
Лишнее это количество статусов жизненного цикла. Требуется их сократить до 3: открыта(новый), в работе(реализация), выполнена(закрыт).
Убрать вкладки: “наряды на работу”,“связанные изменения”, “связанные инциденты”, “связанные проблемы”, “дочерние изменения”.
Да, я знаю что в модуле управления изменениями есть тикет на изменения, но он представляется нашему руководству пока сложным, т.к. весь этот жизненный цикл проходит в заявке JIRA, дублировать это в тикете iTop пока не хочется, а фиксировать изменения в КЕ надо. поэтому требуется разработать новый упрощенный тикет.
в модуле управления изменениями, есть три вида изменения(нормальное, стандартное, экстренное), туда же хочется добавить новый под именем “Фиксация изменений”
это я назвал так тикет, который требуется разработать.
цель данного тикета, упростить процедуру фиксации изменений КЕ в CMDB.
процедура фиксации изменений выглядит так:
Регистрация. Прикладной администратор, в рамках заявки в jira, создает «тикет» в itop. В модуле «Управление изменениями», создает «Новый новый тикет». Заполнение вкладки свойства:
· Название запроса – Указывается тема из заявки в JIRA.
· Указывает номер заявки JIRA
Заполнение вкладки «КЕ». На основе выполненного анализа (см. Регламент внесения изменений п.5.7), прикладной администратор добавляет объекты из базы CMDB. Если требуемого объекта нет в базе, прикладной администратор регистрирует новый объект:
Ø В модуле «Управление Конфигурациями» нажать «Создать КЕ» (кнопка должна быть в открытом окне выбора объектов)
Ø Нажать «Применить»
Ø Система отправит уведомление Менеджеру Конфигураций о регистрации нового объекта
После того, как новый объект зарегистрирован, его требуется добавить в список «КЕ» тикета, указать статус (добавление, изменение, удаление). Нажать кнопку «Создать». Назначить исполнителем заявки себя.
1.2 Внесение изменений в базу CMDB. Получив допуск к работам, ПА переводит запрос в статус «Реализация» (Другие действия>Реализовать). После окончания выполнения работ, вносит изменения в атрибуты объектов, которые были добавлены во вкладке КЕ запроса на изменения, созданного в п. 4.1 «Регламента Управления Конфигурациями». Система отправляет уведомление команде прикладных администраторов и сопровождению сервисов, об изменении версий и других атрибутов объектов.
Вот в рамках этой процедуры и нужен новый тип тикета.
Вы можете помочь с его разработкой?
У вас есть два варианта: “свой велосипед” и “городской трамвай”. Выбор зависит от дальнейших планов вашего руководства по переходу к планированию и учету изменений в iTop.
Вариант “свой велосипед” - крути педали, пока не дали, заключается в разработке собственного велосипеда для передвижения из А в Б. То есть вы пишете модуль, который работает так, как нужно в сегодня. Завтра вам нужно поехать на этом велосипеде чуть дальше или заехать в точку В, и вы будете его переделывать. И так постоянно.
Вариант “городской трамвай”. Он уже есть и ходит по маршруту, а вы можете входить и выходить там, где хотите. Да, иногда придется немного пройтись ножками. Но когда на маршрут поставят новый более современный трамвай, вы к этому будете готовы)).
Если ваше руководство не планирует более глубокое использование iTop, то делайте велосипед. Начали вы правильно.
Если есть дальнейшие планы на iTop, берите стандартные изменения, немного поправьте переходы по статусам (минуя планирование) и скройте лишние поля и вкладки, раз они так усложняют жизнь. Главное - модель данных останется на месте.
@igsao10 самое главное забыл: если вы сейчас выберете первый вариант, то перейти на второй без потерь скорее всего не получится. Потому настоятельно рекомендую использовать стандартные изменения, просто спрятав всё лишнее.
@vladimir я с Вами полностью согласен, но к сожалению iTop у нас используется только как система управления конфигурациями, а использование остального функционала видится туманно…поэтому придется выбрать первый вариант, если не представляется возможным сократить количество переходов по статусам “стандартного изменения” или сделать, чтобы некоторые переходы выполнялись автоматически…если я не ошибаюсь, здесь на форуме, стоял вопрос автоматического назначения тикета…
Здесь define не нужен. У вас же установлен модуль itop-change-ngmt-itil?
Кроме details нужно переопределить list и, возможно, search, если там выводятся поля, которые вам не нужны. Можно переопределить сразу весь presentation.
После этого прогоняете toolkit, исправляете ошибки и снова toolkit.