Границы видимости

Использование
1

Возник вопрос по границам видимости. Ситуация такая - есть организация, ИТ-отдел и внешний поставщик, которую исполняет роль 2й линии поддержки по одному из программных продуктов.
Сделано так - головная организация имеет договор и модель распространения услуг с ИТ-отделом (стандартная поддержка), а ИТ-отдел имеет договор с внешней организацией (поддержка продукта ProductName).
Соотвественно создано три организации. Хочется сделать так чтоб внешняя организация не видела ничего, кроме запросов, проблем и изменений. адресованных именно ей, в рамках договора и модели предоставления услуг.
В чем проблема - если я ограничиваю пользователей указывая что они могут видеть только сою оранизацию, то они не видят запросы из ИТ-отдела, адресованые им. если же я добавляю им в список видимости ИТ-отдел, то они начинают видеть много лишнего, типа запросов на изменение и известных ошибок, которые к ним никак не относятся.
Что-то имхо не правильно… Где я заблуждаюсь/накосячил?

2 
  Ограничивай видимость меню по профилям.
  Что-то типа - 

  <menu id="RequestManagement" xsi:type="MenuGroup" _delta="redefine">
  <rank>30</rank>
	<enable_class>UserRequest</enable_class>
	<enable_action>UR_ACTION_BULK_MODIFY</enable_action>
</menu>
  <menu id="IncidentManagement" xsi:type="MenuGroup" _delta="redefine">
  <rank>35</rank>
	<enable_class>Incident</enable_class>
	<enable_action>UR_ACTION_MODIFY | UR_ACTION_BULK_MODIFY</enable_action>
</menu>

<menu id="ProblemManagement" xsi:type="MenuGroup" _delta="redefine">
  <rank>42</rank>
	<enable_class>Problem</enable_class>
	<enable_action>UR_ACTION_MODIFY | UR_ACTION_BULK_MODIFY</enable_action>
</menu>
<menu id="ChangeManagement" xsi:type="MenuGroup" _delta="redefine">
	<rank>50</rank>
	<enable_class>Change</enable_class>
	<enable_action>UR_ACTION_MODIFY | UR_ACTION_BULK_MODIFY</enable_action>
	<enable_class>NormalChange</enable_class>
	<enable_action>UR_ACTION_MODIFY</enable_action>
</menu>
<menu id="ServiceManagement" xsi:type="MenuGroup" _delta="redefine">
	<rank>60</rank>
	<enable_class>Service</enable_class>
	<enable_action>UR_ACTION_MODIFY | UR_ACTION_BULK_MODIFY</enable_action>
</menu>
3

В самом начале, когда пустили внешнего поставщика в свой сервис деск.

Договор с внешней организацией никак на логику работы iTop не влияет и носит исключительно информационный характер, чтобы вы сами не забыли, что он у вас есть и какие по нему SLA. Структура iTop не поддерживает работу поставщиков разного уровня, предполагается, что есть вы, а все остальные – ваши заказчики, которые не видят объекты друг друга. Работа с вашими подрядчиками ведется в их сервисдесках/почтах и может быть интегрирована в iTop например через модуль отправки/получения почты или REST API.

Честно говоря, готового решения без кодинга пока не приходит в голову. Но задача интересная, я подумаю.

4

То есть по факту у меня есть один поставщик услуг (ИТ-отдел) и некоторое кол-во заказчиков? Ибо как я уже понял по факту нельзя сделать несколько поставщиков услуг для одного заказчика - к каждому заказчику может быть привязана только одна модель распространения услуг от поставщика.
Теперь на счет интеграции - мне же все равно надо завести пользователя для внешнего поставщика услуг и дать ему соответствующие права. что он мог воспользоваться REST API?
И таки да - с внешнем поставщиком есть SLA, определены TTO/TTR и нам бы хотелось их контролировать.

Кстати на счет контроля TTO/TTR - где в iTop можно определить рабочие промежутки времени? Ибо по факту запрос может свалиться в нерабочее время и соответственно не хотелось бы чтоб отсчет TTO/TTR шел в нерабочее время.

5

Настройка рабочего времени здесь:
https://wiki.openitop.org/doku.php?id=extensions:sla-computation_2_1