Переопределите объявление этой константы в своем модуле, добавив нужное поле в список.
Спасибо. Все получилось.
Я видел эту переменную. Но подумал, что pending_reason - поле “Текст”, будет всегда отображаться.
Коллеги, добрый день!
А как тоже самое сделать в версии 2.3?
Нашел константу, исправил, прогнал setup и ничего не изменилось ((
Привет.
Тоже задался этим вопросом.
На 2.3 пользовательский портал выполнен в современном стиле (если ставили в установщике) и кастомизируется (сам вид , не классы которые могут быть использованы для вывода в этот вид) в основном в файле index.php
Вот тема на их форуме https://sourceforge.net/p/itop/discussion/922360/thread/c7421d93/
Ответ кого-то из разрабов -
Hello,
The portal is a self contained application. Therefore, you can easily modify it and adapt it to your needs. For that purpose, you’ll need to look at the /portal directory and mainly into the index.php file. Everything you need is in that file.
Modifying the portal/index.php should not be too complex for a developper.
Best regard
Добрый день, коллеги.
-
Кастомизировать портал можно в своем модуле путем определения/переопределения компонентов xsi:type=“Combodo\iTop\Portal\Brick\BrowseBrick” в блоке:
<module_designs>
<module_design id=“itop-portal” xsi:type=“portal”>
-
Нужна помощь!
При определении дополнительных полей для запросов через расширение - шаблоны запросов (https://wiki.openitop.org/doku.php?id=extensions:request-templates) поля типа duration НЕ отображаются в форме создания запроса на портале пользователя.
Кто-нибудь сталкивался с этой проблемой?
Заранее спасибо за ответ.
Кастомизируется он ни в коем случае не в index.php.
Практически всё, что можно изменить в новом портале через XML, лежит в datamodels/2.0/itop-tickets/datamodel.itop-tickets.xml. Там же описаны поля формы тикетов. Некоторые модули могут добавлять на портал свои разделы, как это делает модуль Известных ошибок и FAQ. В этом случае исходные данные нужно брать в XML-модели данных соответствующего модуля, и переопределять в своем модуле.
Привет, Владимир.
Как показать в портале причину отклонения запроса?
В стандартной версии 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 должен быть уникален.
Не так всё, без преувеличения)
Самый простой вариант (на мой взгляд) выглядит так:
- объявляешь новый текстовый атрибут rejection_reason внутри UserRequest;
- выводишь его в нужном месте формы на портале;
- отлавливаешь момент отклонения и записываешь комментарий в rejection_reason.
Предполагаю, что последний пункт можно реализовать через интерфейс iApplicationObjectExtension.
Знакомая история. Полагаю, этот модуль может решить проблему: https://www.itophub.io/wiki/page?id=extensions%3Arequest-templates.
1 лайк