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

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

Тогда вместо 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.

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