Кастомизация форм (в рамках архитектуры)
Добавлено: 20 май 2013, 12:09
Ситуация для примера Есть фирма по разработке ПО. OTRS используется для поддержки клиентов и для внутренних нужд. Есть "внешние" и "внутренние" Клиенты. Внешние клиенты жалуются только на ПО, для внутренних нужно принимать обращения по сопровождению it служб компании.
Рассмотрим форму создания заявки Клиентом Kernel/Modules/CustomerTicketMessage.pm Для "внешних" Клиентов нужна минималистическая форма с Темой, Текстом сообщения и доп.полем Версия ПО. Для "внутренних" Клиентов нужен весь набор полей и доп. поле "Номер комнаты". Т.е. смысл в том что нужно получить для разных интерфейса для разных групп Клиентов, но при этом хотелось бы чтобы система была общая.
Что делаем
1. Создаём модуль, отнаследовавшись от старого.
2. Создаём для него конфиг, копируя старый и меняя там имя модуля.
3. Настраиваем две формы в Конфигураторе (в рамках конфига) так как нам нужно.
4. Раздаём права доступа к старому и новому интерфейсу, чтобы каждая группа пользователей видела свою форму.
Теперь подробности
1. Создадим модуль Kernel/Modules/CustomerTicketMessageInternal.pm и отнаследуемся от основной формы создания заявки
2. Создадим для неё отдельный конфиг. В файлах Kernel/Config/Files/*.xml нужно найти все упоминания CustomerTicketMessage и аккуратно перенести их в собственный xml файл. Например ZCustomerTicketMessageInternal.xml Получится вот такой файл
Ребилдим конфиг OTRS
после этого конфиги нового модуля CustomerTicketMessageInternal должны появится в web-интерфейсе Конфигурации системы.
3. Через Конфигурацию стистемы настраиваем старую и новую формы. Пригодится стандартный механизм ACL'ов
4. Далее следует разбить Клиентов по группам и настроить видимость интерфейсов для той или иной группы (секция конфига CustomerFrontend::Module###CustomerTicketMessageInternal).
Какие плюсы:
- получаем настройки для разных групп пользователей
- методика в рамках архитектуры, ничего кардинально менять не нужно
- все обновления OTRS проходят прозрачно
Рассмотрим форму создания заявки Клиентом 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;
Код: Выделить всё
perl ./bin/otrs.RebuildConfig.pl
3. Через Конфигурацию стистемы настраиваем старую и новую формы. Пригодится стандартный механизм ACL'ов
4. Далее следует разбить Клиентов по группам и настроить видимость интерфейсов для той или иной группы (секция конфига CustomerFrontend::Module###CustomerTicketMessageInternal).
Какие плюсы:
- получаем настройки для разных групп пользователей
- методика в рамках архитектуры, ничего кардинально менять не нужно
- все обновления OTRS проходят прозрачно