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


#1

Добрый день.
Знает кто-нибудь, как в интерфейсе пользовательского портала скрыть поля ВЛИЯНИЕ и СРОЧНОСТЬ и задать им значения по умолчанию? Возможно ли это сделать без глубокого проникновения в программирование? )))


Влияние и критичность - удаление (сокрытие)
#2

Похоже, снова я)).
Смотри в datamodel.itop-request-mgmt-itil.xml, в самом начале идет определение констант, тебя может заинтересовать эта строка:

<constant id="PORTAL_USERREQUEST_FORM_ATTRIBUTES" xsi:type="string" _delta="define"><![CDATA[title,description,impact,urgency]]></constant>

Кроме неё там ещё много всего, связанного с порталом. Мы же про iTop 2.0.2 говорим?


#3

@amsol, ну как, получилось что-нибудь?


#4

Добрый день.
К сожалению пока не было времени.
На этой неделе планирую сделать, на выходных отпишусь.


#5

Поправил файл (убрал поле), но ничего не поменялось. Я так понимаю нужны еще какие-то действия.


#6

@Alexander, после правки запускал setup или toolkit?
iTop при установке компилирует код из папок datamodels и extensions в env-production. После любого изменения в файлах моделей данных или дополнительных модулей нужно запускать setup и прогонять установку в режиме обновления iTop.


#7

Запустил setup и обновил - все заработало. Спасибо!


#8

@Alexander, рад помочь).
Небольшое дополнение: изменение стандартных моделей в datamodels допустимо только для нужд тестирования и разработки. Если собираешься переносить эти изменения в продакшн, делай отдельный модуль! Иначе при очередном обновлении iTop запутаешься, где и чего поменял.


#9

Как отобразить на портале причину перевода Запроса/Инцидента в режим ожидания ?


#10

http://sourceforge.net/p/itop/code/HEAD/tree/tags/2.2.0/datamodels/2.x/itop-request-mgmt/datamodel.itop-request-mgmt.xml#l10

Переопределите объявление этой константы в своем модуле, добавив нужное поле в список.


#11

Спасибо. Все получилось.
Я видел эту переменную. Но подумал, что pending_reason - поле “Текст”, будет всегда отображаться.


#12

Коллеги, добрый день!
А как тоже самое сделать в версии 2.3?
Нашел константу, исправил, прогнал setup и ничего не изменилось ((


#13

Привет.
Тоже задался этим вопросом.
На 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


#14

Добрый день, коллеги.

  1. Кастомизировать портал можно в своем модуле путем определения/переопределения компонентов xsi:type=“Combodo\iTop\Portal\Brick\BrowseBrick” в блоке:

    <module_designs>
    <module_design id=“itop-portal” xsi:type=“portal”>

  2. Нужна помощь!
    При определении дополнительных полей для запросов через расширение - шаблоны запросов (https://wiki.openitop.org/doku.php?id=extensions:request-templates) поля типа duration НЕ отображаются в форме создания запроса на портале пользователя.
    Кто-нибудь сталкивался с этой проблемой?

Заранее спасибо за ответ.


#15

Кастомизируется он ни в коем случае не в index.php.

Практически всё, что можно изменить в новом портале через XML, лежит в datamodels/2.0/itop-tickets/datamodel.itop-tickets.xml. Там же описаны поля формы тикетов. Некоторые модули могут добавлять на портал свои разделы, как это делает модуль Известных ошибок и FAQ. В этом случае исходные данные нужно брать в XML-модели данных соответствующего модуля, и переопределять в своем модуле.


Влияние и критичность - удаление (сокрытие)
#16

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


#17

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


#18

Я создал новое поле в запросе, куда можно вписать причину отклонения запроса и на пользовательском портале в форму вывода добавил строку “Причина отклонения”, причина туда выводится. Работает нормально.
Но конечно получилось не совсем удобно, т.к. сначала надо написать причину отклонения, потом нажать “применить”, только потом отклонять запрос через расширение 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 в запросе и на пользовательском портале?


#19

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


#20

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