Кастомизация пользовательского портала

Привет, Владимир.
Как показать в портале причину отклонения запроса?
В стандартной версии iTop не надо указывать причину отклонения запроса.
Поэтому я установил расширение Approval process automation, которое добавило в Itop окно с причиной отклонения.
В Модели Данных я нашел атрибут abort_comment, который как я думаю содержит причину отклонения. Других атрибутов я не нашел.
Я вставлял abort_comment в форму для вывода отклоненного запроса, но при просмотре запроса выходит ошибка: Обратитесь к админу.
Я хотел вывести данный атрибут наподобие атрибута “режим ожидания (pending_reason)”, но не получилось.
Вы пользовались данным расширением? Можете чем нибудь помочь? Спасибо.

Атрибут abort_comment относится к объекту ApprovalScheme, но не к объекту UserRequest и связать два объекта не получится, т.к. нет одинаковых атрибутов. Получается, что у этого расширения нет никакой связи причины отклонения запроса с самим запросом. В админской консоли в запросе тоже не выводится причина отклонения.
Есть мысли как решить проблему с выводом причины отклонения в портале?

Я создал новое поле в запросе, куда можно вписать причину отклонения запроса и на пользовательском портале в форму вывода добавил строку “Причина отклонения”, причина туда выводится. Работает нормально.
Но конечно получилось не совсем удобно, т.к. сначала надо написать причину отклонения, потом нажать “применить”, только потом отклонять запрос через расширение Approval process automation.
Я внес изменения напрямую в файлах:

  • datamodels/2.x/itop-request-mgmt-itil/datamodel.itop-request-mgmt-itil.xml
  • env-production/core/module_designs/itop-portal.xml.

Когда вношу данные изменения через отдельное расширение, то не работает.
Как сделать данные изменения через расширение?
Код расширения (сначала добавляю поле для ввода в запрос в админской консоли, потом запись в форму вывода в пользовательском портале):

<?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">
      <fields>
        <field id="rejection_reason" xsi:type="AttributeText" _delta="define">
          <sql>rejection_reason</sql>
          <default_value/>
          <is_null_allowed>true</is_null_allowed>
        </field>
      </fields>
<presentation>
        <details _delta="redefine">
          <items>
		  <item id="col:col3">
			<items>
			<item id="fieldset:Ticket:resolution">
			<rank>20</rank>
				<items>
				<item id="rejection_reason">
				<rank>100</rank>
				</item>
				</items>
			</item>
            </items>
		</item>
        </items>
        </details>
      </presentation>
</class>
</classes>
  
<module_designs>
<module_design id="itop-portal" xsi:type="portal" _delta="redefine">
<form id="ticket-edit">
<class>Ticket</class>
<fields/>
<twig>
    <div class="row">
        <div class="col-sm-7">
        <fieldset>
              <legend>{{'Ticket:baseinfo'|dict_s}}</legend>
			  <div class="col-sm-6">
					<div class="form_field" data-field-id="rejection_reason" data-field-flags="read_only"/>
			  </div>
        </fieldset>
		</div>
	</div>
</twig>
</form>
</module_design>
</module_designs> 
 </itop_design>

Еще не получается вывести имя пользователя отклонившего запрос, т.к. этот атрибут принадлежит классу ApprovalScheme.
Поэтому возникает вопрос:
Как можно связать 2 класса, чтобы объекты одного класса можно было выводить в другом классе?
Надо связать классы UserRequest и ApprovalScheme, чтобы выводить причину отклонения и пользователя отклонившего запрос из класса ApprovalScheme в запросе и на пользовательском портале?

Всё не работает?

redefine означает переопределение всего содержимого тега. В данном случае ты целиком переписал всё представление тикета, заменив его на одно поле rejection_reason, а весь портал превратил в одну форму, состоящую из того же поля.

Да, в портале тогда не отображается форма вывода запроса, выходит ошибка, в админке нет нового поля.

Тогда вместо redefine использовать define?

Использовать нужно то, что подходит (define - определение новых нод, redefine - переопределение существующих), но делать это нужно не на уровне всего module_design или details, а на уровне конкретных добавляемых/переопределяемых нод. Для <field id="rejection_reason" ... _delta="define"> ты же не делал define на уровне всего UserRequest.

ok, спс.
В остальном код правильный в расширении?
Насчет связи 2 классов, как я писал ранее, можешь подсказать.

Вывести поле одного объекта в другом можно, если второй объект ссылается на первый по прямой ссылке (как тикет на выбранную услугу или персона на организацию). Тогда во второй объект добавляется AttributeExternalField, где указывается поле связанного объекта.

По коду:

  • отступы разные;
  • для добавления поля на портал скорее всего нужно будет делать redefine всего <twig>, т.к. его дочерние ноды не имеют атрибутов id="...", по которым iTop строит пути для поиска нужно ноды;
  • ноды, которые стоят выше переопределяемой и не являются её предками, тащить в свой модуль не нужно (например, <class>Ticket</class> и <fields/> не играют роли при переопределении <twig>).

Попробовал связать класс UserRequest и ApprovalScheme. Внес изменения в файл datamodel.itop-request-mgmt-itil:
В <class id="UserRequest"> добавил:

<field id="steps" xsi:type="AttributeExternalKey">
<sql>steps</sql>
<target_class>ApprovalScheme</target_class>
<is_null_allowed>true</is_null_allowed>
<on_target_delete>DEL_MANUAL</on_target_delete>
</field>
<field id="steps" xsi:type="AttributeExternalField">
<extkey_attcode>steps</extkey_attcode>
<target_attcode>steps</target_attcode>
</field>

В <presentation><details><items> добавил:

<item id="steps">
<rank>60</rank>
</item>

Steps - это атрибут из класса ApprovalScheme, в который добавляется инфа от поля отклонения.
Данный код не вывел поле с причиной отклонения в админском портале.
Что не так?

Также прочитал тему с добавлением связей между классами http://community.itop-itsm.ru/t/sozdanie-svyazej-mezhdu-obektami-cmdb/35/26, пока не понял в чем проблема.

В пользовательском портале в файл itop-portal.xml в форме <form id="ticket-edit"> добавил:
<class>ApprovalScheme</class>
В <twig> добавил:
<div class="form_field" data-field-id="steps" data-field-flags="read_only"/>
В этой форме был объявлен класс Ticket, добавил туда 2-ой класс ApprocalScheme, можно в форме определять 2 класса?

Также объявил класс:
<class id="ApprovalScheme">
<scopes>
<scope id="all">
<oql_view><![CDATA[SELECT ApprovalScheme]]></oql_view>
</scope>
</scopes>
</class>
При выводе формы закрытых запросов выходит ошибка.

Коллеги, подскажите пожалуйста, на сколько реально в пользовательском портале привязать шаблон к выбранной категории услуги?
Для примера попробую описать хотелку: есть шаблон запроса на доступ - таблица с нужными полями, которые надо заполнить пользователю, хочу чтобы в зависимоти от категории услуги(запроса на доступ) в поле описание запроса автоматом рисовалась таблица, которую пользователель должен заполнить.

А что это должно дать? Кто будет в UserRequest заполнять ссылку на ApprovalScheme? Внутри <fields> id должен быть уникален.

Не так всё, без преувеличения)

Самый простой вариант (на мой взгляд) выглядит так:

  1. объявляешь новый текстовый атрибут rejection_reason внутри UserRequest;
  2. выводишь его в нужном месте формы на портале;
  3. отлавливаешь момент отклонения и записываешь комментарий в rejection_reason.

Предполагаю, что последний пункт можно реализовать через интерфейс iApplicationObjectExtension.

Знакомая история. Полагаю, этот модуль может решить проблему: https://www.itophub.io/wiki/page?id=extensions%3Arequest-templates.

1 лайк

А что это должно дать? Кто будет в UserRequest заполнять ссылку на ApprovalScheme? Внутри id должен быть уникален.

Дать возможность выводить объекты класса ApprovalScheme в объектах UserRequest, или не так?
Как заполнить ссылку в UserRequest на ApprovalScheme?
<Fields id> сделал уникальным.

Самый простой вариант (на мой взгляд) выглядит так:

1.объявляешь новый текстовый атрибут rejection_reason внутри UserRequest;
2.выводишь его в нужном месте формы на портале;
3.отлавливаешь момент отклонения и записываешь комментарий в rejection_reason.
Предполагаю, что последний пункт можно реализовать через интерфейс iApplicationObjectExtension.

Я нашел в коде, где происходит функция DBUpdate и записываются данные в БД, но причина отклонения не записывается в поле abort_comment, как я думал. Оно записывается в поле steps. Но в это же поле записываются данные из других объектов класса Approval_scheme. В итоге получается такая колбаса в одной ячейке таблицы:

Пока не знаю как теперь вытаскивать причину отклонения. Чтобы нормально вывести причину отказа нужно переделывать код самого расширения, сделать так чтобы объекты класса записывались в разные поля БД.

День добрый, Владимир! Скрыл поля “срочность” и “влияние”, а так же столбец “срочность” из таблицы текущих запросов на пользовательском портале в файле datamodel.itop-tickets.xml, после этого поломался счетчик тикетов, при создании нового тикета пользователем, присваивается один и тот же номер, на пример R-000012, и так каждый раз, создавал после 5 тикетов. При создании тикета под другим пользователем, ему назначен R-000017. Видимо внутренний счетчик продолжает считать по порядку, а в отображении беда. Подскажите возможно ли это поправить? И как можно обнулить счетчик тикетов перед вводом в пром. эксплуатацию? Версия iTop версия 2.5.0-3935.

Привет, @gorincoff! Покажи, что именно и как изменил. Не думаю, что это может быть как-то связано с полями.

<fields>
					<field id="title"/>
					<field id="start_date"/>
					<field id="status"/>
					<field id="service_id"/>
					<field id="servicesubcategory_id"/>
					<!--field id="priority"/ -->
					<field id="caller_id"/>
				</fields>

Вот тут закомментировал столбец с приоритетом в таблице текущих запросов пользователя.

Вот тут перевел в режим “hidden” поля “impact” и “urgency”.

form id=“ticket-create”>
div class=“form_field” data-field-id=“impact” data-field-flags=“hidden”>
/div>
/div>
div class=“col-sm-6”>
div class=“form_field” data-field-id=“urgency” data-field-flags=“hidden”>

Еще убрал у поля “email” флаг “read_only”, чтоб пользователи могли сами указать свой email. Пожалуй это все правки в файле datamodel.itop-tickets.xml.

Правки нужно делать в собственных модулях, а не в стандартных. Вряд ли эти изменения стали причиной проблемы, но всё же стоит попробовать откатиться к стандартной версии и проверить.