Разные формы заявок для разных очередей

[egorbright]

Здравствуйте.

Есть несколько очередей.

Требуется на форму создания тикета добавить определенные динамические поля в зависимости от выбора очереди.

Скажите, пожалуйста, каким образом можно сделать разные формы создания тикетов для разных очередей?

[ykolesnikov]

Это широко обсуждалось на английском форуме - How To show freetext for specific Queues for Customers
http://forums.otterhub.org/viewtopic.ph ... 7fc7a3d691

[egorbright]

Супер. Огромное спасибо! =)

[ykolesnikov]

Кстати, коллега, если разберетесь, не сочтите за труд сделать пост в русском HOWTOS на эту тему.

[egorbright]

Если разберусь - то с превеликим удовольствием. =)

[egorbright]

Написал хауту. Тут: viewtopic.php?f=4&t=1648

[merkushov]

Вариант с редактированием формы через javascript на стороне браузера - костыльный.

Хочу предложить ещё один вариант кастомизации форм заявок. Как мне кажется, он архитектурно более правильный, хотя и не под все задачи может подходить.
Суть в том чтобы создать новый модуль на стороне сервера, отнаследовавшись от существующего. В результате мы получаем ещё один пункт в меню и свои настройки. Через группы можно настроить доступ к новому элементу, а через настройки формы отображать совершенно другие элементы.

Подобным образом можно продублировать практически любую существующую форму. Может пригодится если есть очень разные группы пользователей, которым необходимы разные интерфейсы создания заявок с разным набором динамических полей. В такую схему хорошо ложится, например, если Клиентским интерфейсом пользуются и внешние Клиенты и внутренние сотрудники компании, но у них разные задачи.

Если кому-то интересно, могу описать подробности.

[egorbright]

Полностью согласен с тем, что вариант с JS костыльный.

Мне интересна предложенная Вами модель построения подобных "аддонов"

[merkushov]

Всё просто!

Ситуация для примера Есть фирма по разработке ПО. OTRS используется для поддержки клиентов и для внутренних нужд. Есть "внешние" и "внутренние" Клиенты. Внешние клиенты жалуются только на ПО, для внутренних нужно принимать обращения по сопровождению it служб компании.
Рассмотрим форму создания заявки Клиентом Kernel/Modules/CustomerTicketMessage.pm Для "внешних" Клиентов нужна минималистическая форма с Темой, Текстом сообщения и доп.полем Версия ПО. Для "внутренних" Клиентов нужен весь набор полей и доп. поле "Номер комнаты". Т.е. смысл в том что нужно получить для разных интерфейса для разных групп Клиентов, но при этом хотелось бы чтобы система была общая.

Что делаем...
Создадим модуль Kernel/Modules/CustomerTicketMessageInternal.pm и отнаследуемся от основной формы создания заявки

Код: Выделить всё

# --
# Kernel/Modules/CustomerTicketMessageInternal.pm - модуль создания новой заявки для внутренних Клиентов
# --
# This software comes with ABSOLUTELY NO WARRANTY. For details, see
# the enclosed file COPYING for license information (AGPL). If you
# did not receive this file, see http://www.gnu.org/licenses/agpl.txt.
# --

package Kernel::Modules::CustomerTicketMessageInternal;

use base qw( Kernel::Modules::CustomerTicketMessage );

1;

[merkushov]

Теперь создадим для неё отдельный конфиг. В файлах Kernel/Config/Files/*.xml нужно найти все упоминания CustomerTicketMessage и аккуратно перенести их в собственный xml файл. Например ZCustomerTicketMessageInternal.xml Получится вот такой файл

Код: Выделить всё

<?xml version="1.0" encoding="utf-8" ?>
<otrs_config version="1.0" init="Config">

    <ConfigItem Name="CustomerFrontend::Module###CustomerTicketMessageInternal" Required="0" Valid="1">
        <Description Translatable="1">Frontend module registration for the customer interface.</Description>
        <Group>MyCompany</Group>
        <SubGroup>Frontend::Customer::ModuleRegistration</SubGroup>
        <Setting>
            <FrontendModuleReg>
                <Description>Create tickets</Description>
                <NavBarName>Ticket</NavBarName>
                <Title>New Ticket</Title>
                <NavBar>
                    <Description Translatable="1">Create new Ticket</Description>
                    <Name Translatable="1">New Ticket</Name>
                    <Block></Block>
                    <Type></Type>
                    <NavBar>Ticket</NavBar>
                    <Link>Action=CustomerTicketMessageInternal</Link>
                    <LinkOption></LinkOption>
                    <AccessKey></AccessKey>
                    <Prio>101</Prio>
                </NavBar>
            </FrontendModuleReg>
        </Setting>
    </ConfigItem>

    <ConfigItem Name="Ticket::Frontend::CustomerTicketMessageInternal###NextScreenAfterNewTicket" Required="1" Valid="1">
        <Description Translatable="1">Determines the next screen after new customer ticket in the customer interface.</Description>
        <Group>MyCompany</Group>
        <SubGroup>Frontend::CustomerInternal::Ticket::ViewNew</SubGroup>
        <Setting>
            <Option SelectedID="CustomerTicketOverview">
                <Item Key="CustomerTicketOverview">CustomerTicketOverview</Item>
                <Item Key="CustomerTicketZoom">CustomerTicketZoom</Item>
            </Option>
        </Setting>
    </ConfigItem>
   
<!-- !!!!!!!!!!!!!!!!!! весь конфиг не влез в сообщение для форума !!!!!!!!!!!!!!! -->

    <ConfigItem Name="Ticket::Frontend::CustomerTicketMessageInternal###DynamicField" Required="0" Valid="1">
        <Description Translatable="1">Dynamic fields options...</Description>
        <Group>MyCompany</Group>
        <SubGroup>Frontend::CustomerInternal::Ticket::ViewNew</SubGroup>
        <Setting>
            <Hash>
            </Hash>
        </Setting>
    </ConfigItem>

</otrs_config>

Ребилдим конфиг OTRS

Код: Выделить всё

perl ./bin/otrs.RebuildConfig.pl

после этого конфиги нового модуля CustomerTicketMessageInternal должны появится в web-интерфейсе Конфигурации системы.
Далее следует разбить Клиентов по группам и настроить видимость интерфейсов для той или иной группы (секция конфига CustomerFrontend::Module###CustomerTicketMessageInternal).

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

[ykolesnikov]

Интересно очень, Виктор!
Простите за глупые вопросы непрограммиста:
1. Вновь созданный модуль - CustomerTicketMessageInternal.pm (опираюсь на Ваш пример) помещаем в Custom/Kernel... или в вместе с оригинальными модулями?
2. Файл ZCustomerTicketMessageInternal.xml - при ребилде конфига автоматом подхватится вместе с остальными из этой папки Config/Files? (просто для меня этот процесс непонятен) или создастся еще один раздел в Конфигурировании системы?

Возможно не один я такой неграмотный. Может создадите в HOWTOS тему с более подробным описанием. Думаю, сообщество оценит!

[merkushov]

1. Я размещаю в ./Kernel/... потому что мне так удобнее обновлять систему, но по рекомендациям OTRS нужно размещать в Custom/Kernel/...
2. Да, созданный xml после ребилда автоматически подхватится вместе с остальными.
В моём примере создастся новый раздел в Конфигурировании системы. За это отвечает тэг

Код: Выделить всё

<Group>MyCompany</Group>

если оставить стандартную группу Ticket, то новые конфиги нужно будет искать в старых разделах.

Это и есть подробное описание Настройка формы и конфигурирование доступа Клиента по Группам это отдельные темы. Могу перенести в HOWTOS, если подскажете как разместить в сообщении кусок конфига в 8000 символов.

[ykolesnikov]

Спасибо! С доступом понятно. Конфиг можно сделать вложением к теме.

[egorbright]

Супер! Однозначно в хауту =) Спасибо

[ykolesnikov]

Посмотрите туда, уже пару дней как лежит и ждет Вас.