да я с тобой 100%
Это и моя мечта. Функция слияния будет отличной!
Поскольку часто клиенты начинают новое электронное письмо и не отвечают с номером тикета... было бы здорово "объединить" этот ответ с существующим тикетом.

Ага.
Даже проблема в том, что нет «общедоступной ссылки на билет», которую можно было бы добавить.
Так что даже это помогло бы, если бы вы могли закрыть тикет и сказать: «Посмотрите номер тикета: # 12345»,
который свяжет персонал и пользователя с заявкой.
Это может помочь, с одной стороны, если слияние невозможно, с другой стороны, если у вас есть билеты,
который следует за другим, вы можете создать своего рода «логический путь».

Но посмотрим, что по этому поводу думают разработчики ;)

ВАШЕ ЗДОРОВЬЕ!

Мне нравится идея автоматической ссылки (см. #12345683)

@greezybacon

Мне открыть для этого другую ветку?

Таким образом, идея заключается в том, чтобы «просто» нажать кнопку, и вы можете ввести номер билета (или выбрать, но это тяжело).
После этого ссылка будет добавлена ​​в тикет.

Опять же, проблема заключается не в добавлении самой ссылки, а в том, что ее могут просматривать только сотрудники ИЛИ пользователь.
Как я уже сказал, было бы здорово разобраться со следующими проблемами и изменениями, которые вы делаете, от начала до конца, без поиска.

Но также вы не можете, например, создать ссылку на тикет в базе знаний, которая, возможно, тоже могла бы объяснить что-то лучше.

Я хотел бы добавить свою поддержку для этого запроса функции. Мои пользователи очень хорошо умеют отправлять несколько электронных писем по одной и той же проблеме, не указывая номер заявки, и я быстро теряю всю необходимую информацию, необходимую для решения проблемы.

Объединение билетов было бы здорово! Даже если это просто ввод билета #.

Обман https://github.com/osTicket/osTicket-1.8/issues/1068?

Пожалуйста, выполните поиск перед отправкой нового вопроса!

Ну в целом цитата та же.
Но, с другой стороны, это отдельно от моего объяснения, поскольку автоматическая ссылка - это еще одна функция, чем объединение заявок.

Так что понятия не имею, как теперь с этим справиться.

На мой взгляд, первым «более простым» шагом было бы добавление возможности ссылки на тикет, который может быть просмотрен персоналом и/или пользователем.
Таким образом, вы можете создать своего рода процесс/историю, когда пытаетесь найти решение или что-то понять.

Но вообще было бы круто в будущем иметь некий "основной билет", в который можно просто добавлять новые/такие/двойные билеты.
Так что вы получите один билет и увидите все разные решения, способы пользователей в списке билетов, которые были объединены.

Это мое представление об этом, но я не знаю, сможет ли кто-нибудь понять и увидеть это так же осмысленно, как я.

ВАШЕ ЗДОРОВЬЕ

Ссылки / ссылки - это оригинальное предложение @greezybacon , над которым они на самом деле работают, и оно называется «Проблемы». Группировка похожих заявок имеет большой смысл, но это не слияние. При слиянии вам нужно только «переместить» все записи заявок в новую заявку, для связывания/группировки потребуется новая таблица.
Так что да, это почти то же самое, о чем вы говорите @ Hannibal226

Я буду программировать это в ближайшие дни/недели. и опубликовать его как запрос на включение.

я думаю, что не так сложно "объединить билеты", если сообщения отсортированы по времени. и в большинстве случаев, если вы объедините заявку, у вас будет только «одно» сообщение. Потому что это может быть новый тикет, на который конечный пользователь ответил неправильно/написал новое электронное письмо и не использовал кнопку ответа.

Моя идея такова:

• у вас есть кнопка "Объединить с другим билетом".
• если вы нажмете ее, откроется всплывающее окно, и вы напишите/ищите тикет, где вы хотите объединить этот тикет.
• чем вас попросили добавить отправителя в качестве соавтора (если это не то же электронное письмо, что и от владельца)
• чем вас попросили закрыть «новый тикет» в конце или удалить его.
  если вы закроете его, то будет добавлена ​​заметка со всей информацией, например:
  кто его отправил (email/имя) время/дата и номер тикета из закрытого тикета
  ИЛИ
  кто его отправил (электронная почта/имя) время/дата

финал.
Я думаю, что это действительно нужная функция. У меня часто бывают клиенты, которые пишут новое электронное письмо и не используют кнопку ответа. затем я вручную закрываю новый билет и добавляю номер билета в «основной билет». Но это не так уж и круто, если нужно переключаться с тикета на тикет, чтобы понять, что происходит.

@ mrsaw12 mrsaw12 могу ли я предложить вам попробовать реализовать это как плагин?

@Mrsaw12

Звучит gr8, и мне бы очень хотелось это проверить ;)
И, как вы сказали, это совсем не сложно, но в любом случае я не слишком разбираюсь в PHP и MySQL, и поэтому для себя это сложно.

Так много успехов и дайте нам знать, когда это будет сделано ;)

Ура приятель!

@kordianbruck

Так что в любом случае я не уверен.
Есть два способа, если вы получаете из одного тикета сообщение о том, что его следует объединить и/или связать с чем-либо, ИЛИ вы выбираете разные тикеты и группируете их.

Опять же, это слишком глубоко, и вообще какая-либо из этих функций отсутствует, и я рад, что у нас есть такие активные ребята, как @mrsaw12 , которые тратят немного времени, чтобы быстро помочь здесь.

Наверняка главные разработчики, такие как @greezybacon или все ребята рядом с r, делают более чем достаточно, и это не должно означать какое-то давление или что-то в этом роде.

В любом случае спасибо вам за то, что вы объединили свои мысли и, возможно, с решением, обе части довольны результатом, так что мы можем сказать «да, это то же самое»;)

ВАШЕ ЗДОРОВЬЕ

В ближайшие месяцы мы добавим возможность для заявки иметь несколько потоков (через «задачи»). Было бы интересно посмотреть, поможет ли это слиянию билетов.

@greezybacon Круто, приятно слышать!

Привет! мне интересно, есть ли какие-либо обновления для этого улучшения? очень нужен. Благодарность!

+1

@greezybacon Приятно слышать и спасибо!

также ищу обновление по этому поводу. Объединение заявок очень важно для нашего рабочего процесса, спасибо.

Привет, ребята,

Я использовал много систем продажи билетов, и все они объединяются с помощью одной и той же базовой методологии (Ceberus, Zendesk, RT и т. д.).

Я бы хотел, чтобы osTicket объединился с тем, что предлагает большинство других систем продажи билетов.

1) Разрешить агенту выбирать несколько заявок из любого представления (список результатов поиска, список моих заявок, другие списки) и нажимать кнопку ОБЪЕДИНИТЬ.

2) После нажатия кнопки MERGE

• ВСЕ данные объединены в одну цепочку тикетов, упорядоченные по дате
• САМЫЙ СТАРЫЙ номер билета — это номер объединенного билета.
• ВСЕ сотрудники и агенты в новом билете

Это слияние — вы берете все и объединяете в одну вещь, которая представлена ​​ОРИГИНАЛЬНОЙ (самой старой) вещью.

Слияние и сокращение дубликатов — наиболее важные функции в среде с большими объемами, позволяющие сократить бессмысленную и ненужную работу при оформлении билетов. ИМХО, это зияющие функциональные дыры в osTicket.

+1 ричбодо

+1 !!!

несмотря на множество запросов на функцию слияния, никакого прогресса ???

:( это займет много времени? Билет слияния очень полезен.

Слияние не особенно важно, так как над ним есть более важные функции / функции.
Я бы не ожидал, что функция слияния какое-то время.

Печально за это :) но я понимаю, что у тебя много работы.
В эти дни я использовал много функций слияния в других билетах с открытым исходным кодом, поэтому ... этого действительно не хватает в OsTicket.

Что ж, я надеюсь, что этот проект Merge не забудется.

Для меня в OsTicket есть три вещи, которые нужно реализовать/исправить:

• Объединить билеты (этот выпуск)
• Редактирование темы в тикете (уже сделано и скоро будет выпущено, отлично!) https://github.com/osTicket/osTicket-1.8/issues/1173
• Исправьте неправильное время на странице регистрации пользователя https://github.com/osTicket/osTicket-1.8/issues/1842
• Исправить ошибку в ссылке на билет https://github.com/osTicket/osTicket-1.8/issues/2024
• Возможно адаптивная тема https://github.com/osTicket/osTicket-1.8/issues/2030
• Автоматическое закрытие тикета на определенных статуях https://github.com/osTicket/osTicket-1.8/issues/2036
  И OsTicket будет лучшим с открытым исходным кодом

Вау, сколько людей следят за этим :-) Объединяем билеты, отлично!

Ожидание слияния с нетерпеливым ожиданием!

Сейчас я добавляю код в себя, поэтому не буду обновляться после 1.9.4, пока Merge не станет одним из добавленных функций.

Если существует стабильный код для слияния тикетов, почему бы не добавить его в основную ветку?
Вроде есть спрос...
Слияние было бы огромным улучшением для нас!

Да, слияние билетов очень пользовательское.

Inviato да мобильных устройств. | Отправлено мобильным устройством
Il 13 марта 2015 г., 07:03, "Эдди-БС" с уведомлением@github.com , в сценарии:

Если существует стабильный код для слияния тикетов, то почему бы не добавить его в основной
филиал ?
Вроде есть спрос...
Слияние было бы огромным улучшением для нас!

—
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

Слияние билетов было бы для нас огромным преимуществом, поскольку мы много раз сталкивались со случаем, когда пользователь создавал билеты под двумя адресами электронной почты, и мы хотим объединить их все в одну учетную запись, и в настоящее время это нужно делать по одному. используя владельца изменения (или вам нужно написать запрос, чтобы сделать это из серверной части, но это всегда опасно, потому что вы можете пропустить что-то, что обычно обрабатывалось программным обеспечением).

Будет полезно также объединить один и тот же пользовательский билет, но другой билет, поэтому, если пользователь А сделает два разных билета, они смогут объединиться в один.

+1 за это тоже. Очень хочется, чтобы в OSTicket однажды появилась эта функция.

+1 за эту функцию, было бы идеально, если бы это было возможно

+1

Представьте, если бы на Github не было функции слияния...

+1

Объединение билетов было бы очень полезным дополнением. Мне нравится, как идут дела с 1.10rc1, но в код было внесено так много изменений, что старые настройки слияния не так просто реализовать. Я хотел бы быть более подкованным в PHP.

+1

+1 Очень нужно!

Потрясающе детализированная функция интернационализации, реализованная в версии 1.10, реализована, и теперь осталась еще одна функция — объединение заявок, которая очень важна для центров поддержки с большим объемом работы. Я надеюсь, что это привлечет внимание к 1.10 или 1.11, чтобы osTicket опередил другие решения.

+1

Да, я согласен

+1

Что нужно, чтобы кто-то разработал эту функцию и объединил ее с OSTicket?

Несмотря на комментарий ntozier о том, что «слияние не особенно актуально, поскольку над ним есть более важные функции / функции. Я бы не ожидал, что функция слияния какое-то время». основываясь на огромном количестве +1 и дубликатов открытых билетов, я бы сказал, что спрос довольно высок.

Я пишу PHP 16 лет. Я мог бы написать метод слияния. Я хотел бы поговорить с ведущими разработчиками схемы БД и обсудить их мысли о наилучшем способе реализации слияния. Или я могу просмотреть схему и предложить реализацию. Но прежде чем я сделаю что-либо из этого, я хотел бы убедиться, что моя работа может попасть в OSTicket Trunk.

Это возможно?

:+1: для @ooglek

@ooglek
Звучит хорошо и разумно для меня. :)

Разработчики, как вы думаете?
@протич
@greezybacon
@nfebuary

Ага!

:+1:

@ooglek
Круто, что ты проявляешь эту инициативу!

Я совершенно уверен, что @greezybacon тоже благодарен, но я точно не знаю, каковы их правила добавления кого-то на github.
Может быть, вы можете создать функцию слияния рядом?

Но надо дождаться разработчиков и посмотреть.

Еще раз спасибо.

Re: «но я точно не знаю, каковы их правила добавления кого-то на github».
Любой может присоединиться к github и сделать запрос на включение.
Разработчики рассмотрят изменения и примут или отклонят их.

@ntozier
ОК, извините, я имел в виду часть github osticket, а не github в целом, извините: P

Но, похоже, для @ooglek это возможно ;)

Это определенно то, что я хотел бы видеть добавленным к osticket. Эта функция определенно помогла бы мне продать это руководству при принятии этой системы по сравнению с другой системой продажи билетов, которую мы используем.

+1

Добавляю свой собственный +1 в микс.

Мы хотим отказаться от другого решения для продажи билетов, и слияние необходимо. Мы получаем много новых тикетов, которые должны быть ответами на существующие, и, поскольку нам нужно точно отслеживать использование тикетов, мы в конечном итоге объединяем много.

Я думал об этом последние несколько дней. Я буду работать над пользовательским интерфейсом, и я разговаривал с @greezybacon, и он также упомянул, что вложил в это немного энергии (его график немного сумасшедший, так что имейте это в виду) @ooglek приветствует любую помощь, мы с вами можем обсудить пользовательский интерфейс, и вы можете обсудить бэкэнд с @greezybacon. Я думаю, что мы можем получить это идет. ну и +1

Может ли кто-нибудь составить более формальный RFC по процессу слияния, чтобы мы могли решить проблемы с процессом слияния и разработать некоторые определения того, как это сделать в osTicket? Я думаю, что некоторые из вопросов, затронутых до сих пор:

• Как объединяются темы? Есть предметы из разрозненных билетов:
  
  
  
  • Переплетены в хронологическом порядке
  
  
  • Цепочка из свернутой заявки (заявок) добавляется в конец цепочки объединенной заявки.
  
  
  • Отдельные потоки, отображаемые в пользовательском интерфейсе через отдельные вкладки
  
  
  • Объединение потоков не выполняется. Вместо этого заявки закрываются, а ссылки на «связанные заявки» добавляются в объединенную заявку.
  
  
• Как объединяются метаданные? В частности
  
  
  
  • Срок выполнения
  
  
  • Назначенные лица (персонал и команда), а также направляемый отдел
  
  
  • Пользовательские данные и формы, добавленные в соответствующие заявки
  
  
• Каков процесс слияния?
  
  
  
  • Действие множественного выбора из очереди листинга билетов
  
  
  • Действие из раскрывающегося списка «Больше» в представлении заявок
  
  

Я мог бы попытаться напечатать что-нибудь, но у меня нет сильного варианта использования этой функции, поэтому я думаю, что у других, вероятно, возникнут более сильные чувства и указания относительно того, как все должно работать.

В данный момент несколько занят, но мои ближайшие мысли таковы:

• Индивидуальный выбор хронологического слияния или добавления потоков
• Решения по каждому пункту в отношении сроков выполнения, исполнителей и т. д.
• Действие из раскрывающегося списка «Еще»

Наша текущая проблема (и ее можно несколько смягчить за счет портала, а не только электронной почты) заключается в том, что пользователь открывает заявку, не получая ответа в течение нескольких часов (он мог открыть заявку в нерабочее время или мы могли бы быть в отпуске), а затем открыть еще один вопрос, получили ли мы первый. Мы либо должны закрыть тот, который сбрасывает наш учет, либо объединиться.

В другом случае люди откроют тикет, а затем отправят дополнительную информацию в отдельном электронном письме, которое из-за другой строки темы будет зарегистрировано как новый тикет. Это также потенциально может быть смягчено с помощью портала, но мы хотим сохранить возможность разрешить отправку билетов по электронной почте.

@greezybacon
Я думаю, сначала было бы хорошо увидеть два варианта:

1)
Из Заявки A и Заявки B объединиться (как связанная заметка) с Заявкой C.
На этом шаге автоматически информация о слиянии должна отправляться пользователю и
закрыть А и Б.

• То есть теперь, когда вы видите под «открытым» билетом C, вы можете увидеть более старые или
  дополнительные параметры, просто перейдя к связанным.

2)
Билет A и билет B сливаются в НОВЫЙ билет C.
Те же функции, что и выше, но билет C будет создан новым с помощью реализации
существующие.

На мой взгляд, это главное, что нужно для поддержания системы билетов в чистоте.

ПОСЛЕ возможность переключать Билет A или Билет B непосредственно в Билете
C было бы хорошо, но я думаю, что это требует некоторого времени (темы и т. д.) и не
так важно для основного слияния атм.

ВАШЕ ЗДОРОВЬЕ!

Я не думаю, что объединение заявок должно приводить к созданию новой заявки

Я не буду называть имена, но наше текущее решение работает следующим образом: вы выбираете идентификатор заявки, в которую хотите объединиться, а затем все содержимое другой заявки заменяется сообщением типа «Идентификатор заявки XXX имеет объединены в ID YYY". Это сохраняет тот факт, что слияние было выполнено без создания нового тикета. Однако, поскольку мы выставляем счет на основе использования билетов, остается два билета, хотя фактически должен быть только один.

Поэтому важно вести запись того, что происходило, но также важно делать это понятным и интуитивно понятным способом.

Один из способов, которым это делал OTRS, заключался в «связывании» билетов. Например, одна заявка будет считаться «главной», а другие заявки будут объединены с ней.

На дисплее вся корреспонденция будет «объединена» и отображена в хронологическом порядке, независимо от того, из каких связанных билетов исходит корреспонденция.

Это позволяет установить отношения между родителями и детьми. Вы также можете «связать» билеты таким образом, чтобы они были связаны, но все же это были два отдельных билета.

Билеты, которые считались детскими, не отображались на экране «Открыто/Закрыто/Решено» и не учитывались.

Я согласен с @greezybacon в том, что слияние НЕ должно создавать новый тикет.

По моему искреннему мнению, после того, как заявки созданы, их не следует изменять в структуре БД, а использовать программное обеспечение для их «объединения». Таким образом, возможно «разъединение», хотя новая корреспонденция будет добавлена ​​только к «главной» заявке, даже если старая заявка получила новую корреспонденцию. Хотя на самом деле это не обязательно, но я думаю, что было бы чище «заморозить» дочерние билеты, когда они связаны с родительским/мастером.

Не в первую очередь, правильно.

Но часто вам нужна эта опция при очистке билетов.
Итак, вы узнали новые обновления или связи.

Теперь вы можете добавить его в существующий тикет, но не знаете, в какой из них, или вы сначала создаете новый, а затем объединяете их.

Почему нет возможности напрямую слиться с новым?

Опять же, я понимаю, что «слияние» в первом случае означает объединение вещей, но в последнем варианте вы можете создать новый билет, чтобы именно это сделать.

PS: Только мои два цента на это точно: P

ВАШЕ ЗДОРОВЬЕ

@ Hannibal226 -- Создание новой заявки -- как клиент отвечает на старую заявку? Как это обрабатывается? По крайней мере, при сохранении структуры данных и создании связи между двумя заявками клиент может ответить на любую заявку, и код обработки ответа не нужно менять — он может войти в любую заявку (да, это это не то, что я предложил с заморозкой детского билета, я выбрасываю варианты). Все, что вам нужно сделать, когда вы подтягиваете билет, это:

• В этом билете есть дети? Если это так, получите все ответы из этой заявки и объедините их вместе с этой заявкой для отображения.
• У этого билета есть родитель? Если это так, перенаправьте и отобразите родительский элемент вместо дочернего.
• При подсчете и отображении «открытых/закрытых/разрешенных» заявок игнорируйте и не учитывайте заявки, связанные как дочерние с другой родительской/главной заявкой.

Модификации намного проще, потому что вам не нужно менять логику обработки входящего ответа... сильно. Я просто подумал о нескольких вещах.

• Изменения статуса: Закрывает ли мастер закрытие дочернего/дочерних элементов? Или статус ребенка/детей игнорируется?
• Ответ клиента на дочернюю заявку должен повторно открыть основную заявку.
• Должен ли статус быть синхронизирован между мастером и дочерним элементом?

Я думаю, что сохранение структуры существующей системы как можно более похожей, добавление сложности только там, где это абсолютно необходимо, а также отсутствие копирования данных или запуска обновлений идентификаторов будет лучше всего служить и, вероятно, уменьшит проблему, связанную с тем, чтобы заставить ее работать.

Лично мне нравится идея «связанных» заявок, и я думаю о слиянии больше как о «группе заявок». Таким образом, когда пользователи Алиса, Боб и Чарли сообщают об одной и той же проблеме, эти заявки затем связываются друг с другом, и агент может (подумайте об электронной почте «ответить» вместо функции «ответить всем»), а затем обновить, ответить и т. д. до конца. пользователей (Алиса Боб Чарли) через связанные/объединенные заявки или только одному пользователю (Боб).

Я думаю, что если делать это таким образом со связанными заявками, самая сложная часть - сделать пользовательский интерфейс настолько интуитивно понятным, чтобы он был простым и понятным, независимо от того, обновляете ли вы / отвечаете / и т. Д. Агенту «группу заявок» (как я бы назвал это) или к единому билету.

С точки зрения конечного пользователя, я думаю, было бы разумно получить информацию, которую другие пользователи сообщили о том же, и все или только я (как единственный конечный пользователь) теперь получаю ответ от агента на основе смысла и фактов, таких как важность сообщение от агента.

Я думаю, что объединение билетов действительно сложно реализовать, поскольку существует множество способов, как это можно реализовать, а также множество различных вариантов использования подходов к объединению билетов.

Ваше здоровье,
Майкл

Мы поговорили о добавлении понятия «Проблема». Проблемы похожи на отношения между заявками и задачами. Тем не менее, билеты привязаны к задачам как родительские/дочерние отношения. Вариант использования, который я часто использовал, — сбой в работе центра обработки данных. ИТ-группа, скорее всего, получит несколько уведомлений о заявках, связанных с «проблемой» отключения центра обработки данных. Таким образом, можно создать новую задачу и связать с ней все тикеты. Ответы на проблему транслируются соответствующим владельцам билетов. Когда проблема закрыта, то и все дочерние билеты тоже.

Я думаю, что слияние — это нечто совершенно другое. Мы часто думали о слиянии как об операции замены. При объединении заявок все заявки, кроме последней, эффективно удаляются. Потоки доступны только из одного оставшегося объединенного тикета. Ответы по электронной почте в версии 1.10 больше не связаны с заявкой; вместо этого они связаны с потоком. Таким образом, если заявка удаляется при объединении, а поток каким-либо образом связан с объединенной заявкой, то ответы на свернутые/удаленные заявки будут продолжены в объединенной заявке через ее поток(и).

@ooglek

Но что у вас есть от объединенного билета C, когда пользователь отвечает на билеты A и B?
Я думаю, что с вещами «родители/дети» это сложнее, чем просто иметь ссылки на билеты, которые только что закрылись.

Так что, на мой взгляд, все пользователи и соавторы должны быть объединены...

Чтобы остановиться на примере нового билета (это не основная функция, о которой мы говорим), мы всегда должны идти вперед от одного билета:

Итак, перейдите в Заявку B и создайте новую Заявку C, что означает, что все пользователи и соавторы будут использоваться, как в B.
Затем вам нужно объединить Заявку A, которая будет включать только Соавторов, если она еще не существует, с Заявкой C.

ВАШЕ ЗДОРОВЬЕ

@Chefkeks Я не могу согласиться с группировкой билетов с точки зрения пользователя. Это слишком близко к смешиванию потенциально конфиденциальной информации из билетов разных клиентов и слишком легко может привести к перекрестному заражению.

Я действительно думаю, что это то, где Проблемы были бы удобны. В качестве примера рабочего процесса:

Три отдельные организации/пользователи сообщают об одной и той же ошибке в процессе обновления, поэтому мы создаем проблему, например «Ошибка, полученная при обновлении», а затем связываем эти заявки с этой проблемой. Затем создайте задачу для устранения ошибки и свяжите эту задачу с этой проблемой, а также свяжите билеты.

-извините, нажал не ту кнопку в новом приложении-

Я очень заинтересован в этом, однако это кажется довольно сложным. мои требования - (и это могут быть только мои) намного проще.

клиент а создает тикет, клиент б (или клиент а с другим адресом электронной почты) пишет об этом тикете, но не отвечает в исходной ветке. Теперь я копирую содержимое письма как внутреннюю заметку и добавляю второй адрес электронной почты в качестве соавтора.

Это работает, но проблема в том, что вложения нельзя передавать с помощью копирования и вставки.
поэтому для меня было бы достаточно очень простого слияния или прикрепления сообщения к существующему билету.

@snizzleorg
Это не проще, что вы имеете в виду, то, что вы делаете, просто больше вручную: P

Итак, мы говорим о том, чтобы сделать ссылку на весь тикет, а ты говоришь о том, чтобы получить текстовое сообщение из тикета.
По крайней мере, нам всем нужно одно и то же, но способов несколько, и теперь вопрос о наиболее удобных/полезных.

Или ты хочешь сказать мне, что одна кнопка не будет лучше, чем копировать и закрывать все вручную? :П
(возможна даже копия приложения)

ВАШЕ ЗДОРОВЬЕ

Хорошо, я думаю, что «проблемы», как объяснил @greezybacon , - это то, что я имел в виду под «группой билетов».

Что касается точки зрения конечного пользователя и безопасности данных/личной информации из отдельных билетов, вы можете немного ошибиться.
Моя идея была больше похожа на обычный ответ, который транслируется всем владельцам билетов, чтобы все они получали информацию от агента, а также, в зависимости от организации, к которой принадлежат владельцы билетов, то, что сообщили другие пользователи. Таким образом, тикеты остаются индивидуальными для конечных пользователей, но с некоторыми возможностями для агентов, чтобы упростить обработку тикетов с той же проблемой.

Тем не менее, прочитав, что Джаред написал о «проблемах» и о том, что он думает об объединении заявок как о чем-то совершенно другом, я должен признать, что я больше «поклонник» «проблем» и чувствую, что это может быть лучше. слияние или, скажем, обработка/управление билетами.

Майкл

@шефкекс

Но не кажется ли вам, что становится запутанным и сложным (в кодировании) иметь один билет/трансляцию для сотрудников, но отдельные для пользователей?

Я думаю, что тогда намного проще заменить существующие билеты от пользователей или, лучше сказать, против одного.
Так что это должно происходить автоматически, когда "старые" тикеты закрываются, а тот же пользователь/сотрудник r в новом тикете.

Теперь пользователь также может видеть, что в этом случае что-то происходит, что, возможно, является лишь частью, так как это материал из второго билета (теоретически теперь немного xD)

ВАШЕ ЗДОРОВЬЕ

Есть потребность в обоих. Существует необходимость обработки нескольких запросов от одного пользователя, которые должны быть объединены или «объединены». Существует отдельная потребность в объединении нескольких различных запросов, связанных общей «проблемой». Группировка задач не подразумевает предоставления пользователям доступа к заявкам друг друга. Тем не менее, это подразумевает концепцию «общедоступных тикетов», когда проблема может быть опубликована на клиентском портале с указанием чего-то вроде «В настоящее время нам известно о проблемах с центром обработки данных ...»

Эти два должны стать отдельными функциями. Их не следует совмещать.

Я полностью согласен с этим!

Эти два должны стать отдельными функциями. Их не следует совмещать.

Итак, я думаю, имея в виду ваш последний пост, Джаред, здесь, на github, должно быть 2 проблемы RFC, чтобы обсуждать обе независимо друг от друга, но со ссылкой друг на друга, чтобы люди обсуждали либо только слияние заявок, либо проблемы/группы заявок. .

Ваше здоровье
Майкл

PS: Поскольку команда osTicket действительно имеет опыт кодирования и дизайна пользовательского интерфейса, я не беспокоюсь о том, что это может быть слишком запутанным ни для агентов, ни для конечных пользователей.

@greezybacon

Но почему так «сложно»?

Пользователи могут получить доступ только к заявкам, которые им разрешены.
Так почему бы не сделать вывод о том, что вы хотите, поскольку пользователи не могут получить доступ, например, к билету другого, если они не являются соавторами?
Я думаю, если привилегии работают хорошо, не должно быть разделения на это.

U даже мог бы назвать «проблему» - «проект» или «задача» или «группа», но человек x может получить доступ только к основной (объединенной) заявке и заявкам внутри, насколько он является ее создателем или соавтором.

Может быть, я думаю, что в этом случае я немного маловат, но я не уверен, станет ли это слишком большим, если вы начнете разделяться, так как, возможно, появятся новые дела и запросы на дела между ними, или?

PS: я просто думаю о пользователе и почти о реализации, извините, если звучит так легко и не совсем точно xD xD

ВАШЕ ЗДОРОВЬЕ

«Проблема» подразумевает совершенно новую парадигму для понимания и управления пользователями OST. Как сказал @snizzleorg , когда клиенты А отправляют электронные письма и электронные письма клиента Б (или электронные письма клиента А с другого адреса), это 90% моих случаев слияния.

Какое-то время было приятно иметь один тикет и иметь возможность общаться с человеком А по поводу проблемы, а затем общаться с поставщиком Б по той же проблеме, но исключая человека А, но все по одному и тому же тикету в OTRS. Но мне это не нужно, просто было приятно.

Мне лично очень не нравится идея создания «Проблемы», потому что я сказал системе, что эти две заявки на самом деле об одной и той же проблеме, независимо от того, кто находится в заявке.

Как упомянул @tmcnag , я думаю, что «перекрестное загрязнение» - это то, что должен решать пользователь, а не инструмент. В некоторых случаях, по вашему мнению, я могу захотеть «перекрестно заразить», но по моему это инструмент.

Почему Билет A и Билет B, когда клиент отправил электронное письмо один раз, а затем отправил электронное письмо снова через 5 минут, чтобы сказать «Ой, неважно», но не ответил на Билет A, почему это должно стать «проблемой» - они действительно только один билет, который клиент не смог пройти через процесс, чтобы сделать его одним билетом. Я просто хочу проверить две (или три, или четыре) заявки и «объединить» их (IMO свяжет их на случай, если я неправильно объединим неправильные) и иметь единую унифицированную временную шкалу ответов и разговоров, которая позволит мне управлять всем в одном билете, как и предполагал _I_, даже если клиент «не поступил правильно», ответив на нужное электронное письмо.

Я думаю, что добавление «Вопросов» делает это еще более сложным — в 90% случаев клиенту дважды отправят электронное письмо об одном и том же, и я хочу, чтобы они были в одном и том же тикете.

Согласитесь с @greezybacon. Проблемы — полезная концепция. Объединение билетов — полезная функция. Они должны разрабатываться отдельно, а не кооптироваться.

Мне нравится идея нового типа билета (выпуска), который будет чем-то вроде мега-билета. Который можно использовать для объединения нескольких тикетов в один выпуск... или даже открыть его персоналом, когда/если случится что-то важное, затронувшее многих. Лично я бы редко использовал это на любом из моих живых сайтов. Но я мог бы захотеть использовать их для таких вещей, как плановое техническое обслуживание, большие перебои в работе сети и т. д.

При этом я, вероятно, чаще использовал бы функцию слияния. Я надеюсь, что это будет что-то вроде того, как мы делаем это вручную сейчас. То есть обновить один тикет (позже созданный), заявив, что для этой проблемы уже открыт тикет (справочный тикет №), закрывая дубликат тикета. а затем обновить исходный тикет любой дополнительной информацией и добавить открывателя второго в качестве соавтора.

Я с @ooglek Проблемы и слияние - это разные вещи. Слияние было бы наиболее полезным для нашей компании, а концепция проблем - не уверена, что она нам нужна. Хотя приятно...

Я чувствую, что все еще есть некоторая путаница.

Объединение заявок, владельцев, потоков и данных:

• что вызывает "заражение"
• чтобы помочь сохранить одну и ту же проблему от одного и того же человека или группы лиц в одних и тех же данных и потоке связи
• (возможно) удаляет тикеты при объединении с другим

Связывание заявок через задачи

• держит (все) вещи отдельно
• позволяет раздельно общаться, данные, владельцы, сотрудники по «связанным» вопросам
• добавляет «связанные» билеты в просмотр билетов
• добавляет в систему новый список предметов, "проблемы"
• допускает массовую коммуникацию и закрытие

@greezybacon хорошее подведение итогов. так что в основном две новые функции

@snizzleorg Я предполагаю, что именно так будут работать две функции. Я надеюсь устранить некоторую путаницу, предложив разные цели для двух разных функций. Я надеюсь, что все будут согласны друг с другом, чтобы мы могли работать над продвижением RFC и реализацией функций.

Хороший. Как я уже сказал, меня больше интересует слияние, и я думаю, что, по крайней мере, эта функция хорошо изложена. Остается вопрос, как выбрать владельца результирующего тикета, если два исходных тикета различны и конфликты разрешены в самих данных тикета.

Я предлагаю:

1 + слияние 2 = данные/владелец тикета 1

2 + слияние 1 = данные/владелец тикета 2

Я голосую за то, чтобы предоставить пользователю (агенту) выбор, какие данные будут иметь объединенный тикет.

Поэтому дайте пользователю предварительное определение/предложение данных объединенного тикета, которые он может
A) принять и продолжить слияние или
B) полностью изменить направление слияния (таким образом, 2 + слияние 1 = данные/владелец заявки 1 вместо заявки 2) или
C) редактировать отдельные поля (например, раздел справки) перед объединением заявок

@greezybacon Что касается слияния билетов, я думаю, что существует некоторая путаница в отношении эффекта слияния для пользователя и фактических средств слияния в бэкэнде.

• Загрязнение — если оба билета хранятся в базе данных отдельно, загрязнения нет. После действия «слияния» будет создана «ссылка» между двумя заявками и тип отношения (заявка 3 является дочерней по отношению к заявке 4, заявка 4 является родительской для заявки 3). Программное обеспечение будет синхронизировать связанные статусы заявок — при изменении статуса родительской заявки изменяются статусы всех дочерних заявок. Когда дочерняя заявка получает электронное сообщение, это сообщение обновляется, и любое изменение статуса дочерней заявки синхронизируется со всеми связанными заявками. Заявка 4 будет отображать сообщение, обновленное в Заявке 3. В этом случае не будет загрязнения, и вы всегда сможете разъединить (разъединить) две заявки практически без каких-либо последствий (единственный эффект, о котором я могу думать, это добавление соавторов). от дочерних заявок к родительским заявкам при объединении, и вы, вероятно, не захотите отменять это при разъединении).
• Сохранение соавторов . Я считаю, что 90% слияний будут исходить от одного и того же человека, либо из одного и того же электронного письма, либо из двух разных электронных писем, управляемых одним и тем же человеком. Обеспокоенность этих 10% заключается в том, чтобы просто тщательно документировать (а также в пользовательском интерфейсе во время слияния) то, что будет сделано (автоматическое добавление соавторов в мастер-заявку из дочерних (дочерних) заявок)) и убедиться, что пользователь знает что, если это не то, чего они хотят, отменить это. Или добавьте флажок, который по умолчанию установлен, «Объединить владельцев заявок с соавторами в родительском/главном», и если вы снимите флажок, соавторы не будут изменены в родительском.
• Удаление билетов -- НЕТ! Не делай этого. Плохо.

Проблемы — это новая функция, пока (насколько мне известно) не разработанная, не определенная и аморфная. Можете ли вы использовать задачи для объединения заявок? Полностью! Но действительно ли цель функции «Проблемы» — объединить тикеты? Или вы запутываете Issues, чтобы включить слияние, потому что это кажется проще?

Если проблемы являются общими проблемами, с которыми сталкиваются несколько клиентов, действительно ли пользователи / администраторы OST хотят видеть в списке кучу проблем с «объединенными заявками»? Многим пользователям OST могут быть не нужны задачи, и я был бы сбит с толку, если бы слияние билетов «создало» задачу. Вы теряете контекст заявки, когда она становится проблемой — теперь мне приходится обрабатывать «объединенные заявки» не так, как обычные заявки, и переключаться на совершенно другую область в OST для управления объединенными заявками, которые затем выходят за рамки правил, эскалация и работа в OST Обычных билетов.

Я действительно, действительно твердо убежден, что использование Issues для реализации Merge Tickets вызовет гораздо больше проблем и проблем, как для разработчиков OST, так и для пользователей OST, чем поиск способа неразрушающей реализации Merge Tickets в существующей структуре Tickets, поскольку они существуют сегодня, с добавлением таблицы или двух в БД и некоторого кода и триггеров для обработки действий над связанными заявками.

@snizzleorg Я думаю, вы неправильно поняли комментарий @greezybacon - он не говорил «две разные функции», он говорил: «Проблемы решают все чисто». С чем я не согласен выше.

@ooglek Вы объединяете концепции задач (связанных заявок) и слияния. Как вы можете объединить две вещи и получить две вещи, которые связаны между собой? Идея слияния подразумевает объединение нескольких вещей в одну; следовательно, удаление объединенных элементов.

@greezybacon @ooglek

МОЕ мнение по этому поводу таково: при просмотре базы данных ooglek прав, и билеты не должны просто удаляться.
По использованию/интерфейсу сайт greezy прав, и вам нужно скрыть/заменить старые вещи, иначе слияние бессмысленно.

НО опять же, почему так сложно?
Почему заявки просто закрываются при слиянии (может быть, определенный статус слияния)?

Это означает, что билеты по-прежнему доступны или лучше видны через основной билет/выпуск, но их больше нельзя изменить.
Или, может быть, будет реализован своего рода снимок, чтобы вы могли переключать его и т. Д. (Но это дизайн позже)

И это тот момент, когда слияние и выпуск могут быть разделены (МОЕ мнение), поэтому при слиянии тикеты закрываются, а при выпуске это список «открытых» тикетов.

ВАШЕ ЗДОРОВЬЕ

@greezybacon Слияние — это концепция пользовательского интерфейса, а не концепция бэкэнда. С точки зрения пользователя, заявка выглядит объединенной, потому что, как только они выполняют действие «Объединить», они видят, что основная заявка имеет всю корреспонденцию в хронологическом порядке в их представлении, и ответ направляется всем сторонам, объединенным (или исключенным во время объединения). ). Итак, пользователь видит объединенный тикет.

Что касается серверной части, вы хотите сделать все как можно более чистым и необратимым. Создавая отношения между 2+ билетами, вы можете:

• Принимайте ответы на дочерние заявки по электронной почте, потому что эта заявка все еще существует — для обработки входящих электронных писем с заявками, которые больше не существуют, не требуется дополнительный код или структура БД.
• Разъединить — ответы будут привязаны к соответствующим заявкам — единственная нерешенная проблема — объединенные соавторы, которые потенциально могут быть решены при разъединении.
• История -- История тикетов все еще существует, и вы можете просматривать ее напрямую, никаких новых изменений программного обеспечения.
• Представление Open/Resolved/Closed -- поскольку дочерние заявки, с точки зрения пользователя, объединены, дочерние заявки не отображаются в этих представлениях.

Чтобы реализовать слияние таким неразрушающим образом, я вижу три основных изменения и одно небольшое добавление функции/функции:

• Таблица отношений. Связывает заявку с другой заявкой с типом отношения.
• Изменить открытое/разрешенное/закрытое представление заявок. Исключить билеты, которые являются детьми.
• Изменить View Ticket. Объединить корреспонденцию из заявок родителей и детей в режиме реального времени -- например, выбрать * из корреспонденции, где билеты в (ticketA, ticketB) упорядочены по полученной дате описания. А при просмотре дочерней заявки ясно дайте понять, что она активно помечена как дочерняя и доступна только для чтения, и вы не можете на нее ответить. Добавьте ссылку на мастер-тикет.
• Новый код: слияние добавляет отношения и копирует (необязательный флажок или, что еще лучше, поле с несколькими вариантами выбора со всей информацией о клиенте и соавторе) клиента и соавторов в качестве соавторов в мастер-тикете.

Это значительно упрощает слияние, позволяет вам не изменять большие участки кода для обработки «объединенных» тикетов, оставляет за собой исторический след, чтобы вы могли исследовать, когда тикет был «объединен» или «разъединен», и почти полностью неразрушающий. (изменение в мастер-тикете сотрудников может быть истолковано как деструктивное; я так не думаю, но я не хочу сбрасывать со счетов эту точку зрения).

@ Hannibal226 и я, кажется, согласны по большинству пунктов. Я не думаю, что объединенные дочерние (детские) заявки должны быть закрыты - я думаю, что при изменении основного статуса изменяется дочерний статус и наоборот.

Например, если основная заявка имеет статус «Решено», а клиент с дочерней заявкой отвечает по электронной почте, то дочерняя заявка должна вернуться к статусу «Открыта», и, таким образом, основная и все остальные дочерние заявки также должны вернуться к статусу «Открыта».

Если вы закроете все дочерние заявки как «Объединенные», вам придется более сильно изменить логику обработки новых входящих писем. Заявка имеет статус "Объединен?" Вы по-прежнему добавляете корреспонденцию в исходный детский билет? Или теперь вы изменяете мастер (что, я думаю, может привести к гигантскому беспорядку, если слияние было ошибкой, сделанной прошлой ночью, клиент (ы) ответили три разных раза, затем я пошел, чтобы разъединить их - и теперь переписка клиента находится в билете клиента B.

@ooglek

Таким образом, вы хотите открыть билет A, B и «мастер» C до почты, идущей в билет A.

Но, не зная кода, я бы сказал, что это, по крайней мере, сложно/легко, когда почта приходит в A, которая является объединенной из C.
Это означает, что только C переходит в онлайн.
Так что здесь нужна только одна процедура (флаг или через таблицу отношений [как не упомянуто]).

Ощущение слияния очищает. Таким образом, открывать билеты, которые также объединены, не нужно, так как держать их открытыми при объединении. (на мой взгляд)
Таким образом, заявки A и B просто становятся невидимыми/заменяются (для всех пользователей и соавторов), как только они объединяются, поэтому их можно закрыть (завершить/забыть).
В большинстве случаев они вам никогда больше не понадобятся, так зачем постоянно менять статус?
Только в некоторых случаях вы, возможно, захотите что-то проверить, поэтому вы можете перейти к этому по ссылкам и, в последнем случае, разъединиться.

Итак, я вижу наше согласие в:

• Нет закрытия тикета
• Проблемы не слияния, но слияние может решить проблемы (по крайней мере, я вас так понимаю)
• Функция объединения/разъединения
• Объединяйте в основном пользовательский интерфейс, но меньше БД

но наши настоящие разные взгляды могут быть на:

• дочерний элемент - мастер (потому что, на мой взгляд, больше БД, чем пользовательский интерфейс)
• статус изменился по всем тикетам, а не только на "мастер"

ВАШЕ ЗДОРОВЬЕ!

@Ганнибал226

Мой сценарий работает следующим образом:

• Клиент А отправляет электронное письмо, создает тикет А
• Электронная почта клиента A, тот же адрес электронной почты, создает заявку B
• Электронные письма клиента A, другой адрес электронной почты, создает билет C

Пользователь/агент OST решает использовать Билет A в качестве «Мастера» и объединить Билет B и Билет C в Билет A.

• OST Создает связанную связь, Заявка B является потомком Заявки A.
• OST Создает связанную связь, билет C является дочерним по отношению к билету A.
• Поскольку в этих трех билетах есть два разных электронных письма, пользователь / агент OST решает объединить других пользователей, кроме Мастера, в качестве соавторов; Клиент A Электронное письмо B становится соавтором заявки A

И теперь мы закончили.

Если Клиент А отправляет электронное письмо на Заявку C, эта корреспонденция добавляется в Заявку C, как и сейчас. Если эта корреспонденция вызывает изменение состояния (Разрешено -> Открыто), состояние Заявки C изменяется, как и сейчас, но также изменяется состояние Заявки A и Заявки B, чтобы они совпадали.

Если клиент А отправляет электронное письмо билету Б, происходит то же самое.

Если клиент А отправляет электронное письмо билету А, происходит то же самое.

Когда пользователь/агент OST загружает билет A (объединенный основной билет), он видит всю корреспонденцию из билетов A, B и C во встроенном виде. Мы можем или можем не показывать, что они из объединенного тикета в Просмотре тикетов.

Когда пользователь/агент OST загружает заявку B или C, он видит уведомление о том, что это связанная дочерняя заявка с URL-ссылкой на основную заявку, и что все здесь доступно только для чтения, а ответы должны выполняться в основной заявке. Билет.

Я не совсем уверен, что вы имеете в виду во втором абзаце. Можешь перефразировать?

Параграф 3: Я по-прежнему не согласен с тем, что Детские Заявки (в вашем примечании, Заявки А и Заявки Б) должны быть закрыты. Что происходит, когда клиент отвечает на этот дочерний тикет? Теперь вам нужно изменить способ обработки заявок, которые находятся в новом состоянии (Закрытое объединение) или в состоянии плюс статус отношения (Закрытое + дочернее), а затем добавить логику для изменения состояния Мастера. А если статус Closed, то переписка должна быть добавлена ​​не в этот тикет, а в Master. Но когда вы это сделаете, вы потеряете возможность разъединения, потому что теперь корреспонденция, которая пришла, предназначенная для билета A (дочерний), записывается в БД для билета C (главный), и если вы разъедините, как вы вытащите корреспонденцию в Билет C (главный), предназначенный для билета A (дочерний), обратно в билет A?

Я считаю, что клиенты долго хранят билеты — у меня есть электронные письма от клиентов о билетах, открытых 2 года назад, — и я хочу убедиться, что эти билеты будут адресованы.

Я вижу наше соглашение здесь как:

• Нет закрытия тикета
• Предлагайте функции слияния и разделения
• Слияние — это в основном просто изменения пользовательского интерфейса, минимальные изменения БД и минимальные изменения кода и процессов.

И мы не согласны с:

• Как реализовать отношения «потомок-хозяин»
  ** я: Просто таблица отношений
  ** ты: ??
• Проблемы
  ** я: Проблемы — это отдельная функция, упомянутая в этой теме, но IMO не связана с реализацией функций слияния.
  ** ты: ??
• Состояние основных и дочерних билетов
  ** я: Я считаю, что состояние основного и дочернего тикета должно оставаться синхронизированным, чтобы клиенты могли отвечать на любой из тикетов, и эта корреспонденция попадала в предназначенный покупателю тикет, чтобы во время разъединения была согласованность и не смешивалось непреднамеренные ответы
  ** ты: ??

Я с нетерпением жду, когда вы поделитесь своими мыслями о том, чем мы отличаемся.

Есть ли мастер-группа разработчиков OST? Какой-то процесс?

@ooglek

• Как реализовать отношения дочерний-хозяин ** я: Просто таблица отношений ** вы: ??
• Состояние основной и дочерней заявок ** я: Я считаю, что состояние основной и дочерней заявок должно оставаться синхронизированным, чтобы клиенты могли отвечать на любую из заявок, и эта корреспонденция попадала в заявку, предназначенную для клиента, так что во время разъединения это согласованность и отсутствие смешивания непреднамеренных ответов ** вы: ??
  
  
  
  • Прежде всего, мы сближаемся с отношением «хозяин-потомок» и таблицей отношений.
  
  
  • Так что здесь я согласен, НО не с управлением статусами через несколько тикетов.
    
    Изменения статуса повторного открытия должны влиять только на «мастер» (в нашем примере A) - на мой взгляд.
  
  
  • Вся коммуникация должна быть просто «перенаправлена» на мастер, если она объединена. Потому что, почему вы должны использовать слияние, когда вы хотите добавить что-то в тикет B или C впоследствии? [поэтому разъединить]
  
  
• Проблемы ** я: Проблемы — это отдельная функция, упомянутая в этой теме, но ИМО не связанная с реализацией функций слияния ** вы: ??
  
  
  
  • Потому что Проблемы: Ты прав, и мы можем обсудить это в другое время :P
    
    Я думаю, что только другая обработка статуса (отдельно от мастера) и создание нового билета могут принести функцию проблемы, без полного «перепроектирования / реализации» здесь.
  
  

Я рад интересу и движениям по этому «запросу функции»;)

ВАШЕ ЗДОРОВЬЕ!

@Ганнибал226

• Отношения -- согласовано
• Состояние билетов. Причина, по которой я предлагаю синхронизировать состояние с Master и Child, связана со случаем, когда приходит электронное письмо, предназначенное для Child.
  
  
  
  • Если мы «закроем» детские тикеты, что нам делать с этим новым письмом? Если мы добавим его в переписку Мастера, то "Размерить" начисто не получится. Если мы добавим его в корреспонденцию дочернего элемента, чтобы обеспечить безопасное разъединение, теперь нам нужно отменить существующий код изменения состояния, который сделал бы дочерний элемент «открытым», но теперь мы должны подавить это и изменить только мастер на «открытый». ". Это некоторые фундаментальные изменения.
  
  
  • Если мы синхронизируем дочерний/основной, новое электронное письмо попадает в дочерний тикет, дочерний статус обновляется, и это (дополнительный код, не изменяющий существующий код) запускает обновление статуса для других дочерних и основных тикетов. Это лишь часть добавленного кода, а не логическое изменение в коде обработки новой электронной почты.
  
  
  • Я думаю, что последний чище, сохраняя логику как есть и просто добавляя один дополнительный шаг для билетов, которые являются частью вышеупомянутой таблицы отношений.
  
  
• Вопросы -- Мы согласны! :-)

@greezybacon Хотелось бы услышать ваши мысли. И это одна из тех вещей, которые вы хотели бы, чтобы я разветвил, изменил, а затем отправил запрос на включение? Или хотите реализовать?

@ooglek

• Состояние билета
  
  
  
  • Туше. Я забыл вариант разъединения, который наверняка будет проще и структурированнее, если письма будут попадать в него напрямую во время слияния.
  
  

Приятно видеть, что мы собрались здесь вместе :P

ВАШЕ ЗДОРОВЬЕ ;)

Пользовательский интерфейс слияния может сочетаться с функцией сворачиваемого потока здесь: # 2699.

Я думаю, у нас должен быть значок в списке заявок, указывающий, объединены ли заявки. Тогда агенты узнают, могут ли они отменить слияние из списка заявок или из фактического просмотра заявок.

Должно быть системное событие слияния и когда оно произошло в представлении заявки. Заявки, которые объединяются, должны иметь отдельный цветной индикатор, показывающий, что они являются объединенными заявками в потоке. как цвета для сообщений и заметок.

В нижней части диалогового окна ответа он может перечислить адреса электронной почты всех объединенных заявок, и агент может вручную удалить их при ответе. Или используйте раскрывающийся список на кнопке отправки, чтобы выбрать «Ответить всем» или «Ответить родительскому билету». Ответить всем может автоматически заполнять адреса отправителей с возможностью удаления вручную. Я вот думаю вслух.

При фактическом слиянии после проверки билетов и выбора слияния в модальном режиме с параметрами, какой билет является родительским? Какие адреса электронной почты оставить для отправки ответов? Должны быть доступны варианты закрытия, запроса или передачи заявок после выполнения слияния. Возможно ли добавить слияние или перетасовать слияние по дате? Я подумаю о других вещах позже. Это чисто пользовательский интерфейс, я позволю вам, ребята, обсудить бэкэнд, я постараюсь не отставать. :улыбка:

+1

+1

Привет,

Есть новости об этой желаемой функции?

+1

+1

Я уже сделал это для своей версии (v1.9.12). Функция, как показано ниже:

• Пользователь (гость) Foo использует адрес электронной почты [email protected] , отправляет в систему, он создает тикет X-1234.
• Пользователь Foo забыл адрес электронной почты, который он использовал для заявки X-1234, затем он использует адрес электронной почты [email protected] для отправки в систему. Теперь тема письма новая и в ней нет номера тикета. Система создает заявку X-2345.
• Персонал (агент) откроет тикет X-1234, выберет Объединить тикеты. Форма билета Х-1234 и его темы будут сохранены. Темы X-2345 будут объединены в X-1234. Детали формы X-2345 останутся для дальнейшей проверки.

@cosmospham звучит именно так, как мне нужно. у вас есть ветка или какой-то способ скачать ваш код?

@snizzleorg Извините, это частное репо. Поэтому я могу только зафиксировать изменения фиксации для вас. См. изменения в файлах скриншотов 03 https://github.com/cosmospham/test-0

Во-первых, добавьте меню.
Во-вторых, добавьте правило маршрута.
Затем создайте диалоговое окно ajax.
Затем напишите функцию слияния.
Примечание. Обновляйте страницу только после слияния.

Я думаю, вы можете их понять.

Моя компания в настоящее время использует функцию объединения заявок для следующих сценариев:

1. У нас есть оповещения о мониторинге, которые поступают в нашу систему продажи билетов. Допустим, мы получаем предупреждение о том, что брандмауэр выходит из строя. Затем через 30 минут мы получаем тикет о том, что брандмауэр включен. Что мы делаем, так это объединяем два билета и закрываем их. Когда происходит слияние, он объединяет две заявки, и заявка, которая была создана первой, остается заявкой, а новая заявка, которая пришла, становится частью истории заявок.
2. Электронные письма пользователей о проблеме. Затем снова отправляются электронные письма по той же проблеме, но, поскольку они не отправили электронное письмо с номером заявки в теме, система создает еще одну заявку для той же проблемы, открытой тем же пользователем. Объединение двух заявок вместе с первой заявкой, остающейся видимой, и второй открытой заявкой становится частью истории заявки.

Возможность объединить кучу связанных заявок в родительскую «проблему» — это действительно отличная идея, но я думаю, что она должна быть отделена (как думают другие люди) от функции слияния.

+1

+1, эта функция была бы для нас очень ценной. Очень важная часть наших пользователей отвечает на уведомления по электронной почте osticket, используя почтовый клиент, который не учитывает заголовки, ожидаемые osticket.

Это большой спрос на функцию слияния билетов с 2009 года, которую люди обсуждают на форуме osticket.
И я также время от времени проверяю наличие каких-либо обновлений, но, к сожалению, остается только ждать снова и снова.

Почему эта функция так важна (внутри компании)?

• Если одна из служб не работает и 10 пользователей обратятся к вам по той же проблеме, будет создано 10 тикетов.

• Если поставщик услуг или поставщик решил проблему за вас, и вы хотели бы прикрепить его в качестве документа закрытия заявки, вы не можете переслать сообщение в osticket и объединить существующую заявку. Вы должны либо скопировать содержимое, либо сохранить его в формате pdf для загрузки. Но как насчет сообщения, которое ваш поставщик услуг прикрепляет к большому количеству вложений? У вас будет много ручной работы.

• Пользователь создал новый тикет, сообщив о какой-то системной проблеме, но на самом деле мы уже предоставили решение год назад. Зачем нужно объединять старый билет с этим новым? Поскольку при общении с офисным персоналом вам нужно будет освежить их память, дайте им знать, что они повторяют один и тот же вопрос.

+1

+1

+1

+1

По опыту работы в MSP я понимаю, как это повлияет на вашу производительность, поскольку вам придется работать над каждым тикетом отдельно. Будет отличным дополнением!!!

+1

+1

+1

Мы бы очень хотели перенести нашу систему тикетов внутри компании (от Zendesk). Возможность объединять/разделять билеты является ключевым фактором в нашем решении. Нередко бывает, что более 20 заявок поступают из разных источников (продажи, реселлеры, поставщики, грузоотправители, автоматизированные системы, ответы клиентов и т. д. и т. д.). Идея объединить все это вручную была бы не более чем кошмаром.

Мы были бы готовы вложить несколько долларов в финансовом отношении, чтобы помочь запустить процесс. Я понятия не имею, сколько это может стоить, но я был бы рад настроить страницу GoFundMe. Кажется, у нас достаточно «+1», так что несколько долларов от каждого должны покрыть время разработки и сэкономить нам целое состояние на нашем хостинге Zendesk.

+1 для версии 1.10

+1

+1

Есть новости о том, произойдет ли это?

+1
Это так необходимо, я даже могу внести свой вклад в код, чтобы это произошло

Я должен отметить, что мы уже реализовали эту функцию, используя ссылки на билеты, и код был размещен здесь:

http://osticket.com/forum/discussion/89699/osticket-v1-10-merge-duplicate-ticket-mods-attached

Мы включили ссылку на разработчика, который может реализовать это для вас, если вам неудобно делать это самостоятельно.

Кажется, что-то случилось.... #3768
Спасибо, что поделились работой @Micke1101

Я рад видеть, что над этим ведется какая-то работа. +1

@Micke1101Micke1101 Отличная работа с запросом на вытягивание! Надеюсь, он скоро объединится с ядром! +1

3768: Требуется больше внимания.

Что-то новое по этой теме?

Я так понимаю 2020?

Мы также хотим объединять билеты в osTicket 0.12.2! Голосуйте за эту функцию :)
Независимо от того, строится ли он как плагин или в ядре.
Спасибо!

@антиюзер

Официальная функция слияния билетов находится по ссылке ниже. Подпишитесь на эту тему, чтобы быть в курсе:

• https://github.com/osTicket/osTicket/pull/4990

Ваше здоровье.