Zammad: Агент не может видеть билеты, если он является клиентом в другой группе.
Информация:
- Используемая версия Zammad: 2.2.x
- Способ установки (исходный код, пакет, ..): deb9 rep
- Операционная система: сервер deb9, клиент win7 / 10
- База данных + версия: PostgreSQL 9.6.6
- Версия Elasticsearch: 5.6.5
- Браузер + версия: все
Ожидаемое поведение:
- Агент группы A создает билет для группы B (покупателем этого билета является он сам)
- Обзор «мои билеты» (клиент = текущий пользователь) показывает этот билет
Фактическое поведение:
- Агент группы A создает билет для группы B (покупателем этого билета является он сам)
- Вы не видите билет
Шаги по воспроизведению поведения:
- Определите несколько групп (например, Helpdesk и Datacenter )
- Определите две роли Agent Helpdesk и Agent Datacenter
- Создайте двух пользователей. Установите один в качестве службы поддержки агентов, а другой - в качестве центра обработки данных агента.
- Установите права для службы поддержки агентов на полный доступ агента для группы Heldpesk.
- Сделайте то же самое для Agent Datacenter, но для группы Datacenter.
- Создайте обзор со следующими условиями:
customer is current user AND state is (new OR open OR pending) - Создайте заявку в качестве пользователя группы центра обработки данных.
Что ж, я как минимум на 70% уверен, что это ошибка, а не запрос функции или общий вопрос.
Я имею в виду, это не может быть преднамеренным, или нет?
Как агент, вы должны иметь возможность создавать билеты «для себя» И потом просматривать их в обзоре.
Мы уже пытались дополнительно установить роль клиента для этих агентов, но это тоже не работает.
В дополнение к этому нам необходимо вручную назначить дополнительную роль клиента. Автоматическое сопоставление ldap не работает, если вы пытаетесь назначить роли агента и клиента .
svnr-dvnkln
Все 5 Комментарий
Привет @ svnr-dvnkln
это сделано намеренно. Мы разработали его таким образом, чтобы предотвратить несколько проблем:
- Что следует клиенту, который является агентом в другой роли, увидеть (Информация о билетах)
- Что покупатель должен иметь возможность делать с билетом
Если мы воспользуемся простым ответом «Так же, как когда он является клиентом», это вызовет большую путаницу.
«Почему я не могу отредактировать этот билет, я его вижу и я агент»
и многие многие другие вопросы.
Сейчас веб-приложение способно одновременно обрабатывать одну роль (агента или клиента). И мы не планируем это менять.
С Уважением.
Йоханнес
hanneshal
14 дек. 2017
Привет @hanneshal ,
Спасибо за быстрый ответ!
Так как же нам решить эту проблему?
Наши агенты по-прежнему должны иметь возможность управлять своими «клиентскими билетами» в другой группе, где у них нет агентских прав.
Что следует клиенту, который является агентом в другой роли, увидеть (Информация о билетах)
Что покупатель должен иметь возможность делать с билетомЕсли мы воспользуемся простым ответом «Так же, как когда он является клиентом», это вызовет большую путаницу.
«Почему я не могу отредактировать этот билет, я его вижу и я агент»
и многие многие другие вопросы.
На самом деле это довольно просто. Это зависит от прав, установленных агентом.
Если у меня есть права агента для группы A, я только клиент в группе B, наоборот.
Я не вижу здесь более серьезной проблемы, поскольку другие билетные системы делают это таким же образом.
Мы не можем просто дать агенту из группы A права на чтение для группы B. Это было бы серьезным нарушением конфиденциальности.
ваше здоровье
svnr-dvnkln
14 дек. 2017
Привет,
если вы хотите использовать zammad в качестве внутренней системы заявок для разных отделов, то быть агентом в одной группе и быть клиентом в другой группе является обязательным вариантом использования.
Например, если ИТ-отдел и отдел кадров используют zammad для своих задач.
В этом случае у вас есть две группы. Одна группа для ИТ и одна для HR.
Айтишник - агент, если у кадровика есть ИТ-проблемы!
Но тот же самый айтишник должен быть в роли заказчика, если у него есть какие-либо вопросы по поводу его работы. Потому что при решении вопросов трудоустройства агентом является кадровый агент.
То же и со смотрителями компании. Они должны быть агентом группы обслуживающего персонала и заказчиком группы HR и IT.
Вы же не хотите, чтобы компания использовала разные установки zammad для каждого отдела, который работает с билетами, не так ли?
И вы не хотите, чтобы у опекунов не было ни вопросов по IT, ни по кадрам?
Любое предложение, как решить эту проблему, приветствуется?
Я вижу только три варианта:
- использовать разные установки для каждого отдела => не рекомендуется, поскольку вводит пользователей в заблуждение
- не используйте zammad => неприемлемо ;-)
- реализовать вариант использования
С наилучшими пожеланиями
Герхард
gwingend
14 дек. 2017
chrklo
5 февр. 2018
у нас тоже есть эта проблема.
banholzer
11 янв. 2019
Смежные вопросы
martini
·
3Комментарии
metasnw
·
3Комментарии
em-ex
·
3Комментарии
infestdead
·
3Комментарии
robwilc
·
3Комментарии
Самый полезный комментарий
Привет,
если вы хотите использовать zammad в качестве внутренней системы заявок для разных отделов, то быть агентом в одной группе и быть клиентом в другой группе является обязательным вариантом использования.
Например, если ИТ-отдел и отдел кадров используют zammad для своих задач.
В этом случае у вас есть две группы. Одна группа для ИТ и одна для HR.
Айтишник - агент, если у кадровика есть ИТ-проблемы!
Но тот же самый айтишник должен быть в роли заказчика, если у него есть какие-либо вопросы по поводу его работы. Потому что при решении вопросов трудоустройства агентом является кадровый агент.
То же и со смотрителями компании. Они должны быть агентом группы обслуживающего персонала и заказчиком группы HR и IT.
Вы же не хотите, чтобы компания использовала разные установки zammad для каждого отдела, который работает с билетами, не так ли?
И вы не хотите, чтобы у опекунов не было ни вопросов по IT, ни по кадрам?
Любое предложение, как решить эту проблему, приветствуется?
Я вижу только три варианта:
С наилучшими пожеланиями
Герхард