Добрый день!
Стоит задача разработки нового вида тикета, с помощью которого будут выполняться изменения в базе CMDB.
Жизненный цикл тикета: Создан>в работе>выполнена.
Так, как я не являюсь программистом, прошу помощи у Вас форумчане.
С чего следует начать разработку?
Как я понимаю, исходник будет в виде xml?
Помогите пожалуйста
К счастью, такой тип тикетов уже есть - Стандартные изменения.
Здравствуйте, Владимир!
Да, он есть, но мне нужно его модифицировать.
в качестве примера, взял файлы из каталога ~/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 требуется выкосить все лишнее и добавить нужное.
Правильным ли путем я пошел?
Что там лишнее?
Тикет Изменения это и есть тикет, с помощью которого выполняются изменения в CMDB.
Лишнее это количество статусов жизненного цикла. Требуется их сократить до 3: открыта(новый), в работе(реализация), выполнена(закрыт).
Убрать вкладки: “наряды на работу”,“связанные изменения”, “связанные инциденты”, “связанные проблемы”, “дочерние изменения”.
Да, я знаю что в модуле управления изменениями есть тикет на изменения, но он представляется нашему руководству пока сложным, т.к. весь этот жизненный цикл проходит в заявке JIRA, дублировать это в тикете iTop пока не хочется, а фиксировать изменения в КЕ надо. поэтому требуется разработать новый упрощенный тикет.
в модуле управления изменениями, есть три вида изменения(нормальное, стандартное, экстренное), туда же хочется добавить новый под именем “Фиксация изменений”
Хотя пихать его в тикет модуля управления изменениями будет не правильно…лучше вывести как отдельную кнопку “Тикет фиксации изменений”
Что такое “Тикет фиксации изменений”?
это я назвал так тикет, который требуется разработать.
цель данного тикета, упростить процедуру фиксации изменений КЕ в CMDB.
процедура фиксации изменений выглядит так:
Регистрация. Прикладной администратор, в рамках заявки в jira, создает «тикет» в itop. В модуле «Управление изменениями», создает «Новый новый тикет». Заполнение вкладки свойства:
· Название запроса – Указывается тема из заявки в JIRA.
· Указывает номер заявки JIRA
Заполнение вкладки «КЕ». На основе выполненного анализа (см. Регламент внесения изменений п.5.7), прикладной администратор добавляет объекты из базы CMDB. Если требуемого объекта нет в базе, прикладной администратор регистрирует новый объект:
Ø В модуле «Управление Конфигурациями» нажать «Создать КЕ» (кнопка должна быть в открытом окне выбора объектов)
Ø Нажать «Применить»
Ø Система отправит уведомление Менеджеру Конфигураций о регистрации нового объекта
После того, как новый объект зарегистрирован, его требуется добавить в список «КЕ» тикета, указать статус (добавление, изменение, удаление). Нажать кнопку «Создать». Назначить исполнителем заявки себя.
1.2 Внесение изменений в базу CMDB. Получив допуск к работам, ПА переводит запрос в статус «Реализация» (Другие действия>Реализовать). После окончания выполнения работ, вносит изменения в атрибуты объектов, которые были добавлены во вкладке КЕ запроса на изменения, созданного в п. 4.1 «Регламента Управления Конфигурациями». Система отправляет уведомление команде прикладных администраторов и сопровождению сервисов, об изменении версий и других атрибутов объектов.
Вот в рамках этой процедуры и нужен новый тип тикета.
Вы можете помочь с его разработкой?
У вас есть два варианта: “свой велосипед” и “городской трамвай”. Выбор зависит от дальнейших планов вашего руководства по переходу к планированию и учету изменений в iTop.
Вариант “свой велосипед” - крути педали, пока не дали, заключается в разработке собственного велосипеда для передвижения из А в Б. То есть вы пишете модуль, который работает так, как нужно в сегодня. Завтра вам нужно поехать на этом велосипеде чуть дальше или заехать в точку В, и вы будете его переделывать. И так постоянно.
Вариант “городской трамвай”. Он уже есть и ходит по маршруту, а вы можете входить и выходить там, где хотите. Да, иногда придется немного пройтись ножками. Но когда на маршрут поставят новый более современный трамвай, вы к этому будете готовы)).
Если ваше руководство не планирует более глубокое использование iTop, то делайте велосипед. Начали вы правильно.
Если есть дальнейшие планы на iTop, берите стандартные изменения, немного поправьте переходы по статусам (минуя планирование) и скройте лишние поля и вкладки, раз они так усложняют жизнь. Главное - модель данных останется на месте.
Могу, но только так, как сам считаю правильным. Велосипедов по заказу тех, кому “пока сложно” мне и на работе хватает).
@igsao10 самое главное забыл: если вы сейчас выберете первый вариант, то перейти на второй без потерь скорее всего не получится. Потому настоятельно рекомендую использовать стандартные изменения, просто спрятав всё лишнее.
@vladimir я с Вами полностью согласен, но к сожалению iTop у нас используется только как система управления конфигурациями, а использование остального функционала видится туманно…поэтому придется выбрать первый вариант, если не представляется возможным сократить количество переходов по статусам “стандартного изменения” или сделать, чтобы некоторые переходы выполнялись автоматически…если я не ошибаюсь, здесь на форуме, стоял вопрос автоматического назначения тикета…
Об этом я и говорю. Всё это делается очень легко.
@vladimir наведите тогда меня на путь:) с чего начать? я так понимаю это тоже через собственный модуль будет делаться?
Да, любая доработка - собственный модуль. Разница в том, что будет использоваться существующий класс.
С этого мануала:
https://wiki.openitop.org/doku.php?id=2_2_0:customization:add-attribute-sample
А дальше аналогично:
После этого нужно будет немного поправить переходы в lifecycle.
Создал пустой модуль
Установил
Скопировал в свой модуль весь класс RoutineChange из файла itop/datamodels/2.x/itop-change-mgtm-itil/datamodel.itop-change-ngmt-itil.php
<?xml version="1.0" encoding="UTF-8"?><itop_design xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” version=“1.0”>
Change
…
<user_rights>
</user_rights>
</itop_design>
Сделал переопределение для presentation
...........
<presentation>
<details _delta="redefine">
<items>
<item id="functionalcis_list">
...........Здесь define не нужен. У вас же установлен модуль itop-change-ngmt-itil?
Кроме details нужно переопределить list и, возможно, search, если там выводятся поля, которые вам не нужны. Можно переопределить сразу весь presentation.
После этого прогоняете toolkit, исправляете ошибки и снова toolkit.
Убрал определение для класса
<class id="RoutineChange">
Убрал отдельное переопределение details и переопределил сразу весь presentation
<presentation _delta="redefine">
<details>
Открыл toolkit, вылезла ошибка:
Error: Error loading module "citicket": could not find node for class(id:RoutineChange) - Loaded modules: core,application,Service_ZK,authent-external,authent-ldap,authent-local,citicket
Dumping target doc - looking for 'RoutineChange'В module.itop-citicket-mgmt.php в зависимостях он указан?
Да модуль itop-change-mgmt-itil установлен/
в каком то из этих массивов я должен его указать?
// Components
//
'datamodel' => array(
'model.citicket.php'
),
'webservice' => array(
),
'data.struct' => array(
// add your 'structure' definition XML files here,
),
'data.sample' => array(
// add your sample data XML files here,
),