네, 100% 당신과 함께 해요
이것도 제 꿈입니다. 병합 기능이 좋습니다!
종종 고객이 새 이메일을 시작하고 티켓 번호로 응답하지 않기 때문에...이 답변을 기존 티켓에 "병합"하는 것보다 좋습니다.

응.
문제는 추가할 수 있는 "공개 티켓 링크"가 없다는 것입니다.
따라서 티켓을 닫고 "티켓 번호 참조: #12345"라고 말하면 도움이 됩니다.
직원과 사용자를 티켓에 연결합니다.
병합이 불가능한 경우 한편으로는 도움이 될 수 있고 다른 한편으로는 티켓이 있는 경우 도움이 될 수 있습니다.
다른 것에 따라 일종의 "논리적 방법"을 만들 수 있습니다.

하지만 개발자들이 이에 대해 어떻게 생각하는지 봅시다 ;)

건배!

자동 링크 아이디어가 마음에 듭니다(#12345683 참조).

@greezybacon

이에 대해 다른 스레드를 열어야 합니까?

그래서 이것의 이면에 있는 아이디어는 "그냥" 버튼을 누르고 티켓 번호를 입력할 수 있다는 것입니다(또는 선택하지만 이것은 무겁습니다).
그러면 티켓에 링크가 추가됩니다.

다시 문제는 링크 자체를 추가하는 것이 아니라 직원 또는 사용자만 이를 볼 수 있다는 것입니다.
내가 말했듯이 다음과 같은 문제와 변경 사항은 검색하지 않고 처음부터 끝까지 처리하는 것이 좋습니다.

그러나 예를 들어 지식 기반의 티켓에 대한 링크를 만들 수는 없습니다.

이 기능 요청에 대한 지원을 추가하고 싶습니다. 내 사용자는 티켓 번호를 포함하지 않고 동일한 문제에 대해 여러 이메일을 보내는 데 정말 능숙하며 문제를 해결하는 데 필요한 모든 필요한 정보를 빠르게 파악하지 못합니다.

티켓을 합치는 것은 굉장할 것입니다! 티켓 번호만 입력해도.

https://github.com/osTicket/osTicket-1.8/issues/1068의 속임수?

새 문제를 제출하기 전에 검색하십시오!

일반적으로 인용문은 동일합니다.
하지만 반면에 자동링크는 티켓을 합치는 것과는 별개의 기능이라고 내 설명과 별개다.

그래서 지금 이것을 처리하는 방법을 모릅니다.

제 생각에 "더 쉬운" 첫 번째 단계는 직원 및/또는 사용자가 볼 수 있는 티켓에 링크하는 옵션을 추가하는 것입니다.
따라서 솔루션을 찾거나 무언가를 이해하려고 할 때 일종의 프로세스/역사를 만들 수 있습니다.

그러나 미래에는 새로운/동일한/이중 티켓을 추가할 수 있는 일종의 "메인 티켓"이 있으면 좋을 것입니다.
하나의 티켓을 얻고 모든 다른 솔루션, 사용자가 병합된 티켓 목록에서 방법을 볼 수 있도록 합니다.

이건 내 생각이지만, 내가 보는 것처럼 이것을 이해하고 이해할 수 있는 사람이 있을지 모르겠습니다.

건배

참조/링크는 실제로 작업 중인 @greezybacon 의 원래 제안이며 '이슈'라고 합니다. 유사한 티켓을 함께 그룹화하는 것은 많은 의미가 있지만 병합과는 다릅니다. 병합을 사용하면 모든 티켓 항목을 새 티켓으로 '이동'하기만 하면 됩니다. 연결/그룹화에는 새 테이블이 필요합니다.
예, @Hannibal226에 대해 말하는 것과 거의 동일합니다.

나는 이것을 다음 일/주에 프로그래밍할 것입니다. 그리고 pull request로 플러시합니다.

메시지가 시간순으로 정렬되면 "티켓 병합"이 그렇게 어렵지 않다고 생각합니다. 그리고 대부분의 경우 티켓을 병합하면 "하나의" 메시지만 남게 됩니다. 최종 사용자가 잘못 답변한 새 티켓일 수 있기 때문에/새 이메일을 작성하고 답변 버튼을 사용하지 않았습니다.

내 생각은 다음과 같습니다.

• "다른 티켓에 병합" 버튼이 있습니다.
• 그것을 누르면 팝업이 열리고 이 티켓을 병합할 티켓을 작성/검색합니다.
• 발신자를 협력자로 추가하라는 요청보다 (소유자와 같은 이메일이 아닌 경우)
• 마지막에 "새 티켓"을 닫거나 삭제하라는 요청보다.
  닫으면 다음과 같은 모든 정보가 추가된 메모보다
  보낸 사람(이메일/이름) 시간/날짜 및 종료된 티켓의 티켓 번호
  또는
  보낸 사람(이메일/이름) 시간/날짜

결정적인.
정말 필요한 기능인 것 같아요. 나는 종종 새로운 이메일을 작성하고 응답 버튼을 사용하지 않는 고객이 있습니다. 새 티켓을 수동으로 닫고 "메인 티켓"에 티켓 번호를 추가하는 것보다. 그러나 무슨 일이 일어나는지 이해하기 위해 티켓에서 티켓으로 전환해야 하는 경우에는 그렇게 쿨하지 않습니다.

@mrsaw12 플러그인으로 구현해보시겠습니까?

@Mrsaw12

이것은 gr8처럼 들리고 나는 이것을 테스트하고 싶습니다 ;)
그리고 당신이 말했듯이 그것은 전혀 그렇게 복잡하지 않지만 어쨌든 나는 PHP와 MySQL에별로 관심이 없기 때문에 나 자신을 위해 어렵습니다.

많은 성공을 거두고 완료되면 알려주세요 ;)

건배 친구!

@kordianbruck

암튼 잘 모르겠습니다.
하나의 티켓에서 병합 및/또는 무엇이든 연결해야 한다는 메시지를 받거나 다양한 티켓을 선택하고 그룹화하는 경우 두 가지 방법이 있습니다.

다시 말하지만, 이 기능이 전혀 누락되어 있고 @mrsaw12 와 같은 활동적인 사람이 있어 여기에서 빠르게 도움을 주기 위해 약간의 시간을 할애하게 되어 기쁩니다.

@greezybacon 과 같은 주요 개발자나 r 옆에 있는 모든 사람들이 충분히 더 많은 일을 하고 있다는 것은 확실합니다. 이것은 어떤 압력이나 그런 것을 의미해서는 안 됩니다.

어쨌든 함께 생각하게 해주셔서 감사하고 솔루션으로 두 부분 모두 결과에 만족하여 "예, 동일합니다"라고 말할 수 있습니다. ;)

건배

앞으로 몇 달 안에 티켓에 여러 스레드가 있는 기능을 추가할 예정입니다("작업"을 통해). 그것이 티켓 병합에 도움이 될지 보는 것은 흥미로울 것입니다.

@greezybacon 멋지네요 , 반갑습니다!

안녕! 이 개선 사항에 대한 업데이트가 있는지 궁금합니다. 절실히 필요합니다. 감사!

+1

@greezybacon 반갑고 감사합니다!

또한 이것에 대한 업데이트를 찾고 있습니다. 티켓 병합은 워크플로에 필수적입니다. 감사합니다.

안녕하세요 여러분,

저는 많은 티켓팅 시스템을 사용해 왔으며 모두 동일한 기본 방법론(Ceberus, Zendesk, RT 등)을 통해 병합됩니다.

대부분의 다른 발권 시스템이 제공하는 것과 일치하는 osTicket의 병합을 보고 싶습니다.

1) 에이전트가 모든 보기(검색 결과 목록, 내 티켓 목록, 기타 목록)에서 여러 티켓을 선택하고 병합 버튼을 누르도록 허용합니다.

2) MERGE 버튼을 눌렀을 때

• 모든 데이터는 날짜별로 정렬된 하나의 티켓 스레드로 병합됩니다.
• OLDEST 티켓 번호는 병합된 티켓의 티켓 번호입니다.
• 모든 공동 작업자와 에이전트는 새 티켓에 있습니다.

병합입니다. 모든 것을 가져 와서 ORIGINAL(가장 오래된) 것으로 표현되는 하나의 항목에 넣습니다.

중복을 병합하고 줄이는 것은 티켓팅에서 무분별하고 불필요한 작업을 줄이기 위해 대용량 환경에서 가장 중요한 기능입니다. 그들은 IMHO, 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은 최고의 오픈 소스가 될 것입니다.

와우 많은 사람들이 이것을 따르고 있습니다 :-) 티켓 병합, 훌륭합니다!

간절한 기대를 안고 합체를 기다리고 있습니다!

지금은 코드를 추가 중이므로 Merge가 추가된 기능 중 하나가 될 때까지 1.9.4 이상으로 업데이트되지 않습니다.

티켓 병합을 위한 안정적인 코드가 있다면 메인 브랜치에 추가하지 않겠습니까?
수요가 있는듯...
병합은 우리에게 엄청난 개선이 될 것입니다!

예, 병합 티켓은 사용자가 가득 찼습니다.

Inviato da dispositivo 모바일. | 휴대기기로 전송
Il 13/Mag/2015 07:03, "Eddie-BS" [email protected] ha scritto:

티켓 병합을 위한 안정적인 코드가 있다면 메인에 추가하지 않겠습니까?
나뭇 가지 ?
수요가 있는듯...
병합은 우리에게 엄청난 개선이 될 것입니다!

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

티켓 병합은 사용자가 두 개의 이메일 주소로 티켓을 생성한 경우를 여러 번 겪었고 이를 모두 하나의 계정에 병합하고 현재 한 번에 하나씩 수행해야 하는 경우에 우리에게 큰 이점이 될 것입니다. 변경 소유자를 사용하는 경우(또는 백엔드에서 이를 수행하기 위해 쿼리를 작성해야 하지만 소프트웨어가 일반적으로 처리했을 항목을 놓칠 수 있기 때문에 항상 위험합니다.)

userful은 동일한 사용자 티켓이지만 다른 티켓도 병합하므로 사용자 A가 두 개의 다른 티켓 기능을 만들어 하나로 병합할 수 있습니다.

이것도 +1. 언젠가 OSTicket이 이 기능을 갖게 되길 진심으로 바랍니다.

이 기능에 대해 +1, 이것이 가능하다면 완벽할 것입니다.

+1

Github에 병합 기능이 없었다고 상상해보세요...

+1

티켓을 병합하는 것은 매우 유용한 추가 기능입니다. 1.10rc1에서 진행되는 방식이 마음에 들지만 코드가 너무 많이 변경되어 이전 병합 조정을 구현하기가 쉽지 않습니다. PHP에 대해 더 잘 알고 싶습니다.

+1

+1 매우 필요합니다!

1.10에서 구현된 매우 상세한 국제화 기능이 완료되었으며 이제 남은 다른 기능은 대용량 지원 센터에 필수적인 조용한 티켓 병합입니다. 나는 이것이 osTicket이 다른 솔루션보다 앞서 쏠 수 있도록 1.10 또는 1.11에 대해 약간의 관심을 받기를 바랍니다.

+1

그래, 난 동의

+1

누군가 이 기능을 개발하고 OSTicket과 병합하려면 무엇이 필요할까요?

ntzier가 "병합 위에 더 중요한 특징/기능이 있기 때문에 병합은 특별히 할 일이 아닙니다. 한동안 병합 기능을 기대하지 않을 것입니다."라고 언급했음에도 불구하고. +1의 순전한 양과 열린 티켓의 중복을 기반으로 하면 수요가 꽤 높다고 말할 수 있습니다.

저는 16년 동안 PHP를 작성해 왔습니다. 병합 방법을 작성할 수 있습니다. DB 스키마에 대한 수석 개발자와 병합을 구현하는 가장 좋은 방법에 대한 그들의 생각에 대해 이야기하고 싶습니다. 또는 스키마를 검토하고 구현을 제안할 수 있습니다. 하지만 그 일을 하기 전에 내 작업이 OSTicket Trunk에 포함될 수 있는지 확인하고 싶습니다.

가능성이 있습니까?

:+1: @ooglek 용

@ooglek
나에게 좋고 합리적으로 들립니다. :)

개발자 여러분, 어떻게 생각하십니까?
@protich
@greezybacon
@nfebuary

응!

:+1:

@ooglek
이 이니셔티브를 보여 주셔서 감사합니다!

@greezybacon 도 감사하다고 확신하지만 github에 누군가를 추가하는 것에 대한 규칙이 무엇인지 모르겠습니다.
어쩌면 당신 옆에 병합 기능을 만들 수 있습니까?

그러나 우리는 개발자를 기다리고 봐야 합니다.

다시 한 번 감사합니다.

Re: "하지만 github에 누군가를 추가하는 것에 대한 그들의 규칙이 무엇인지 확실히 모르겠습니다."
누구나 github에 가입하고 pull request를 할 수 있습니다.
개발자는 변경 사항을 검토하고 수락하거나 거부합니다.

@ntzier
OK 죄송합니다. 일반적으로 github가 아닌 'osticket' github 부분을 의미했습니다. 죄송합니다.

그러나 @ooglek 에서는 가능한 것 같습니다 ;)

이것은 확실히 osticket에 추가되었으면 하는 바램입니다. 이 기능은 우리가 사용하고 있는 다른 발권 시스템보다 이를 채택할 때 이를 경영진에게 판매하는 데 확실히 도움이 될 것입니다.

+1

내 자신의 +1을 믹스에 던집니다.

우리는 다른 티켓팅 솔루션에서 마이그레이션할 방법을 찾고 있으며 병합이 필수적입니다. 기존 티켓에 응답해야 하는 새로운 티켓이 많이 생기고 티켓 사용을 정확하게 추적해야 하기 때문에 결국 많이 병합됩니다.

나는 지난 며칠 동안 이것에 대해 생각했습니다. 나는 UI 작업을 할 것이고 @greezybacon 과 이야기를 나누었고 그는 그것에 약간의 에너지를 쏟는 것에 대해서도 언급했습니다. (그의 일정은 약간 미쳤으므로 명심하십시오) @ooglek 어떤 도움도 환영합니다. 당신과 나는 토론할 수 있습니다 UI와 @greezybacon과 백엔드에 대해 논의할 수 있습니다. 나는 우리가 이것을 할 수 있다고 생각한다. 아 그리고 +1

누군가가 병합 프로세스에 대한 보다 공식적인 RFC를 구성하여 병합 프로세스와 관련된 문제를 해결하고 osTicket에서 이를 수행하는 방법에 대한 몇 가지 정의를 만들 수 있습니까? 지금까지 제기된 문제 중 일부는 다음과 같습니다.

• 스레드는 어떻게 병합됩니까? 개별 티켓의 항목은 다음과 같습니다.
  
  
  
  • 연대순으로 얽혀
  
  
  • 접힌 티켓의 스레드가 병합된 티켓의 스레드 끝에 추가됩니다.
  
  
  • 별도의 탭을 통해 UI에 표시되는 별도의 스레드
  
  
  • 스레드 병합이 수행되지 않습니다. 대신 티켓이 닫히고 병합된 티켓에 "관련 티켓" 링크가 추가됩니다.
  
  
• 메타 데이터는 어떻게 병합됩니까? 구체적으로
  
  
  
  • 마감일
  
  
  • 담당자(직원 및 팀) 및 라우팅 부서
  
  
  • 각 티켓에 추가된 사용자 지정 데이터 및 양식
  
  
• 병합하는 과정은 무엇입니까?
  
  
  
  • 티켓 목록 대기열에서 다중 선택 작업
  
  
  • 티켓 보기의 더보기 드롭다운에서 작업
  
  

뭔가를 입력하려고 시도할 수 있지만 이 기능에 대한 강력한 사용 사례가 없기 때문에 다른 사람들이 작업 방식에 대해 더 큰 느낌과 방향을 가질 수 있다고 생각합니다.

지금은 다소 바쁘지만 즉각적인 생각은 다음과 같습니다.

• 스레드의 연대순 병합 또는 추가에 대한 사례별 선택
• 기한, 양수인 등에 대한 항목별 결정
• "더보기" 드롭다운에서 작업

우리의 현재 문제(이메일 전용이 아닌 포털이 있으면 다소 완화될 수 있음)는 사용자가 티켓을 열면 몇 시간 내에 답장을 받지 못한다는 것입니다(영업 시간 외에 티켓을 열거나 우리는 휴가를 보낼 수 있습니다) 그런 다음 우리가 첫 번째를 얻었는지 묻는 다른 문을 엽니다. 우리는 회계를 버리는 회계를 닫거나 병합해야 합니다.

다른 경우는 사람들이 티켓을 열고 별도의 이메일로 추가 정보를 보내는 경우입니다. 다른 제목으로 인해 새 티켓으로 등록됩니다. 이는 포털을 사용하여 잠재적으로 완화될 수도 있지만 이메일 기반 티켓을 허용하는 기능을 유지하고자 합니다.

@greezybacon
먼저 두 가지 옵션을 보는 것이 좋습니다.

1)
티켓 A와 티켓 B에서 티켓 C로 병합(링크 참고)
이 단계를 통해 자동으로 병합에 대한 정보를 사용자에게 보내야 하고
A와 B를 닫습니다.

• 즉, 티켓 C '개방' 아래에서 볼 수 있습니다.
  연결된 옵션으로 이동하여 추가 옵션을 선택합니다.

2)
티켓 A와 티켓 B에서 새로운 티켓 C로 병합됩니다.
위와 같은 기능이지만 티켓 C는 구현으로 새로 생성됩니다.
기존 것.

내 생각에 이것은 티켓 시스템을 깨끗하게 유지하기 위해 중요한 것이 필요합니다.

AFTERWARDS 티켓에서 직접 티켓 A 또는 티켓 B를 전환하는 옵션
C는 좋겠지만 이것은 약간의 시간(테마 등)이 필요하고 그렇지 않다고 생각합니다.
주요 병합 ATM에서 매우 중요합니다.

건배!

티켓을 병합하면 새 티켓이 생성되지 않아야 한다고 생각합니다.

이름은 밝히지 않겠지만 현재 솔루션이 작동하는 방식은 병합하려는 티켓의 ID를 선택한 다음 다른 티켓의 모든 콘텐츠가 "티켓 ID XXX이(가) ID YYY"로 병합되었습니다. 이렇게 하면 새 티켓을 만들지 않고 병합이 수행되었다는 사실이 보존됩니다. 그러나 티켓 사용량을 기준으로 청구하기 때문에 실제로 하나만 있어야 하는 두 개의 티켓이 남아 있습니다.

따라서 무슨 일이 일어났는지 기록하는 것도 중요하지만 깨끗하고 직관적인 방식으로 기록하는 것도 중요합니다.

OTRS가 한 한 가지 방법은 티켓을 "연결"하는 것이었습니다. 예를 들어, 한 티켓은 "마스터"로 간주되고 다른 티켓은 여기에 병합됩니다.

디스플레이에서 모든 서신은 "통합"되고 서신이 연결된 티켓에 관계없이 시간순으로 표시됩니다.

이것은 부모-자식 관계를 허용합니다. 티켓이 관련되어 있지만 여전히 두 개의 별도 티켓으로 티켓을 "연결"할 수도 있습니다.

어린이로 간주된 티켓은 "열림/닫힘/해결됨" 표시 또는 계산에 표시되지 않습니다.

병합하면 새 티켓이 생성되지 않는다는 @greezybacon 의 의견에 동의합니다.

제 생각에는 티켓이 생성되면 DB 구조에서 수정해서는 안 되며 소프트웨어를 사용하여 "병합"해야 합니다. 이렇게 하면 "병합 해제"가 가능하지만, 이전 티켓이 새 서신을 받은 경우에도 "마스터" 티켓에만 새 서신이 추가됩니다. 꼭 필요한 것은 아니지만 부모/마스터에 연결된 어린이 티켓을 "고정"하는 것이 더 깨끗할 것이라고 생각합니다.

첫 번째 방법이 아닙니다. 맞습니다.

그러나 종종 티켓을 정리하는 동안 이 옵션이 필요합니다.
그래서 u는 새로운 업데이트 또는 연결을 인식했습니다.

이제 기존 티켓에 추가할 수 있지만 어떤 티켓에 먼저 새로 생성한 다음 병합할지 모릅니다.

new에 직접 병합하는 옵션이 없는 이유는 무엇입니까?

다시 한 번 저는 첫 번째 방법의 "병합"이 모든 것을 함께 모으는 것을 의미한다는 것을 이해하지만 마지막 옵션에서는 정확히 이것을 수행하기 위한 새 티켓을 생성할 수 있습니다.

추신: 이것에 대한 나의 2센트만 확실합니다 :P

건배

@Hannibal226 -- 새 티켓 생성 -- 고객이 기존 티켓에 어떻게 답장을 보내나요? 어떻게 처리되나요? 최소한 데이터 구조를 동일하게 유지하고 두 티켓 사이에 링크를 생성하면 고객은 두 티켓 중 하나에 응답할 수 있으며 응답 처리 코드는 변경할 필요가 없습니다. 내가 어린이 티켓을 동결로 제안한 것이 아니라 옵션을 버리는 것입니다). 티켓을 뽑을 때 해야 할 일은 다음과 같습니다.

• 이 티켓에 어린이가 있습니까? 그렇다면 해당 티켓에서 모든 응답을 가져와 이 티켓과 병합하여 표시하십시오.
• 이 티켓에 부모가 있습니까? 그렇다면 자식 대신 부모를 리디렉션하고 표시하십시오.
• "개방/종료/해결됨" 티켓 수 및 표시에서 다른 부모/마스터 티켓에 하위로 연결된 티켓을 무시하고 계산하지 마십시오.

수정은 훨씬 더 간단합니다. 들어오는 응답을 처리하기 위한 논리를 변경할 필요가 없기 때문입니다... 많이. 나는 단지 몇 가지를 생각했다.

• 상태 변경: 마스터를 닫으면 자식이 닫히나요? 아니면 자식/자식 상태가 무시됩니까?
• 어린이 티켓에 대한 고객 응답은 마스터 티켓을 다시 열어야 합니다.
• 마스터/자식 간에 상태를 동기화해야 합니까?

기존 시스템의 구조를 가능한 한 유사하게 유지하고 절대적으로 필요한 경우에만 복잡성을 추가하고 데이터를 복사하거나 ID에 대한 업데이트를 실행하지 않는 것이 가장 효과적이며 작동 문제를 줄일 수 있다고 생각합니다.

개인적으로 저는 "연결된" 티켓이라는 아이디어를 좋아하고 병합을 "티켓 그룹"과 같이 생각합니다. 따라서 사용자 Alice, Bob 및 Charlie가 동일한 문제를 보고하면 이러한 티켓이 서로 연결되고 에이전트는 (이메일 "회신" 대 "전체 회신" 기능을 생각하여) 업데이트, 회신 등을 모두 끝낼 수 있습니다. 연결된/병합된 티켓을 통해 사용자(Alice Bob Charlie) 또는 단일 사용자(Bob)에게 전달합니다.

연결된 티켓으로 그렇게 하는 경우 가장 어려운 부분은 UI를 매우 직관적으로 만들어 상담원이 "티켓 그룹"에 대한 업데이트/응답 등을 쉽고 명확하게 이해할 수 있도록 하는 것이라고 생각합니다. 이것) 또는 단일 티켓으로.

최종 사용자의 관점에서 다른 사용자가 동일하게 보고한 정보를 얻는 것이 의미가 있다고 생각합니다. 이제 나 전체 또는 나만(단일 최종 사용자로서) 에이전트의 응답을 받는 것이 중요합니다. 에이전트의 메시지.

티켓 병합은 구현 방법과 티켓 병합 접근 방식에 대한 다양한 사용 사례가 있기 때문에 실현하기가 정말 어렵습니다.

건배,
남자 이름

우리는 "이슈"의 개념을 추가하는 것에 대해 이야기했습니다. 문제는 티켓과 작업 간의 관계와 같습니다. 그러나 티켓은 부모/자식 관계로 문제에 고정됩니다. 내가 자주 사용한 사용 사례는 데이터 센터 중단입니다. IT 그룹은 데이터 센터 중단 "문제"에 근거한 티켓에 대한 여러 알림을 받을 것입니다. 따라서 새 문제가 생성될 수 있고 모든 티켓이 문제와 연관될 수 있습니다. 문제에 대한 응답은 해당 티켓 소유자에게 브로드캐스트됩니다. 문제가 종료되면 모든 어린이 티켓도 종료됩니다.

병합은 완전히 다른 것이라고 생각합니다. 우리는 종종 병합을 대체 작업으로 생각했습니다. 티켓 병합 시 마지막 티켓을 제외한 모든 티켓이 사실상 삭제됩니다. 스레드는 남은 하나의 병합된 티켓에서만 액세스할 수 있습니다. v1.10에서 이메일을 통한 응답은 더 이상 티켓과 연결되지 않습니다. 대신 스레드와 연결됩니다. 따라서 병합 시 티켓이 제거되고 스레드가 병합된 티켓과 어떻게든 연결되면 축소/삭제된 티켓에 대한 응답은 스레드를 통해 병합된 티켓에서 계속됩니다.

@ooglek

그러나 사용자가 티켓 A와 B에 응답할 때 병합된 티켓 C에서 무엇을 얻었습니까?
"부모/자녀" 항목을 사용하면 방금 닫은 링크 티켓이 있는 것보다 더 복잡하다고 생각합니다.

따라서 내 의견으로는 모든 사용자와 공동 작업자가 병합되어야 합니다...

새로운 티켓(우리가 이야기하는 주요 기능이 아님)의 예를 유지하려면 항상 하나의 티켓에서 진행해야 합니다.

따라서 티켓 B에서 ur를 만들고 새 티켓 C를 만듭니다. 즉, 모든 사용자와 공동 작업자가 B에서와 같이 사용됩니다.
그런 다음 티켓 A를 병합해야 합니다. 티켓 A는 C에 이미 존재하지 않는 경우에만 협력자를 포함합니다.

건배

@Chefkeks 사용자 관점에서 티켓을 그룹화하는 데 동의할 수 없습니다. 이는 별도의 고객 티켓에서 잠재적으로 개인 정보를 혼합하는 것과 너무 가깝고 교차 오염이 너무 쉽게 발생할 수 있습니다.

나는 이것이 Issues가 편리한 곳이라고 생각합니다. 워크플로의 예:

세 개의 개별 조직/사용자가 업데이트 프로세스에서 동일한 버그를 보고하고 있으므로 "업데이트 시 오류가 수신됨"과 같은 문제를 만든 다음 해당 티켓을 해당 문제에 연결합니다. 그런 다음 버그를 해결하기 위한 작업을 만들고 해당 작업을 해당 문제에 연결하고 티켓을 연결합니다.

-새 앱에서 잘못된 버튼을 눌러 죄송합니다-

나는 이것에 매우 관심이 있지만 다소 복잡해 보입니다. 내 요구 사항 - (그리고 그것은 내 것일 수도 있음) 훨씬 간단합니다.

고객이 티켓을 생성하면 고객 b(또는 다른 이메일 주소를 사용하는 고객 a)가 이 티켓에 관해 글을 쓰지만 원래 스레드에는 응답하지 않습니다. 이제 메일 내용을 내부 메모로 복사하고 두 번째 이메일 주소를 공동 작업자로 추가합니다.

이것은 작동하지만 문제는 첨부 파일을 복사 및 붙여넣기를 통해 전송할 수 없다는 것입니다.
그래서 나를 위해 기존 티켓에 메시지를 병합하거나 첨부하는 것으로 충분할 것입니다.

@snizzleorg
이것은 당신이 의미하는 바가 더 간단하지 않고 당신이하는 일은 더 수동입니다 :P

그래서 우리는 전체 티켓에 대한 링크를 만들기 위해 이야기하고 있으며, 티켓에서 문자를 받는 것에 대해 이야기하고 있습니다.
최소한 우리 모두는 같은 것을 필요로 하지만 여러 가지 방법이 있으며 이제 가장 편리하고 유용한 방법에 대한 질문이 있습니다.

아니면 하나의 버튼이 수동으로 모두 복사하고 닫는 것이 더 좋지 않다고 말하고 싶습니까? :피
(첨부파일 복사도 가능)

건배

좋아, @greezybacon 이 설명한 "문제"는 "티켓 그룹"에 대해 염두에 두었던 것입니다.

최종 사용자 관점과 별도 티켓의 데이터 보안/개인 정보와 관련하여 약간 틀릴 수 있습니다.
내 아이디어는 모든 티켓 소유자에게 브로드캐스트되는 일반적인 응답에 더 가깝기 때문에 모두 에이전트로부터 정보를 얻고 티켓 소유자가 속한 조직에 따라 다른 사용자가 보고한 내용도 알 수 있습니다. 따라서 최종 사용자를 위해 티켓을 개별적으로 유지하지만 상담원은 동일한 문제가 있는 티켓을 더 쉽게 처리할 수 있습니다.

즉, Jared가 "문제"에 대해 쓴 것과 티켓을 완전히 다른 것으로 병합하는 것에 대해 어떻게 생각하는지 읽으십시오. 저는 "문제"의 "팬"이고 그것이 좀 더 나은 방법일 수 있음을 인정해야 합니다. 병합 또는 티켓 처리/관리를 말합니다.

남자 이름

@chefkeks

그러나 직원을 위한 티켓/방송을 하나 갖고 있지만 사용자를 위한 별도의 티켓/방송을 갖는 것이 (코딩에서) 혼란스럽고 복잡해진다고 생각하지 않습니까?

그러면 사용자의 기존 티켓을 교체하는 것이 훨씬 쉽습니다.
따라서 "이전" 티켓이 닫히고 새 티켓에 동일한 사용자/협력자가 있을 때 이것은 자동으로 발생해야 합니다.

사용자는 이제 두 번째 티켓(이론적으로는 약간 xD)의 내용이기 때문에 이 경우 일부일 수도 있는 일이 일어나고 있음을 알 수 있습니다.

건배

둘 다 필요합니다. 통합 또는 "병합"되어야 하는 단일 사용자의 여러 요청을 처리해야 합니다. 공통 "문제"를 통해 관련된 여러 다른 요청을 통합하기 위한 별도의 필요가 있습니다. 문제 그룹화는 사용자에게 서로의 티켓에 대한 액세스 권한을 부여하는 것을 의미하지 않습니다. 그러나 "현재 데이터 센터 문제에 대해 알고 있습니다..."와 같은 문제가 클라이언트 포털에 게시될 수 있는 "공개 티켓"의 개념을 의미합니다.

둘은 별개의 기능이 되어야 합니다. 그것들은 결합되어서는 안됩니다.

나는 그것에 전적으로 동의합니다!

둘은 별개의 기능이 되어야 합니다. 그것들은 결합되어서는 안됩니다.

그래서 Jared를 염두에 두고 마지막 게시물을 염두에 두고 여기 github에 2개의 RFC 문제가 있어야 서로 독립적으로 논의할 수 있지만 서로 참조하여 사람들이 티켓 병합 또는 문제/티켓 그룹에 대해서만 논의하고 있습니다. .

건배
남자 이름

추신: osTicket 팀은 코딩 및 UI 디자인에 경험이 많기 때문에 상담원이나 최종 사용자 모두에게 너무 혼란스러울 수 있다는 점에 대해 걱정하지 않습니다.

@greezybacon

그러나 왜 그렇게 "복잡"합니까?

사용자는 허용된 티켓에만 액세스할 수 있습니다.
따라서 사용자가 공동 작업자가 아닌 경우 다른 티켓의 티켓에 액세스할 수 없기 때문에 원하는 것을 끝내지 않는 이유는 무엇입니까?
특권이 잘 작동한다면 그것을 분리할 필요가 없다고 생각합니다.

U는 "문제" - "프로젝트" 또는 "작업" 또는 "그룹"의 이름을 지정할 수도 있지만 x라는 사람은 작성자 또는 공동 작업자인 경우에만 기본(병합) 티켓과 내부 티켓에 액세스할 수 있습니다.

이 경우에는 조금 작게 생각할 수도 있지만, 새로운 케이스가 들어오고 그 사이에 케이스 요청이 있을 수 있기 때문에 분리를 시작하면 이것이 커질지 잘 모르겠습니다.

추신: 나는 단지 사용자와 거의 구현에 대해 생각하고 있습니다. 너무 쉽게 들리고 확실하지 않다면 죄송합니다 xD xD

건배

"이슈"는 OST 사용자가 이해하고 관리할 수 있는 완전히 새로운 패러다임을 의미합니다. @snizzleorg 가 말했듯이 고객 A가 이메일을 보내고 고객 B가 이메일을 보낼 때(또는 고객 A가 다른 주소에서 이메일을 보낼 때) 이것이 제 병합 사례의 90%입니다.

잠시 동안 하나의 티켓이 있고 문제에 대해 사람 A와 통신할 수 있고 그런 다음 동일한 문제에 대해 공급업체 B와 통신할 수 있는 것이 좋았습니다. 그러나 OTRS에서 사람 A는 제외하지만 모두 여전히 동일한 티켓에 있습니다. 하지만 난 그럴 필요가 없어요, 그냥 좋았어요.

저는 개인적으로 "이슈"가 생성된다는 아이디어를 정말 싫어합니다. 티켓에 누가 있든 상관없이 이 두 티켓은 실제로 동일한 문제에 관한 것이라고 시스템에 말했기 때문입니다.

@tmcnag가 언급했듯이 "교차 오염"은 도구가 아니라 사용자가 결정해야 하는 문제라고 생각합니다. 어떤 경우에는 당신의 의견으로는 "교차 오염"을 원할 수 있지만 내 생각에는 도구입니다.

고객이 한 번 이메일을 보낸 다음 5분 후에 다시 이메일을 보내 "죄송합니다"라고 말했지만 티켓 A에 회신하지 않은 티켓 A와 티켓 B가 왜 "문제"가 되어야 합니까? 고객이 하나의 티켓으로 만드는 과정을 거치지 못한 단 하나의 티켓. 두 개(또는 세 개 또는 네 개의) 티켓을 확인하고 "병합"하고(잘못된 티켓을 잘못 병합할 경우에 대비하여 IMO 링크) 모든 것을 관리할 수 있는 단일 통합 응답 및 대화 타임라인을 갖고 싶습니다. 고객이 올바른 이메일에 답장하여 "올바른 일"을 하지 않았더라도 _I_ 의도한 대로 하나의 티켓으로.

"Issues"를 추가하면 이 모든 것이 더 복잡해진다고 생각합니다. 사례의 90%는 동일한 문제에 대해 두 번 이메일을 받는 고객이고 동일한 티켓에서 고객을 원합니다.

@greezybacon 에 동의 -- 문제는 유용한 개념입니다. 티켓 병합은 유용한 기능입니다. 그것들은 별도로 개발되어야 하며 함께 선택되어서는 안 됩니다.

나는 일종의 메가 티켓과 같은 새로운 유형의 티켓(발행)에 대한 아이디어를 좋아합니다. 여러 티켓을 단일 문제로 결합하는 데 사용할 수 있습니다. 많은 사람들에게 영향을 미치는 큰 일이 발생했을 때 직원이 열 수도 있습니다. 개인적으로 나는 내 라이브 사이트에서 이것을 거의 사용하지 않을 것입니다. 그러나 예정된 유지 관리, 대규모 네트워크 중단 등과 같은 작업에 사용할 수 있습니다.

즉, 병합 기능을 더 자주 사용할 것입니다. 우리가 지금 수동으로 하는 것과 같기를 바랍니다. 이것은 중복 티켓을 닫는 이 문제(참조 티켓 번호)에 대해 이미 열린 티켓이 있다는 하나의 티켓(나중에 생성된 티켓)을 업데이트하는 것입니다. 그런 다음 원본 티켓을 추가 정보로 업데이트하고 두 번째 티켓을 공동 작업자로 추가합니다.

@ooglek 문제가 있고 병합하는 것은 다른 문제입니다. 합병은 문제 개념인 동안 우리 회사에 가장 유용할 것입니다. 필요한지 확실하지 않습니다. 멋지긴 한데...

아직 혼란이 있는 것 같아요.

티켓, 소유자, 스레드 및 데이터 병합은 다음과 같습니다.

• "오염"의 원인
• 동일한 데이터 및 통신 스레드에서 동일한 개인 또는 그룹의 동일한 문제를 유지하는 데 도움이 됩니다.
• (아마도) 다른 티켓에 병합될 때 티켓을 제거합니다.

문제를 통해 티켓 연결

• (모든) 물건을 따로 보관하다
• "관련" 문제에 대해 별도의 통신, 데이터, 소유자, 공동 작업자 허용
• 티켓 보기에 "관련" 티켓을 추가합니다.
• "문제"라는 항목의 새 목록을 시스템에 추가합니다.
• 대량 통신 및 폐쇄를 허용합니다.

@greezybacon 좋은 요약. 기본적으로 두 가지 새로운 기능

@snizzleorg 저는 이것이 두 가지 기능이 작동하는 방식이라고 제안합니다. 나는 두 가지 별개의 기능에 대해 별개의 목적을 제안함으로써 약간의 혼란을 제거하기를 희망합니다. 제 희망은 모든 사람이 같은 페이지에 모여서 RFC 및 기능 구현을 계속 진행할 수 있도록 하는 것입니다.

멋진. 말했듯이 나는 병합에 더 관심이 있으며 최소한 이 기능이 멋지게 배치되어 있다고 생각합니다. 문제는 두 개의 초기 티켓이 다르고 티켓 데이터 자체에서 충돌을 해결하는 경우 소유자 결과 티켓을 선택하는 방법으로 남아 있습니다.

나는 제안한다:

1 + 병합 2 = 티켓 1의 데이터/소유자

2 + 병합 1 = 티켓 2의 데이터/소유자

사용자(에이전트)에게 병합된 티켓에 어떤 데이터가 포함될지 선택권을 주기 위해 투표합니다.

따라서 사용자에게 병합된 티켓의 데이터에 대한 사전 정의/제안을 제공할 수 있습니다.
A) 병합을 수락하고 진행하거나
B) 병합 방향을 완전히 변경(따라서 2 + 병합 1 = 티켓 2 대신 티켓 1의 데이터/소유자) 또는
C) 티켓 병합 전에 단일 필드(예: 도움말 항목) 편집

@greezybacon 티켓 병합에 대해 병합이 사용자에게 미치는 영향과 백엔드에서 병합의 실제 수단에 대해 약간의 혼동이 있다고 생각합니다.

• 오염 -- 두 티켓이 데이터베이스에 별도로 보관되어 있으면 오염이 없습니다. "병합" 작업 시 두 티켓 사이의 "링크"와 관계 유형이 생성됩니다(티켓 3은 티켓 4의 자식, 티켓 4는 티켓 3의 부모). 소프트웨어는 연결된 티켓 상태를 동기화 상태로 유지합니다. 상위 티켓 상태가 변경되면 모든 하위 티켓 상태가 변경됩니다. 어린이 티켓이 이메일 통신을 수신하면 해당 티켓 통신이 업데이트되고 어린이의 모든 상태 변경 사항은 연결된 모든 티켓에 동기화됩니다. 티켓 4는 티켓 3에서 업데이트된 통신을 표시합니다. 이 경우에는 오염이 없을 것이며 영향이 거의 또는 전혀 없이 항상 두 티켓의 연결을 해제(병합 해제)할 수 있습니다(내가 생각할 수 있는 유일한 영향은 협력자를 추가한 경우뿐입니다) 병합할 때 하위 티켓에서 상위 티켓으로 변환할 수 있으며 병합을 취소할 때 실행 취소하고 싶지 않을 것입니다.
• 공동 작업자 유지 -- 병합의 90%는 같은 사람, 즉 같은 사람이 관리하는 동일한 전자 메일 또는 두 개의 다른 전자 메일에서 수행될 것이라고 생각합니다. 그 10%의 우려는 무엇을 할 것인지(자식 티켓에서 마스터 티켓에 자동으로 공동 작업자 추가) 사용자가 알도록 하는 것입니다. 그것이 그들이 원하는 것이 아니라면, 그것을 취소하는 것입니다. 또는 기본적으로 "상위/마스터의 공동 작업자에 티켓 소유자 병합"이 선택되어 있는 확인란을 추가하고 선택을 취소하면 공동 작업자가 상위에서 수정되지 않습니다.
• 티켓 제거 -- NO! 하지마 그 나쁜.

문제는 아직 (내가 아는 한) 설계되지 않고 지정되지 않았으며 무정형인 새로운 기능입니다. Issues를 사용하여 티켓을 병합할 수 있습니까? 완전히! 그러나 티켓을 병합하는 것이 문제 기능의 진정한 의도입니까? 아니면 병합이 더 쉬워 보이기 때문에 병합을 활성화하기 위해 문제를 복잡하게 만들고 있습니까?

문제가 여러 고객이 겪고 있는 일반적인 문제인 경우 OST의 사용자/관리자가 목록에서 "병합 티켓" 문제를 보고 싶어합니까? 많은 OST 사용자의 경우 문제가 필요하지 않을 수 있으며 티켓을 병합하여 문제가 "생성"된다면 혼란스러울 것입니다. 문제가되면 티켓의 컨텍스트를 잃게됩니다. 이제 "통합 티켓"을 일반 티켓과 다르게 처리하고 OST에서 완전히 다른 영역으로 전환하여 병합 티켓을 관리해야합니다. 그러면 규칙을 벗어납니다. 일반 티켓의 OST 에스컬레이션 및 운영.

문제를 사용하여 병합 티켓을 구현하는 것은 기존 티켓 프레임워크 내에서 티켓 병합 을 비파괴적으로 구현하는 방법을 찾는 것보다 OST 개발 및 OST 사용자 모두에게 훨씬 더 많은 문제와 도전을 야기할 것이라고 강력하게 생각합니다. 오늘날 존재하며, DB에 한두 개의 테이블이 추가되고 연결된 티켓에 대한 작업을 처리하기 위한 일부 코드 및 트리거가 있습니다.

@nizzleorg @greezybacon의 의견을 오해하신 것 같습니다. 그는 "두 가지 다른 기능"을 말하는 것이 아니라 "문제가 모든 것을 깔끔하게 해결합니다."라고 말한 것입니다. 위에 동의하지 않습니다.

@ooglek 이슈(링크된 티켓)와 병합의 개념을 결합하고 있습니다. 어떻게 두 가지를 병합하고 연결된 두 가지로 끝날 수 있습니까? 병합의 개념은 여러 항목을 하나로 축소하는 것을 의미합니다. 따라서 병합된 항목을 제거합니다.

@grezybacon @ooglek

이에 대한 내 의견은 데이터베이스 보기에서 ooglek이 옳고 티켓이 그냥 삭제되어서는 안 된다는 것입니다.
사용/인터페이스 사이트에서 greezy가 정확하고 오래된 것을 숨기거나 교체해야 합니다. 그렇지 않으면 병합이 무의미합니다.

그러나 다시, 왜 그렇게 복잡합니까?
티켓이 병합과 함께 종료되는 이유는 무엇입니까(특정 병합 상태일 수 있음)?

즉, 기본 티켓/발행을 통해 티켓에 계속 접근할 수 있거나 더 잘 볼 수 있지만 더 이상 변경할 수는 없습니다.
또는 일종의 스냅샷이 구현되어 이를 토글할 수 있습니다. (그러나 이것은 나중에 디자인입니다)

그리고 그것이 병합과 발행이 분리될 수 있는 지점(내 의견)이므로 병합에서 티켓이 닫히고 발행에서 '공개' 티켓의 목록입니다.

건배

@greezybacon 병합은 백엔드 개념이 아닌 UI 개념입니다. 사용자의 관점에서 티켓은 병합된 것처럼 보입니다. 한 번 병합 작업을 수행하면 마스터 티켓이 보기에 시간 순서대로 모든 통신 내용이 있고 회신은 병합된(또는 병합 시 제외된) 모든 당사자에게 가기 때문입니다. ). 따라서 사용자는 병합된 티켓을 보게 됩니다.

백엔드에서는 가능한 한 깨끗하고 실행 취소할 수 있도록 하려고 합니다. 2개 이상의 티켓 간에 관계를 생성하여 다음을 수행할 수 있습니다.

• 해당 티켓이 아직 존재하기 때문에 이메일을 통해 어린이 티켓에 대한 회신을 수락합니다. 더 이상 존재하지 않는 티켓으로 수신 이메일을 처리하기 위해 추가 코드 또는 DB 구조가 필요하지 않습니다.
• 병합 해제 - 응답은 각각의 티켓에 고정됩니다. 유일하게 남아 있는 문제는 병합된 공동 작업자입니다. 이는 병합 해제에서도 잠재적으로 처리될 수 있습니다.
• 기록 -- 티켓 기록은 여전히 ​​존재하며 직접 볼 수 있으며 새로운 소프트웨어 변경 사항은 없습니다.
• Open/Resolved/Closed 보기 -- 하위 티켓은 사용자의 관점에서 병합되기 때문에 하위 티켓은 이 보기에 나열되지 않습니다.

이 비파괴적인 방식으로 병합을 구현하기 위해 세 가지 주요 변경 사항과 한 가지 사소한 기능/기능이 추가되었습니다.

• 관계 테이블. 관계 유형이 있는 다른 티켓에 티켓을 연결합니다.
• 티켓의 Open/Resolved/Closed 보기를 수정합니다. 어린이 티켓은 제외하십시오.
• 보기 티켓을 수정합니다. 실시간으로 부모 및 어린이 티켓의 서신 병합 -- 예를 들어 (ticketA, ticketB)의 티켓이 수신 날짜 내림차순인 서신에서 *를 선택하십시오. 그리고 아동 티켓을 볼 때 아동으로 표시되어 있고 읽기 전용이며 이에 응답할 수 없음을 분명히 하십시오. 마스터 티켓에 대한 링크를 추가합니다.
• 새 코드: 병합은 관계를 추가하고 마스터 티켓에서 고객과 공동 작업자를 공동 작업자로 복사합니다(선택 사항인 확인란, 또는 모든 고객 및 공동 작업자 정보가 포함된 다중 선택 상자).

이것은 병합을 크게 단순화하고, "병합" 티켓을 처리하기 위해 많은 양의 코드를 수정할 수 없도록 하고, 티켓이 "병합" 또는 "병합 해제"된 시기를 조사할 수 있도록 기록의 흔적을 남기고, 거의 완전히 비파괴적입니다. (협업자의 마스터 티켓 수정은 파괴적인 것으로 해석될 수 있습니다. 저는 그렇게 생각하지 않지만 그 관점을 할인하고 싶지는 않습니다.)

@ Hannibal226 과 나는 대부분의 요점에 동의하는 것 같습니다. 나는 병합된 자식 티켓을 닫아야 한다고 생각하지 않습니다 -- 마스터 상태가 변경되면 자식 상태가 변경되고 그 반대도 마찬가지라고 생각합니다.

예를 들어 마스터 티켓이 "해결됨"이고 어린이 티켓이 있는 고객이 이메일을 통해 회신하는 경우 어린이 티켓은 "열림"으로 돌아가야 하므로 마스터 티켓과 다른 모든 어린이 티켓도 "열기"로 돌아가야 합니다.

모든 하위 티켓을 "병합"으로 닫으면 새 수신 이메일을 처리하는 논리를 더 많이 수정해야 합니다. 티켓이 "병합?" 상태입니다. 여전히 원래 아동 티켓에 서신을 추가합니까? 아니면 이제 마스터를 수정합니까(머지 어젯밤 실수로 인해 큰 혼란을 초래할 수 있다고 생각합니다. 고객이 세 번 다른 응답을 한 다음, 병합을 해제하러 갔습니다. 이제 고객 A 서신) 고객 B의 티켓에 있습니다.

@ooglek

따라서 우편물이 티켓 A로 들어가는 한 티켓 A, B 및 "마스터" C를 열고 싶습니다.

그러나 코드를 모른 채 나는 메일이 C에서 병합된 A로 들어올 때 적어도 어렵거나 쉽다고 말할 것입니다.
즉, C만 온라인으로 변경됩니다.
따라서 여기서는 하나의 루틴만 필요합니다(플래그 또는 관계 테이블 [언급되지 않음]).

병합의 감각은 청소입니다. 따라서 병합될 때 티켓을 열어 두므로 병합된 티켓을 여는 것은 불필요합니다. (내 생각에는)
따라서 티켓 A와 B는 병합되는 즉시 보이지 않거나 교체되어(모든 사용자 및 공동 작업자에 대해) 닫힐 수 있습니다(마침/잊어버리기).
대부분의 경우 다시는 필요하지 않은데 상태를 계속 변경하는 이유는 무엇입니까?
몇 가지 경우에만 무언가를 확인하고 싶을 수 있으므로 링크를 통해 이동할 수 있고 마지막 옵션에서 병합 해제할 수 있습니다.

그래서 나는 우리의 동의를 봅니다:

• 티켓 종료 없음
• 문제는 병합이 아니지만 병합이 문제를 처리할 수 있습니다(최소한 그렇게 이해합니다).
• 병합/병합 해제 기능
• 대부분의 UI만 더 적은 DB로 병합

그러나 우리의 실제 다른 견해는 다음과 같습니다.

• 자식 - 마스터 (내 생각에는 UI보다 DB가 더 많기 때문에)
• "마스터"뿐만 아니라 모든 티켓에 대해 상태가 변경됨

건배!

@한니발226

내 시나리오는 다음과 같이 작동합니다.

• 고객 A가 이메일을 보내고 티켓 A를 생성합니다.
• 고객 A 이메일, 동일한 이메일 주소가 티켓 B 생성
• 고객 A 이메일, 다른 이메일 주소, 티켓 C 생성

OST 사용자/에이전트는 티켓 A를 "마스터"로 사용하고 티켓 B와 티켓 C를 티켓 A에 병합하기로 결정합니다.

• OST 연결된 관계를 생성하고 티켓 B는 티켓 A의 자식입니다.
• OST 연결된 관계를 생성하고 티켓 C는 티켓 A의 자식입니다.
• 이 세 티켓에 두 개의 다른 이메일이 있기 때문에 OST 사용자/에이전트는 마스터가 아닌 다른 사용자를 공동 작업자로 병합하기로 결정합니다. 고객 A 이메일 B가 티켓 A의 협력자가 됩니다.

이제 끝났습니다.

고객 A가 티켓 C에 이메일을 보내면 해당 서신이 지금과 같이 티켓 C에 추가됩니다. 해당 통신이 상태 변경(Resolved -> Open)을 트리거하면 현재와 같이 티켓 C의 상태가 변경되지만 티켓 A와 티켓 B 상태도 일치하도록 변경됩니다.

고객 A가 티켓 B에 이메일을 보내도 같은 일이 발생합니다.

고객 A가 티켓 A에 이메일을 보내도 같은 일이 발생합니다.

OST 사용자/에이전트가 티켓 A(병합된 마스터 티켓)를 로드하면 티켓 A, B, C의 모든 서신이 인라인으로 표시됩니다. 티켓 보기에서 병합된 티켓의 출처를 표시하거나 표시하지 않을 수 있습니다.

OST 사용자/에이전트가 티켓 B 또는 C를 로드하면 이것이 마스터 티켓에 대한 URL 링크가 포함된 링크된 하위 티켓이며 여기에 있는 모든 것이 읽기 전용이며 응답은 마스터 내에서 이루어져야 한다는 알림이 표시됩니다. 티켓.

나는 당신이 두 번째 단락에서 무엇을 의미하는지 잘 모르겠습니다. 당신은 다시 말할 수 있습니까?

단락 3: 나는 여전히 아동 티켓(당신의 메모에서 티켓 A와 티켓 B)이 폐쇄되어야 한다는 것에 동의하지 않습니다. 고객이 해당 아동 티켓에 응답하면 어떻게 됩니까? 이제 새 상태(Closed Merged) 또는 상태 플러스 관계 상태(Closed + Child)에 있는 티켓을 처리하는 방법을 수정한 다음 마스터의 상태를 변경하는 논리를 추가해야 합니다. 그리고 상태가 닫힘이면 해당 티켓이 아니라 마스터에 서신을 추가해야 합니다. 하지만 그렇게 하면 이제 티켓 A(자식)로 향하는 통신이 DB에 티켓 C(마스터)로 기록되기 때문에 병합 해제 기능을 잃습니다. 병합을 해제하면 해당 통신을 어떻게 티켓 C(마스터)는 티켓 A(어린이)를 위해 티켓 A로 다시?

나는 고객들이 오랫동안 티켓을 끊었다고 생각합니다. 저는 지난 2년 동안 열린 티켓에 대해 고객이 이메일로 답장을 보낸 적이 있습니다. 그리고 그 티켓이 제대로 처리되었는지 확인하고 싶습니다.

나는 여기서 우리의 합의를 다음과 같이 본다.

• 티켓 종료 없음
• 병합 및 병합 해제 기능 제공
• 병합은 대부분 UI 변경, 최소한의 DB 변경 및 코드 및 프로세스 변경 최소화입니다.

그리고 우리는 다음에 대해 동의하지 않습니다.

• 자식-마스터 관계를 구현하는 방법
  ** 나: 그냥 관계 테이블
  ** 너: ??
• 문제
  ** 나: 문제는 이 스레드에서 언급된 별도의 기능이지만 IMO는 병합 기능 구현과 관련이 없습니다.
  ** 너: ??
• 마스터 및 아동 티켓 현황
  ** 나: 마스터 및 하위 티켓 상태가 동기화되어 있어야 고객이 모든 티켓에 응답할 수 있고 해당 통신이 고객이 의도한 티켓으로 이동하여 병합 해제 중에 일관성이 있고 혼합되지 않도록 해야 한다고 생각합니다. 의도하지 않은 답변
  ** 너: ??

우리가 어디에서 다른지에 대한 여러분의 생각을 공유하기를 기대합니다.

OST 개발자 그룹이 있습니까? 어떤 종류의 프로세스?

@ooglek

• 자식-마스터 관계 구현 방법 ** 나: 그냥 관계 테이블 ** 당신: ??
• 마스터 및 차일드 티켓 상태 ** 나: 마스터 및 차일드 티켓 상태가 동기화 상태를 유지해야 고객이 모든 티켓에 응답할 수 있고 해당 통신이 고객이 의도한 티켓으로 이동하므로 병합 해제 중에 일관성이 있고 의도하지 않은 응답이 섞이지 않습니다 ** 당신: ??
  
  
  
  • 우선 "마스터-자식" 관계와 관계 테이블을 함께 살펴봅니다.
  
  
  • 따라서 여기에 동의하지만 여러 티켓을 통해 상태를 관리하는 것은 아닙니다.
    
    다시 열기 상태 변경은 "마스터"(예: A)에만 영향을 미쳐야 합니다. 제 생각에는.
  
  
  • 모든 통신은 병합되는 한 마스터로 "리디렉션"되어야 합니다. 나중에 티켓 B 또는 C에 무언가를 추가하고 싶을 때 병합을 사용해야 하는 이유는 무엇입니까? [그러므로 병합 해제]
  
  
• 문제 ** 나: 문제는 이 스레드에서 언급된 별도의 기능이지만 IMO는 병합 기능 구현과 관련이 없습니다. ** 귀하: ??
  
  
  
  • 문제: 맞습니다. 다른 시간에 이에 대해 논의할 수 있습니다.:P
    
    나는 다른 상태 처리(마스터와 별개)와 새로운 티켓 생성만이 문제 기능을 가져올 수 있다고 생각합니다. 여기에서 완전히 "재설계/구현"하지 않아도 됩니다.
  
  

이 '기능 요청'에 대한 관심과 움직임에 기쁘게 생각합니다 ;)

건배!

@한니발226

• 관계 -- 동의
• 티켓 상태 -- 내가 마스터 및 차일드와 상태를 동기화하도록 제안하는 이유는 이메일이 차일드를 대상으로 하는 경우 때문입니다.
  
  
  
  • 어린이 티켓을 "닫으면" 이 새 이메일로 무엇을 합니까? 마스터의 서신에 추가하면 깔끔하게 "병합 해제"할 수 없습니다. 안전한 병합 해제를 허용하기 위해 이를 Child의 통신에 추가하면 이제 Child를 "열림"으로 만들었던 기존 상태 변경 코드를 실행 취소해야 하지만 이제는 이를 억제하고 마스터만 "열기"로 변경해야 합니다. ". 그것은 몇 가지 근본적인 변화입니다.
  
  
  • 하위/마스터를 동기화 상태로 유지하면 새 이메일이 하위 티켓으로 이동하고 하위 상태가 업데이트되며 해당(기존 코드를 수정하지 않는 추가 코드)은 다른 하위 및 마스터 티켓의 상태 업데이트를 트리거합니다. 새로운 이메일 처리 코드의 논리 변경이 아니라 추가된 코드의 한 부분입니다.
  
  
  • 논리를 그대로 유지하고 앞서 언급한 관계 테이블의 일부인 티켓에 대해 한 단계만 추가하면 후자가 더 깔끔하다고 생각합니다.
  
  
• 문제 -- 동의합니다! :-)

@greezybacon 당신의 생각을 듣고 싶습니다. 그리고 이것이 내가 포크, 수정 및 풀 요청을 제출하기를 원하는 것 중 하나입니까? 아니면 구현하시겠습니까?

@ooglek

• 티켓 상태
  
  
  
  • 터치. 병합 해제 옵션을 잊어버렸습니다. 메일이 병합되는 동안 메일이 직접 해당 항목으로 들어가는 경우 훨씬 더 쉽고 구조화됩니다.
  
  

우리가 여기에서 모이는 것을 보니 반갑습니다 :P

건배 ;)

병합 UI는 여기에서 접을 수 있는 스레드 기능과 함께 사용할 수 있습니다. #2699

티켓에 병합된 티켓이 있는지 여부를 나타내는 아이콘이 티켓 목록에 있어야 한다고 생각합니다. 그러면 상담원은 티켓 목록이나 실제 티켓 보기에서 병합 해제할 수 있는지 알게 됩니다.

병합의 시스템 이벤트와 티켓 보기에서 발생한 시간이 있어야 합니다. 병합되는 티켓에는 스레드 내에서 병합된 티켓임을 나타내는 별도의 색상 표시기가 있어야 합니다. 메시지 및 메모의 색상과 같습니다.

응답 대화 상자의 맨 아래에는 병합된 모든 티켓의 이메일 주소가 나열될 수 있으며 상담원은 응답할 때 수동으로 제거할 수 있습니다. 또는 보내기 버튼의 드롭다운을 사용하여 "전체 회신" 또는 "부모 티켓 회신"을 선택하십시오. 전체 회신은 수동으로 제거하는 옵션으로 발신자 주소를 자동으로 채울 수 있습니다. 나는 여기서 큰 소리로 생각하고 있습니다.

티켓을 확인하고 병합을 선택한 후 실제 병합에서 어떤 티켓이 상위 티켓인지에 대한 옵션이 있는 모달이 선택되었습니다. 답장을 보낼 이메일 주소는 무엇입니까? 병합이 수행된 후 티켓을 닫거나, 청구하거나, 양도하는 옵션을 사용할 수 있어야 합니다. 병합을 추가하거나 날짜별로 병합을 섞는 옵션이 있습니까? 다른 것은 나중에 생각하겠습니다. 이것은 순전히 UI라고 생각하고 여러분이 백엔드에 대해 논의할 수 있도록 하고 계속 노력하겠습니다. :웃다:

+1

+1

안녕하세요,

이 원하는 기능에 대한 소식이 있습니까?

+1

+1

내 버전(v1.9.12)에 대해 이미 수행했습니다. 아래와 같은 기능:

• 사용자(게스트) Foo는 이메일 [email protected] 을 사용하여 시스템에 보내 티켓 X-1234를 생성합니다.
• 사용자 Foo는 티켓 X-1234에 사용한 이메일을 잊어버리고 [email protected] 이메일을 사용하여 시스템으로 보냅니다. 이제 이메일 제목이 새 것이고 티켓 번호가 없습니다. 시스템 생성 티켓 X-2345.
• 직원(에이전트)이 티켓 X-1234를 열고 티켓 병합을 선택합니다. 티켓 X-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

+1

MSP에서 일하면서 각 티켓에 대해 개별적으로 작업해야 하므로 이것이 생산성을 얼마나 저해하는지 이해합니다. 큰 도움이 될 것입니다!!!

+1

+1

+1

티켓 시스템을 사내(Zendesk에서 멀리)로 옮기고 싶습니다. 티켓을 병합/분할하는 기능은 결정의 핵심 요소입니다. 다양한 출처(판매, 리셀러, 공급업체, 배송업체, 자동화 시스템, 고객 응답 등)에서 20개 이상의 티켓이 도착하는 것은 드문 일이 아닙니다. 이 모든 것을 수동으로 병합한다는 아이디어는 악몽에 불과합니다.

우리는 프로세스가 원활하게 진행될 수 있도록 재정적으로 몇 달러를 기꺼이 투입할 것입니다. 비용이 얼마인지는 모르겠지만 GoFundMe 페이지를 설정하게 되어 기쁩니다. 여기에서 "+1"이 충분히 있어 모든 사람의 몇 달러가 개발 시간을 지원하고 Zendesk 호스팅에 대한 막대한 비용을 절약할 수 있을 것입니다.

버전 1.10의 경우 +1

+1

+1

이런 일이 일어날 것인지에 대한 소식이 있습니까?

+1
이것은 너무 필요합니다. 나는 이것을 가능하게 하는 코드로 기여할 수 있습니다.

티켓 링크를 사용하여 이 기능을 이미 구현했으며 코드가 여기에 온라인으로 게시되었습니다.

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

혼자서 하는 것이 불편할 경우 구현할 수 있는 개발자 링크를 포함했습니다.

무슨일이라도 생긴듯.... #3768
작업을 공유해 주셔서 감사합니다 @Micke1101

이에 대한 작업이 진행되고 있어 기쁩니다. +1

@Micke1101 풀 리퀘스트 수고하셨습니다! 곧 코어에 병합되기를 바랍니다! +1

3768 더 많은 가시성이 필요합니다.

이 주제에 대해 새로운 것이 있습니까?

그래서 2020년인가?

osTicket 0.12.2에서도 통합 티켓을 원합니다! 이 기능에 투표하세요 :)
플러그인으로 빌드하든 코어에서 빌드하든 상관없습니다.
감사합니다!

@안티유저

공식 티켓 병합 기능은 아래 링크에 있습니다. 최신 상태를 유지하려면 해당 스레드를 따르세요.

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

건배.