Страница 1 из 1

Кастомизация форм (в рамках архитектуры)

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

Что делаем
1. Создаём модуль, отнаследовавшись от старого.
2. Создаём для него конфиг, копируя старый и меняя там имя модуля.
3. Настраиваем две формы в Конфигураторе (в рамках конфига) так как нам нужно.
4. Раздаём права доступа к старому и новому интерфейсу, чтобы каждая группа пользователей видела свою форму.

Теперь подробности
1. Создадим модуль 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;
2. Создадим для неё отдельный конфиг. В файлах Kernel/Config/Files/*.xml нужно найти все упоминания CustomerTicketMessage и аккуратно перенести их в собственный xml файл. Например ZCustomerTicketMessageInternal.xml Получится вот такой файл
ZCustomerTicketMessageInternal.xml.zip
Конфиг для нового модуля
(1.29 КБ) 837 скачиваний
Ребилдим конфиг OTRS

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

perl ./bin/otrs.RebuildConfig.pl
после этого конфиги нового модуля CustomerTicketMessageInternal должны появится в web-интерфейсе Конфигурации системы.

3. Через Конфигурацию стистемы настраиваем старую и новую формы. Пригодится стандартный механизм ACL'ов

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

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

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 29 окт 2014, 13:05
gusev
Виктор, немного не понятно касательно "ребилдим конфиг ОТРС", что под этим подразумевается и как это сделать?

Заранее спасибо!

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 29 окт 2014, 13:24
gusev
Отобразилась данная конфигурация в веб-интерфейсе, теперь при создании новой заявки у меня два поля "новая заявка".

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 29 окт 2014, 13:31
merkushov
Смысл тут в том что появляется ещё одна форма, после чего их можно настроить по разному и развести по ним Клиентов при помощи групп.

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 30 окт 2014, 12:53
alexus
Клиенты-Группы - это очень плохая концепция, с побочными эффектами и общим утяжелением сопровождения системы.

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 30 окт 2014, 13:21
merkushov
alexus писал(а):Клиенты-Группы - это очень плохая концепция, с побочными эффектами и общим утяжелением сопровождения системы.
Согласен. Сопровождение утяжеляет, но как универсальная концепция управления связка интересная. На группы завязан доступ к тикетам очереди и к страницам интерфейса; группы используются для управления элементами форм в ACL; с помощью групп можно управлять элементами главного меню.

Если бы я писал свой OTRS, то взял бы за основу ProcessManagement с его универсальным подходом к созданию форм под конкретные процессы и концепцию Групп - Ролей

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 30 окт 2014, 14:32
alexus
Кто пробовал хоть раз настраивать Process, тот понимает, что задача не для средних умов. ACL и так нормально работает. А концепция клиентского портала, она правильная. Предустановленный ТИП тикета - на клиентском и агентском интерфейсе - это странная постановка вопроса. И надо, чтобы эти атрибуты заявки были сознательно определены клиентом или агентом.

Re: Кастомизация форм (в рамках архитектуры)

Добавлено: 19 сен 2017, 23:27
e.levitskiy
ACL не умеет скрывать ненужные динамические поля в зависимости от "чего либо". не содержимое их- а само поле, как сущность
потому process management интересен хотя бы тем- что можно сделать действительно кастомные формы запросов для всего подряд