Osticket: v1.9.12 버그: 공동 작업자가 티켓 위협에 처음 입장할 때 이메일 알림을 보내지 않음

이전에 #1130으로 보고된 관련 문제를 찾았지만 현재로서는 아직 구현되지 않았습니다.

이거 하려면 어디서 수정해야 하나요?

여전히, 어쨌든, 1.10 브랜드에 존재한다면 여전히 1.10은 안정적이지 않으며 조직에서 프로덕션에 사용하도록 제안할 수 없습니다...

거의 1년 동안 에이전트가 적어도 whow csn i가 신과 외계인에 대한 사랑을 위해 1.9 브랜드를 위해 만든

@mckaygerhard 공동 작업자가 티켓을 만드는 데 사용된 이메일에 이미 포함되어 있기 때문에 초기 이메일을 보내지 않습니다. 동일한 정보가 포함된 두 번째 이메일을 받아야 하는 이유는 무엇입니까?

그 대상이 정상적인 이메일 이벤트 및 ostiket 알림을 받았기 때문에

인터페이스에서 티켓을 만들 수 있고 여기 첫 번째 단계에서 colaboratos를 추가하면 보낼 메일은 모든 관련(저자, 클라이언트 및 공동 작업자)을 위한 것입니다.

관련된 사람들이 정상적인 이메일을 받았기 때문에 정상적인 이메일로 답장을 받았고 모든 위협은 thiket 위협 외부에서 발생했습니다! 지원 기술자의 진정한 고통

내가 @greezybacon 이라고

아직 해결안됨??

물론 해결책이 없습니다. owncloud에서 이 프로젝트를 올릴 때까지... 포크를 올리면 개발 속도가 느려집니다... 새 포크로 마이그레이션

@인파워 참조:
greezybacon이 2016년 6월 25일에 댓글을 남겼습니다.
"mckaygerhard 공동 작업자가 티켓을 만드는 데 사용된 이메일에 이미 포함되어 있기 때문에 초기 이메일을 보내지 않습니다. 동일한 정보가 포함된 두 번째 이메일을 받아야 하는 이유는 무엇입니까?"

있습니다:
A: 공동 작업자와 함께 UI에서 티켓을 열 수 있는 방법이 없습니다.
B: 공동 작업자와 함께 티켓을 여는 유일한 방법은 티켓 시스템에 이메일을 보내고 사람들을 참조하는 것입니다. 그리고 DEV는 모든 수신자에게 하나가 아닌 두 개의 이메일을 보내지 않기로 결정했습니다.

반복합니다: 관련된 사람들은 fitrs 단계에서 일반 이메일로 수신/보내고 일반 이메일로 응답하며 모든 위협은 thiket 위협 외부에서 발생합니다! 지원 기술자의 진정한 고통

따라서 귀하의 주장은 다음과 같습니다.
내가 이메일을 보내는 경우: [email protected].
[email protected] , [email protected] , .
Jon, Mary, Jane이 원본 이메일을 받지 못한다고?

그러나 우리가 osTicket에서 첫 번째 응답을 보냈을 때 첫 번째 항목의 CC가 포함되어 있지 않기 때문에 이것은 하나의 이메일로만 이동합니다.,,

@ntozier u는 두 명 이상의 사용자가 소음을

@inphower 는 메일, 참조 및 작성자 모두가 공동 작업으로 티켓에 포함됩니다.

여기에서 문제는 CC로 메일을 보낸 사람들이 티켓의 위협이 아닌 메일을 받게된다는 것입니다 ...

따라서 이들 중 하나가 응답하면 티켓은 응답 메일에 없기 때문에 위협 기록을 받지 못한 것이 분명합니다.

내 말은: Jon, Mary 및 Jane은 원본 메일을 받지만 티켓뿐만 아니라 "보내기" 때문에 최종 및 실제 수신자가 "티켓"이라는 사실을 이 사람들에게 "통보"하지 않습니다.

Jon, Mary, Jane이 보낸 메일 이후에 티켓에 다른 티켓이 있으면 "아, 그래 티켓이었어, 사적인 대화가 아니었어"라고 생각할 것입니다.

물론, 우리는 티켓 설문 조사, 티켓 지원 또는 그 이름이 무엇이든 그 이유를 "더미" 사람들과 연결하고 있습니다!

그래서 그 위협은 고통으로 이어지기 때문에 역사는 그 일이 일어났을 때 잃게 될 것입니다.

@inphower u는 서포터가 작가로 티켓을 열 때 언급하는 것

이제 pull이 상황을 해결하는 것 같았습니다. #3353은 매우 쉬워 보입니다. 그 당시에는 1.9에서 구현된 개발자들에게 왜 그렇게 복잡했는지!

이 문제는 1.10에서 계속 발생했습니다 ... 공동 작업자가 표시되지 않고 알림이 표시되지 않습니다!

@mckaygerhard

여기서 일련의 사고 방식은 공동 작업자가 사용자로부터 원본 이메일을 받기 때문에 새 티켓 알림을 받을 필요가 없다는 것입니다. 이것이 원하는 것이 아니라면 원하는 대로 코드베이스를 수정하는 것을 환영합니다.

건배.

솔루션은 #3353에 있는 것 같지만 개발자는 다시 해당 문제에 대해 아무런 조치를 취하지 않습니다. 퍼프 때문에 많은 포크와 "삭제된" 댓글이 있습니다.

@mckaygerhard

실제 문제가 없으므로 "수정"이 없으며 이것이 작동하는 방식입니다. 앞서 언급했듯이 코드베이스를 수정하거나 언급한 pull 요청을 적용하고 완료하는 것을 환영합니다.

건배.

그런 다음 #3353을 당겨서 병합하십시오!

Hey pull은 약 10년 동안 #3353에 있습니다. 그리고 이제 @protich는 말합니다 : "우리는 커뮤니티와 함께 ​​하고 싶습니다"!???? 음 ...

모두 안녕. 대화를 하고 계시는 것이 기쁘지만 이 문제 보고서의 주제에서 완전히 벗어났습니다. 주제에 대한 문제 보고서를 보관하십시오. 감사합니다.

뭐가 문제야...그는 협력하고 있고 그들은 여전히 ​​불평하고 있어