В общем пришлось создать для каждой организации (отдела) отдельный договор с заказчиком (как описано в implementation guide), т.е. сколько отделов, столько и договоров. Не понимаю почему нельзя было сделать унаследование от вышестоящей организации к нижестоящим (в учетных записях пользователей ведь это реализовано), чтобы не приходилось добавлять столько договоров, а ведь каждый из них еще нужно привязывать к услугам, короче говоря слишком много лишних действий получается.
Отделы в iTop: Команды или Организации?
Я вижу три варианта решения этой проблемы:
Вариант 1. Выбирать в поле Организация головную организацию, а инициатором - сотрудника конкретного отдела. Для того, чтобы в инициаторах выпадали сотрудники дочерних организаций (то есть всех отделов), нужно поправить запрос в модуле Tickets поле <field id="caller_id" xsi:type="AttributeExternalKey">
.
Было:
SELECT Person
WHERE org_id = :this->org_id
Стало:
SELECT Person AS p
JOIN Organization AS child ON p.org_id = child.id
JOIN Organization AS root ON child.parent_id BELOW root.id
WHERE root.id = :this->org_id
Теперь у нас один договор с головной организацией, но не видно отдел инициатора. Но потом для статистики конечно можно будет вытащить отдел, это не проблема.
Вариант 2. Обеспечить наследование нашими отделами услуг из договора с головной организацией. Для этого нужно поправить запрос в модуле UserRequest в поле <field id="service_id" xsi:type="AttributeExternalKey">
.
Было:
SELECT Service AS s
JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id
JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id
WHERE cc.org_id = :this->org_id AND s.status != 'obsolete'
Стало:
SELECT Service AS s
JOIN lnkCustomerContractToService AS l1 ON l1.service_id = s.id
JOIN CustomerContract AS cc ON l1.customercontract_id = cc.id
JOIN Organization AS child ON cc.org_id = child.id
JOIN Organization AS root ON child.parent_id ABOVE root.id
WHERE root.id = :this->org_id AND s.status != 'obsolete'
Теперь, выбирая отдел, нам доступен список услуг головной организации.
Вариант 3 (на мой взгляд самый правильный). Оставить всё как есть. Даже если у нас 10 отделов, это 10 договоров с одинаковым содержанием. Но добавление этих договоров - операция разовая, а однотипное содержимое позволяет легко подготовить данные для импорта CSV. Зато у нас появляется возможность для будущих манёвров. Например, разные услуги (персоны, документы, КЕ и др.) для разных отделов-заказчиков или более жесткие SLA для Бухгалтерии в момент расчета зарплаты.
UPD: Какой вариант модуля Service Management используется?
Установка Иерархии
Service Management for Service Providers и Simple Ticket Management.
Спасибо большое за решения.
Конечно я понимаю, что любой модуль можно изменить под свои нужды, но как конкретно это сделать, надо копать и разбираться, а Вы даете сразу готовое решение, спасибо большое.
Оставлю пока как есть, обсужу с руководством, может когда-нибудь заиспользую вариант №2
Перенёс в новую тему обсуждение отделов. Предыдущие сообщения здесь: Синхронизация с ad.
Про вариант с сервис провайдерами при установке было написано, что это более гибкая модель, поэтому и пал на нее выбор, а так я по сути не сравнивал.
Так то у нас своя служба техподдержки внутри организации, но никогда не знаешь, что будет завтра.
Почему спрашиваете? Можно наступить на какие-то грабли?
Я наступил. Выбрал не то, а потом учился модули переустанавливать)
Различия заключаются в том, как связаны Договоры, Услуги, КЕ и Заказчики.
Модуль для сервис-провайдеров предполагает оказание одних и тех же услуг разным заказчикам на разном оборудовании. Например, вы оказываете аутсорс техподдержку трём различным компаниям, и у каждой своя инфраструктура, сеть, оборудование и т.п.
Модуль для предприятий рассчитан на оказание услуг различным заказчикам, но на одном и том же оборудовании, как это обычно бывает с IT-отделами, работающими внутри компаний. Как пример, услуга “Новый пользователь 1С”, оказывается Бухгалтерии и Отделу кадров, но сервер 1С у них общий.
Вот схема для наглядности:
ItopEnterpriseAndProviderDifferences.pdf (13.8 КБ)
Здравствуйте, подскажите можно ли сделать Вариант 2. Обеспечить наследование нашими отделами услуг из договора с головной организацией при модели Service Management for Enterprises. Сделал переопределения itop-request-mgmt-itil но все равно ниже стоящая организация не видит услуги из головной.
SELECT Service AS s JOIN lnkCustomerContractToService AS l1 ON l1.service_id = s.id JOIN CustomerContract AS cc ON l1.customercontract_id = cc.id JOIN Organization AS child ON cc.org_id = child.id JOIN Organization AS root ON child.parent_id ABOVE root.id WHERE root.id = :this->org_id AND s.status != ‘obsolete’]]
Например есть организация в которой есть подчиненная организация Org_main -> Org1 договор и услуги на организацию Org_main но контак пользователя привязан на Org1. Как сделать так что бы пользователь у которого организация Org1 мог видеть и подавать запросы по услугам Org_main. Спасибо
<?xml version="1.0" encoding="UTF-8"?>
<itop_design
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0">
<classes>
<class id="UserRequest" _delta="must_exist">
<fields>
<field id="service_id" xsi:type="AttributeExternalKey" _delta="redefine">
<filter>
<![CDATA[SELECT Service AS s JOIN lnkCustomerContractToService AS l1 ON l1.service_id = s.id JOIN CustomerContract AS cc ON l1.customercontract_id = cc.id JOIN Organization AS child ON cc.org_id = child.id JOIN Organization AS root ON child.parent_id ABOVE root.id WHERE root.id = :this->org_id AND s.status != 'obsolete']]>
</filter>
<dependencies>
<attribute id="org_id"/>
</dependencies>
<sql>service_id</sql>
<target_class>Service</target_class>
<is_null_allowed>true</is_null_allowed>
<on_target_delete>DEL_MANUAL</on_target_delete>
<allow_target_creation>false</allow_target_creation>
</field>
</fields>
</class>
</classes>
</itop_design>
iTop 2.3.3-3159 инженерном интерфейсе не знаю как проверить пользователем тестирую /pages/exec.php/browse/services/tree?exec_module=itop-portal&exec_page=index.php
Зайдите под админом, попробуйте создать запрос от имени пользователя Org1 с нужной услугой.
А потому что для нового портала есть свои отдельные запросы для выбора услуг, подкатегорий и пакетов услуг, и каждый из них тоже нужно найти и поправить. Ищите в datamodel.itop-tickets.xml внутри <module_design id="itop-portal" ...>
.
Так как у меня головная организация 1 и все остальные наполняться с АД. Сделал просто выборку по ID не заморачивался с запросом.
<class id="ServiceFamily">
<scopes>
<scope id="all">
<oql_view><![CDATA[SELECT ServiceFamily AS sf JOIN Service AS s ON s.servicefamily_id = sf.id JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id WHERE cc.org_id = 1]]></oql_view>
<ignore_silos>true</ignore_silos>
</scope>
</scopes>
</class>
<class id="Service">
<scopes>
<scope id="all">
<oql_view><![CDATA[SELECT Service AS s JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id WHERE cc.org_id = 1 AND s.status != 'obsolete']]></oql_view>
<ignore_silos>true</ignore_silos>
</scope>
</scopes>
</class>
<class id="ServiceSubcategory">
<scopes>
<scope id="all">
<oql_view><![CDATA[SELECT ServiceSubcategory AS ssc JOIN Service AS s ON ssc.service_id=s.id JOIN lnkCustomerContractToService AS l1 ON l1.service_id=s.id JOIN CustomerContract AS cc ON l1.customercontract_id=cc.id WHERE cc.org_id = 1 AND ssc.status != 'obsolete']]></oql_view>
<ignore_silos>true</ignore_silos>
</scope>
</scopes>
</class>