Добрый день!
Кто-нибудь копал, при создании кастомного интерфейса агента, в сторону привязки кастомизации к агентам/группам, а еще лучше, к ролям?
Интересуют способы реализации (некоммерческие). Как это лучше сделать, чтобы обезопасить себя при обновлении версий.
Спасибо!
Привязка кастомного интерфейса к агентам/группам/ролям
Модератор: ykolesnikov
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: Привязка кастомного интерфейса к агентам/группам/ролям
А это вообще о чем?
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
Re: Привязка кастомного интерфейса к агентам/группам/ролям
Юрий, ну вообще вот про что: разным группам агентов/ролям нужен вообще-то свой интерфейс. Пример: одни хотят добавить кучу столбцов для сортировок в дайджесте, другие - вместо штатных окошек (новые/открытые/эскалированные) иметь свой набор кастомных фильтров/сортировок. Вот было бы здорово прикрутить это, но с привязкой к ролям. Как-то так ...ykolesnikov писал(а):А это вообще о чем?
FreeBSD 9.1, OTRS 3.2.2
Re: Привязка кастомного интерфейса к агентам/группам/ролям
Честно говоря, я на такие запросы отвечаю - "Может вас еще и на горшок на руках отнести"
Поймите, даже если это открытый, бесплатный продукт, это не повод потакать всем хотелкам. Когда идет заказная разработка с нуля - флаг в руки и барабан на шею. Собирайте все хотелки, утверждайте в ТЗ и вперед. Здесь, чтобы реализовать их надо вмешиваться в код. Пусть он объектный, но для того, чтобы все это раскопать и не навредить основному функционалу нужно время, т.е. деньги. Да, здесь предусмотрен нормальный механизм кастомизации, чтобы не ломать все после обновления. Но никто не отменял и никогда не отменит, проверку работы всех кастомных вещей после апгрейда и чем их больше, тем более трудоемкий это процесс. посмотрите, сколько изменили кода при переходе от 3.1. к 3.2. Я просто на сравнение и понимание того что изменилось убил сегодня полдня на пять простых .dtl файла (наряду с основной, другой работой). Заявленные Вами хотелки затронут гораздо больше, и после выхода даже патч-релизов вы обязаны эти процедуры повторять. Это тоже время и деньги.
Кое-что можно сделать через ACL и другие приемы, что недавно опубликовали в Howtos, но, считаю, надо наступать на "горло песне". Количество доработок должно быть ограничено. Представьте, что это продукт, который Вы купили и есть разработчик, который за деньги может делать все. И смогут ли "хотельщики" доказать финансовому боссу, после оплаченного внедрения, что надо платить еще, потому, что Клане Волнухиной или Васе Пупкину, надо немного приложить голову, чтобы работать на стандартном функционале.
В моей старой компании, в которой проработал много лет, уже после ухода начали внедрять SAP. Так вот генеральный директор (наш металлургический олигарх) сказал - внедряем стандартный функционал. Кому нужны "хотелки" - приходят ко мне и обосновывают их необходимость. Догадайтесь с трех раз сколько было доработок.
Поймите, даже если это открытый, бесплатный продукт, это не повод потакать всем хотелкам. Когда идет заказная разработка с нуля - флаг в руки и барабан на шею. Собирайте все хотелки, утверждайте в ТЗ и вперед. Здесь, чтобы реализовать их надо вмешиваться в код. Пусть он объектный, но для того, чтобы все это раскопать и не навредить основному функционалу нужно время, т.е. деньги. Да, здесь предусмотрен нормальный механизм кастомизации, чтобы не ломать все после обновления. Но никто не отменял и никогда не отменит, проверку работы всех кастомных вещей после апгрейда и чем их больше, тем более трудоемкий это процесс. посмотрите, сколько изменили кода при переходе от 3.1. к 3.2. Я просто на сравнение и понимание того что изменилось убил сегодня полдня на пять простых .dtl файла (наряду с основной, другой работой). Заявленные Вами хотелки затронут гораздо больше, и после выхода даже патч-релизов вы обязаны эти процедуры повторять. Это тоже время и деньги.
Кое-что можно сделать через ACL и другие приемы, что недавно опубликовали в Howtos, но, считаю, надо наступать на "горло песне". Количество доработок должно быть ограничено. Представьте, что это продукт, который Вы купили и есть разработчик, который за деньги может делать все. И смогут ли "хотельщики" доказать финансовому боссу, после оплаченного внедрения, что надо платить еще, потому, что Клане Волнухиной или Васе Пупкину, надо немного приложить голову, чтобы работать на стандартном функционале.
В моей старой компании, в которой проработал много лет, уже после ухода начали внедрять SAP. Так вот генеральный директор (наш металлургический олигарх) сказал - внедряем стандартный функционал. Кому нужны "хотелки" - приходят ко мне и обосновывают их необходимость. Догадайтесь с трех раз сколько было доработок.
С уважением
Ю. Колесников
OTRS 3.3.1, ITSM 3.3.1, SUSE 12, MySQL5
Ю. Колесников
OTRS 3.3.1, ITSM 3.3.1, SUSE 12, MySQL5