Додумывание за клиента
Модератор: ykolesnikov
Додумывание за клиента
День добрый!
Есть несколько практических вопросов:
1. Клиент видит и заполняет минимум реквизитов заявки, по умолчанию тип заявки проставляется как unclassified. Для части сервисов тип заявки выставляется планировщиком по событию создания, а вот для другой части это должен сделать агент при блокировке или закрытии заявки, т.е. для заявок в работе или закрытых должен быть указан тип, отличный от unclassified. Можно ли это сделать штатными средствами и как? Или лучше вообще обойтись без типа по умолчанию, и тогда агент по-любому заполнит пустое поле?
2. Можно ли для определенных сервисов назначать заявке очередь в зависимости от определенных реквизитов клиента? В частности, от города клиента.
3. Так и не нашёл каким образом можно сделать шаблоны заявок для клиентов. Или принцип такой же, как для телефонных заявок, которые заводят клиенты? Можно ли ссылки на эти шаблоны вывести в клиентский интерфейс? Типа тулбара.
4. Один из реквизитов, который клиент может самостоятельно указать - это сервис. Для некоторых сервисов есть детализация (состав сервиса). При этом корневой элемент все равно доступен для выбора. Это как-то можно ограничить?
Ps otrs 5
Есть несколько практических вопросов:
1. Клиент видит и заполняет минимум реквизитов заявки, по умолчанию тип заявки проставляется как unclassified. Для части сервисов тип заявки выставляется планировщиком по событию создания, а вот для другой части это должен сделать агент при блокировке или закрытии заявки, т.е. для заявок в работе или закрытых должен быть указан тип, отличный от unclassified. Можно ли это сделать штатными средствами и как? Или лучше вообще обойтись без типа по умолчанию, и тогда агент по-любому заполнит пустое поле?
2. Можно ли для определенных сервисов назначать заявке очередь в зависимости от определенных реквизитов клиента? В частности, от города клиента.
3. Так и не нашёл каким образом можно сделать шаблоны заявок для клиентов. Или принцип такой же, как для телефонных заявок, которые заводят клиенты? Можно ли ссылки на эти шаблоны вывести в клиентский интерфейс? Типа тулбара.
4. Один из реквизитов, который клиент может самостоятельно указать - это сервис. Для некоторых сервисов есть детализация (состав сервиса). При этом корневой элемент все равно доступен для выбора. Это как-то можно ограничить?
Ps otrs 5
Re: Додумывание за клиента
Приветствую!
1. запретить просто проставлять агентам данный тип и сделать поле обязательным для закрытия\блокировки - например через ACL
2. через планировщик ловить событие TicketServiceUpdate, выбирать заявки с нужными реквизитами и обновлять очередь.
3. на англ. форуме точно такая тема была. изменяются .tt файлы создания заявки и туда вносятся нужные параметры
4. сделать недействительным корневой сервис - тогда его нельзя будет выбрать, но можно будет развернуть и выбрать детальный
1. запретить просто проставлять агентам данный тип и сделать поле обязательным для закрытия\блокировки - например через ACL
2. через планировщик ловить событие TicketServiceUpdate, выбирать заявки с нужными реквизитами и обновлять очередь.
3. на англ. форуме точно такая тема была. изменяются .tt файлы создания заявки и туда вносятся нужные параметры
4. сделать недействительным корневой сервис - тогда его нельзя будет выбрать, но можно будет развернуть и выбрать детальный
OTRS ITSM 5.0.3
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Re: Додумывание за клиента
Спасибо за подсказки. Но непонятки все равно остались.
Только нужных реквизитов клиента в условиях отбора я не наблюдаю. Можно как-то на этапе создания заявки автоматом записать что-либо от клиента в динамическое поле, а потом его обработать в планировщике?
Можно поподробнее про запрет? Это тоже через ACL?MrIch писал(а): 1. запретить просто проставлять агентам данный тип и сделать поле обязательным для закрытия\блокировки - например через ACL
Это понятно, что надо ловить событие. Почему TicketServiceUpdate, а не TicketCreate?2. через планировщик ловить событие TicketServiceUpdate, выбирать заявки с нужными реквизитами и обновлять очередь.
Только нужных реквизитов клиента в условиях отбора я не наблюдаю. Можно как-то на этапе создания заявки автоматом записать что-либо от клиента в динамическое поле, а потом его обработать в планировщике?
-
- OTRS Гуру
- Сообщения: 5192
- Зарегистрирован: 20 сен 2010, 18:17
- Откуда: Москва
- Благодарил (а): 92 раза
- Поблагодарили: 82 раза
Re: Додумывание за клиента
Это неправильно! Надо корневой Сервис просто не назначать клиентам.MrIch писал(а):4. сделать недействительным корневой сервис - тогда его нельзя будет выбрать, но можно будет развернуть и выбрать детальный
С уважением,
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Алексей Юсов
Prod: OTRS CE ITSM 6.0.28 on CentOS 7 Apache 2.4 MariaDB 10.4.13 + Radiant Customer Portal
Radiant System OTRS Intergrator RU
Группа OTRS Community в Teleram
Хотите внедрить OTRS? Спросите меня как!
Re: Додумывание за клиента
Да, именно через ACL. Настраиваете ACL таким способом, чтобы агент не мог выбрать unclassified, но это поле делаете обязательным на данной форме ОТРСки.Rem писал(а):
Можно поподробнее про запрет? Это тоже через ACL?
Можно и TicketCreate, разницы особой насколько я помню нет).Rem писал(а): Это понятно, что надо ловить событие. Почему TicketServiceUpdate, а не TicketCreate?
Только правкой кода создания заявки.Rem писал(а): Только нужных реквизитов клиента в условиях отбора я не наблюдаю. Можно как-то на этапе создания заявки автоматом записать что-либо от клиента в динамическое поле, а потом его обработать в планировщике?
OTRS ITSM 5.0.3
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Re: Додумывание за клиента
Как обходной вариант, думаю, подойдет завести не одну компанию, а несколько и при назначении очереди в планировщике зажиматься на id компании.
Re: Додумывание за клиента
Тогда получается коллизия.MrIch писал(а): Да, именно через ACL. Настраиваете ACL таким способом, чтобы агент не мог выбрать unclassified, но это поле делаете обязательным на данной форме ОТРСки.
Я клиенту тип заявки не показываю. В Ticket::Frontend::CustomerTicketMessage###TicketType стоит Нет, но тогда "Если установить "Нет", необходимо настроить параметр TicketTypeDefault(Тип по умолчанию)".
В таком случае пустое значение не допускается, а Unclassified приводит к тому, что при сохранении заявки вываливается ошибка.
И как это обойти?
Re: Додумывание за клиента
А Unclassified у вас действительный тип?
В тип по умолчанию необходимо указать действительный тип из ***/otrs/index.pl?Action=AdminType
В тип по умолчанию необходимо указать действительный тип из ***/otrs/index.pl?Action=AdminType
OTRS ITSM 5.0.3
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Re: Додумывание за клиента
Тип действительный. Просто, если его запретить в ACL, как было предложено выше, то при заведении заявки клиентом будет вываливаться ошибка. Клиенту указание типа недоступно, поэтому надо прописать тип по умолчанию.MrIch писал(а):А Unclassified у вас действительный тип?
В тип по умолчанию необходимо указать действительный тип из ***/otrs/index.pl?Action=AdminType
Задача в том, чтобы агенты не оставляли/не указывали Unclassified.
Re: Додумывание за клиента
Так вы запретите этот тип конкретно для агентов или на определенных страницах, не нужно его клиентам запрещать.
То есть в настройке условий, у вас должны быть условия на Properties - > User - -> Login или Properties -> Frontend -> Action
То есть в настройке условий, у вас должны быть условия на Properties - > User - -> Login или Properties -> Frontend -> Action
OTRS ITSM 5.0.3
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7
Ubuntu 14.04 + PostgreySQL 9.3.9 +Apache 2.4.7