Привязка кастомного интерфейса к агентам/группам/ролям

Обсуждение вопросов и решений

Модератор: ykolesnikov

Ответить
aid
OTRS Новобранец
Сообщения: 60
Зарегистрирован: 06 мар 2012, 16:07

Привязка кастомного интерфейса к агентам/группам/ролям

Сообщение aid » 01 мар 2013, 11:31

Добрый день!

Кто-нибудь копал, при создании кастомного интерфейса агента, в сторону привязки кастомизации к агентам/группам, а еще лучше, к ролям?
Интересуют способы реализации (некоммерческие). Как это лучше сделать, чтобы обезопасить себя при обновлении версий.

Спасибо!
FreeBSD 9.1, OTRS 3.2.2

ykolesnikov
OTRS Гуру
Сообщения: 3119
Зарегистрирован: 24 дек 2010, 09:27
Откуда: Череповец
Благодарил (а): 4 раза
Поблагодарили: 5 раз
Контактная информация:

Re: Привязка кастомного интерфейса к агентам/группам/ролям

Сообщение ykolesnikov » 01 мар 2013, 12:06

А это вообще о чем?
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая

aid
OTRS Новобранец
Сообщения: 60
Зарегистрирован: 06 мар 2012, 16:07

Re: Привязка кастомного интерфейса к агентам/группам/ролям

Сообщение aid » 01 мар 2013, 14:43

ykolesnikov писал(а):А это вообще о чем?
Юрий, ну вообще вот про что: разным группам агентов/ролям нужен вообще-то свой интерфейс. Пример: одни хотят добавить кучу столбцов для сортировок в дайджесте, другие - вместо штатных окошек (новые/открытые/эскалированные) иметь свой набор кастомных фильтров/сортировок. Вот было бы здорово прикрутить это, но с привязкой к ролям. Как-то так ...
FreeBSD 9.1, OTRS 3.2.2

yuri0001
OTRS Бывалый
Сообщения: 492
Зарегистрирован: 11 фев 2011, 20:25
Откуда: Череповец

Re: Привязка кастомного интерфейса к агентам/группам/ролям

Сообщение yuri0001 » 01 мар 2013, 16:46

Честно говоря, я на такие запросы отвечаю - "Может вас еще и на горшок на руках отнести" :lol:
Поймите, даже если это открытый, бесплатный продукт, это не повод потакать всем хотелкам. Когда идет заказная разработка с нуля - флаг в руки и барабан на шею. Собирайте все хотелки, утверждайте в ТЗ и вперед. Здесь, чтобы реализовать их надо вмешиваться в код. Пусть он объектный, но для того, чтобы все это раскопать и не навредить основному функционалу нужно время, т.е. деньги. Да, здесь предусмотрен нормальный механизм кастомизации, чтобы не ломать все после обновления. Но никто не отменял и никогда не отменит, проверку работы всех кастомных вещей после апгрейда и чем их больше, тем более трудоемкий это процесс. посмотрите, сколько изменили кода при переходе от 3.1. к 3.2. Я просто на сравнение и понимание того что изменилось убил сегодня полдня на пять простых .dtl файла (наряду с основной, другой работой). Заявленные Вами хотелки затронут гораздо больше, и после выхода даже патч-релизов вы обязаны эти процедуры повторять. Это тоже время и деньги.
Кое-что можно сделать через ACL и другие приемы, что недавно опубликовали в Howtos, но, считаю, надо наступать на "горло песне". Количество доработок должно быть ограничено. Представьте, что это продукт, который Вы купили и есть разработчик, который за деньги может делать все. И смогут ли "хотельщики" доказать финансовому боссу, после оплаченного внедрения, что надо платить еще, потому, что Клане Волнухиной или Васе Пупкину, надо немного приложить голову, чтобы работать на стандартном функционале.
В моей старой компании, в которой проработал много лет, уже после ухода начали внедрять SAP. Так вот генеральный директор (наш металлургический олигарх) сказал - внедряем стандартный функционал. Кому нужны "хотелки" - приходят ко мне и обосновывают их необходимость. Догадайтесь с трех раз сколько было доработок. :D
С уважением
Ю. Колесников
OTRS 3.3.1, ITSM 3.3.1, SUSE 12, MySQL5

Ответить