sim, estou com você 100%
Este é o meu sonho também. uma função Merge seja ótima!
Porque muitas vezes os clientes iniciam um novo e-mail e não respondem com o número do ticket... do que seria ótimo "mesclar" esta resposta para um ticket existente.

Sim.
Mesmo o problema é que não existe um "link de ticket público" que possa ser adicionado.
Então, mesmo isso ajudaria se você pudesse fechar um ticket e dizer "Ver o número do ticket: #12345",
que vinculará uma equipe E um usuário ao ticket.
Por um lado, isso pode ajudar se a mesclagem não for possível, por outro lado, se você tiver tickets,
que seguindo a outra, você pode criar uma espécie de "maneira lógica".

Mas vamos ver o que os desenvolvedores pensam sobre isso ;)

FELICIDADES!

Eu gosto da ideia do link automático (veja #12345683)

@greezybacon

Devo abrir outro tópico para isso?

Então a ideia por trás disso é "apenas" apenas um botão que você aperta e você pode digitar um número de ticket (ou selecionar, mas isso é pesado).
Depois disso, um link será adicionado ao ticket.

Novamente, o problema não é adicionar o link em si, é que apenas a equipe OU um usuário pode visualizar isso.
Como eu disse o seguinte de problemas e mudanças que você faz, seria ótimo para lidar do começo ao fim, sem pesquisar.

Mas também você não pode, por exemplo, criar um link para um ticket na base de conhecimento, o que talvez possa explicar algo melhor também.

Eu gostaria de adicionar meu suporte para esta solicitação de recurso. Meus usuários são muito bons em enviar vários e-mails sobre o mesmo problema sem incluir o número do ticket, e eu rapidamente perco todas as informações necessárias para resolver o problema.

Mesclar bilhetes seria incrível! Mesmo que seja apenas digitando um ticket #.

Duplicado de https://github.com/osTicket/osTicket-1.8/issues/1068?

Por favor, pesquise antes de enviar um novo problema!

Bem, em geral, é a mesma citação.
Mas, por outro lado, separar com minha explicação como um link automático é outro recurso do que mesclar tickets.

Portanto, não faço ideia de como lidar com isso agora.

Na minha opinião, o primeiro passo "mais fácil" seria adicionar uma opção de link para um ticket que pode ser visualizado pela equipe e/ou usuário.
Então você pode criar uma espécie de processo/histórico ao tentar encontrar soluções ou entender algo.

Mas de qualquer forma seria legal no futuro ter uma espécie de "bilhete principal" que só pode ser adicionado bilhetes novos/iguais/duplos.
Para que você obtenha um ticket para um e veja todas as diferentes soluções, maneiras de usuários em uma lista de tickets que foram mesclados.

Essa é a minha ideia disso, mas não sei se alguém pode entender e ver isso com tanto sentido quanto eu vejo.

FELICIDADES

Referenciar / Vincular é a sugestão original de @greezybacon na qual eles estão realmente trabalhando e é chamado de 'Problemas'. Agrupar tickets semelhantes faz muito sentido, mas é diferente de mesclar. Com uma mesclagem, você só precisa 'mover' todas as entradas de ticket para o novo ticket, vincular/agrupar exigiria uma nova tabela.
Então, sim, é basicamente a mesma coisa que você está falando @ Hannibal226

vou programar isso nos próximos dias/semanas. e distribuí-lo como pull request.

acho que não é tão difícil "mesclar tickets" se as mensagens forem classificadas por tempo. e na maioria dos casos, se você mesclar um ticket, terá apenas "uma" mensagem. Porque talvez seja um novo ticket que o usuário final respondeu errado/escreveu um novo e-mail e não usou o botão de resposta.

Minha ideia é:

• você tem um botão "Mesclar com outro Ticket".
• se você pressioná-lo, abre um pop-up e você escreve/pesquisa o ticket onde deseja mesclar este ticket.
• do que você foi solicitado a adicionar o remetente como colaborador (se não for o mesmo e-mail do proprietário)
• do que você pediu feche o "novo ticket" no final ou exclua-o.
  se você fechá-lo, então uma nota adicionada com todas as informações como:
  quem enviou (e-mail/nome) hora/data e o número do ticket do ticket fechado
  OU
  quem enviou (e-mail/nome) hora/data

final.
Eu acho que é uma função realmente necessária. Muitas vezes tenho clientes que escrevem um novo e-mail e não usam o botão de resposta. do que eu fecho manualmente o novo ticket e adiciono o número do ticket ao "bilhete principal". Mas isso não é tão legal se você precisar mudar de ticket para ticket para entender o que acontece.

@mrsaw12 posso sugerir que você tente implementá-lo como um plugin?

@Mrsaw12

Isso soa gr8 e eu realmente gostaria de testar isso;)
E como você disse, não é tão complicado, mas de qualquer maneira eu não sou muito de PHP e MySQL e muito difícil para mim.

Muito sucesso e nos avise quando estiver pronto ;)

PARABÉNS amigo!

@kordianbruck

Então, de qualquer forma, não tenho certeza.
Há duas maneiras se você receber de um ticket dizendo que ele deve ser mesclado e/ou vinculado a qualquer coisa OU você escolher vários tickets e agrupá-los.

Novamente, isso é muito profundo e está faltando qualquer uma dessas funções e estou feliz por termos caras tão ativos como @mrsaw12 que estão gastando um pouco de tempo para ajudar rapidamente aqui.

Com certeza os principais desenvolvedores como @greezybacon ou todos os caras ao lado de r estão fazendo mais do que o suficiente e isso não deve ser entendido como qualquer pressão ou algo assim.

De qualquer forma obrigado a você por pensar em conjunto e talvez com uma solução ambas as partes r felizes com o resultado, para que possamos dizer "sim, é o mesmo" ;)

FELICIDADES

Nos próximos meses, adicionaremos a capacidade de um ticket ter vários tópicos (por meio de "tarefas"). Seria interessante ver se isso ajudaria na fusão de tickets

@greezybacon Legal, bom ouvir!

Oi! estou querendo saber se há alguma atualização para este aprimoramento? Muito necessário. obrigado!

+1

@greezybacon Bom ouvir e obrigado!

também procurando uma atualização sobre isso. Mesclar tickets é essencial para nosso fluxo de trabalho, obrigado.

Oi pessoal,

Eu usei muitos sistemas de emissão de bilhetes, e todos eles se fundem através da mesma metodologia básica (Ceberus, Zendesk, RT, etc.)

Eu adoraria ver a fusão no osTicket consistente com o que a maioria dos outros sistemas de bilhética oferecem.

1) Permita que o Agente selecione vários tickets de qualquer visualização (lista de resultados de pesquisa, minha lista de tickets, outras listas) e pressione um botão MERGE.

2) Uma vez que o botão MERGE é pressionado

• TODOS os dados são mesclados em um thread de ticket, ordenados por data
• O número do ticket MAIS ANTIGO é o número do ticket mesclado
• TODOS os colaboradores e agentes estão no novo ticket

É uma mesclagem - você pega tudo e coloca em uma coisa que é representada pela coisa ORIGINAL (mais antiga).

Mesclar e reduzir duplicatas são os recursos mais críticos em um ambiente de alto volume para reduzir o trabalho estúpido e desnecessário na emissão de tíquetes. Eles são, IMHO, buracos de recurso escancarados no osTicket.

+1 ricobodo

+1!!!

apesar de muitos pedidos para uma função de mesclagem, nenhum progresso ???

:( vai demorar muito? Mesclar ticket é muito útil.

A mesclagem não é particularmente importante, pois há recursos/funcionalidades mais importantes acima dela.
Eu não esperaria um recurso de mesclagem por um tempo.

Triste por isso :) mas eu posso entender que você tem muito trabalho.
Nestes dias eu tinha usado muito a função de mesclagem em outro ticket de código aberto, então .. realmente faz falta no OsTicket.

Bem, espero ver este projeto Merge não esquecido.

Para mim, o OsTicket tem coisas para implementar/corrigir:

• Mesclar tickets (este problema)
• Edição do tópico no ticket (já feito e será lançado em breve, ótimo!) https://github.com/osTicket/osTicket-1.8/issues/1173
• Corrija a hora errada na página de registro do usuário https://github.com/osTicket/osTicket-1.8/issues/1842
• Corrija um bug no link do ticket https://github.com/osTicket/osTicket-1.8/issues/2024
• Talvez tema responsivo https://github.com/osTicket/osTicket-1.8/issues/2030
• Bilhete de fechamento automático em certas estátuas https://github.com/osTicket/osTicket-1.8/issues/2036
  E OsTicket será o melhor código aberto

Uau, muitas pessoas estão seguindo isso :-) Mesclar tickets, ótimo!

Aguardando fusão com antecipação ansiosa!

Estou adicionando o código em mim por enquanto, então não atualizarei além de 1.9.4 até que Merge seja um dos recursos adicionados.

Se existir um código estável para mesclar tickets, por que não adicioná-lo ao branch principal?
Parece haver uma demanda por isso...
A fusão seria uma grande melhoria para nós!

Sim, mesclar tickets muito cheio de usuários.

Inviato do dispositivo móvel. | Enviado por dispositivo móvel
Il 13/Mag/2015 07:03, "Eddie-BS" [email protected] tem escrito:

Se existir um código estável para mesclar tickets, por que não adicioná-lo à lista principal?
ramo ?
Parece haver uma demanda por isso...
A fusão seria uma grande melhoria para nós!

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment -101513518
.

A junção de tíquetes seria um grande benefício para nós, pois muitas vezes nos deparamos com casos em que um usuário criou tíquetes em dois endereços de e-mail e queremos juntá-los em uma conta e, atualmente, isso precisa ser feito um de cada vez usando o proprietário da mudança (ou você precisa escrever uma consulta para fazer isso no back-end, mas isso é sempre perigoso porque você pode perder algo que o software normalmente teria tratado).

Será userfull também mesclará também o mesmo ticket de usuário, mas um ticket diferente, portanto, se o usuário A fizer dois tickets diferentes, a capacidade de mesclar em um.

+1 para isso também. Realmente desejo que o OSTicket tenha essa função um dia.

+1 para esta função, seria perfeito se isso fosse possível

+1

Imagine se o Github não tivesse um recurso de mesclagem ...

+1

Mesclar tickets seria uma adição muito útil. Eu amo o jeito que as coisas estão indo com 1.10rc1, mas houve tantas mudanças no código que os ajustes de mesclagem antigos não são tão fáceis de implementar. Eu gostaria de ser mais experiente em PHP.

+1

+1 É muito necessário!

O recurso de internacionalização incrivelmente detalhado implementado na versão 1.10 está pronto e agora o outro recurso restante é a mesclagem de tickets, que é essencial para centros de suporte de alto volume. Espero que isso chame atenção para 1.10 ou 1.11 para que osTicket atire antes de outras soluções.

+1

Sim eu concordo

+1

O que seria necessário para alguém desenvolver esse recurso e fundi-lo com o OSTicket?

Apesar do comentário de ntozier de "Mesclar não é particularmente importante, pois há recursos/funcionalidades mais importantes acima dele. Eu não esperaria um recurso de mesclagem por um tempo". com base na grande quantidade de +1s e tickets abertos duplicados, eu diria que a demanda é bastante alta.

Eu tenho escrito PHP por 16 anos. Eu poderia escrever um método de mesclagem. Eu gostaria de conversar com os desenvolvedores líderes sobre o esquema de banco de dados e suas opiniões sobre a melhor maneira de implementar a mesclagem. Ou posso revisar o esquema e sugerir uma implementação. Mas antes de fazer isso, gostaria de ter certeza de que meu trabalho pode chegar ao OSTicket Trunk.

Isso é uma possibilidade?

:+1: para @ooglek

@ooglek
Parece bom e razoável para mim. :)

Desenvolvedores, o que acham?
@protich
@greezybacon
@nfebuary

Isso!

:+1:

@ooglek
Legal que vc mostra essa iniciativa!

Tenho certeza de que @greezybacon também agradece, mas com certeza não sei quais são as regras deles sobre adicionar alguém ao github.
Talvez você possa criar a função de mesclagem ao lado?

Mas temos que esperar os desenvolvedores e ver.

Obrigado novamente.

Re: "mas com certeza eu não sei quais são as regras deles sobre adicionar alguém ao github."
Qualquer pessoa pode entrar no github e fazer um pull request.
Os desenvolvedores revisarão as alterações e as aceitarão ou recusarão.

@ntozier
OK, desculpe, eu quis dizer a parte do github 'osticket', não o github em geral, desculpe: P

Mas parece que é possível para @ooglek então ;)

Isso é definitivamente algo que eu adoraria ver adicionado ao osticket. Esse recurso definitivamente me ajudaria a vender isso para a administração, adotando isso em relação a outro sistema de emissão de bilhetes que estamos usando.

+1

Jogando meu próprio +1 na mistura.

Queremos migrar de outra solução de emissão de bilhetes, e a mesclagem é essencial. Recebemos muitos novos tickets que deveriam ser respostas aos existentes e, como precisamos acompanhar com precisão o uso dos tickets, acabamos mesclando muito.

Eu estive pensando sobre isso nos últimos dias. Vou trabalhar na interface do usuário e conversei com @greezybacon e ele mencionou colocar um pouco de energia nisso também. (a agenda dele é um pouco louca, então tenha isso em mente) @ooglek qualquer assistência é bem-vinda, você e eu podemos discutir a interface do usuário e você pode discutir o back-end com @greezybacon. Acho que podemos fazer isso acontecer. ah e +1

Alguém poderia montar uma RFC mais formal no processo de mesclagem para que pudéssemos considerar problemas com o processo de mesclagem e elaborar algumas definições sobre como fazer isso no osTicket? Acho que algumas das questões levantadas até agora:

• Como os tópicos são mesclados? São os itens dos tickets díspares:
  
  
  
  • Entrelaçados em ordem cronológica
  
  
  • O encadeamento do(s) ticket(s) recolhido(s) é adicionado ao final do encadeamento do ticket mesclado
  
  
  • Segmentos separados mostrados na interface do usuário por meio de guias separadas
  
  
  • Nenhuma mesclagem de thread é executada. Em vez disso, os tickets são fechados e os links de "ticket relacionado" são adicionados ao ticket mesclado
  
  
• Como os metadados são mesclados? Especificamente
  
  
  
  • A data de vencimento
  
  
  • Responsáveis ​​(funcionários e equipe), bem como departamento roteirizado
  
  
  • Dados e formulários personalizados adicionados aos respectivos tickets
  
  
• Qual é o processo de fusão?
  
  
  
  • Ação de seleção múltipla da fila de listagem de ingressos
  
  
  • Ação na lista suspensa mais na visualização de tickets
  
  

Eu posso tentar digitar algo, mas não tenho um caso de uso forte para o recurso, então acho que outras pessoas provavelmente teriam mais sentimentos e orientações sobre como as coisas deveriam funcionar

Um pouco ocupado no momento, mas meus pensamentos imediatos são:

• Escolha caso a caso de mesclagem cronológica ou acréscimo de threads
• Decisões por item para data de vencimento, cessionários, etc.
• Ação da lista suspensa "Mais"

Nosso problema atual (e isso pode ser um pouco mitigado por ter um portal em vez de apenas e-mail) é que um usuário abrirá um ticket, não receberá uma resposta dentro de algumas horas (ele pode ter aberto um ticket fora do nosso horário de expediente ou poderíamos estar de férias) e depois abrir outra perguntando se pegamos a primeira. Ou temos que fechar um que atrapalhe nossa contabilidade ou nos fundir.

O outro caso é quando as pessoas abrem um ticket e enviam mais informações em um e-mail separado que, por causa de uma linha de assunto diferente, será registrado como um novo ticket. Isso também seria potencialmente mitigado usando o portal, mas queremos manter a capacidade de permitir tickets baseados em e-mail.

@greezybacon
Acho que primeiro seria bom ver duas opções:

1)
Do Ticket A e Ticket B para mesclar (como nota vinculada) ao Ticket C.
Com esta etapa automaticamente uma informação sobre a mesclagem deve ser enviada ao usuário e
fechar A e B.

• Quer dizer agora, quando você vê em 'abrir' o Ticket C, você pode ver mais velhos ou
  outras opções apenas indo para as vinculadas.

2)
Do Ticket A e Ticket B se fundem em um NOVO Ticket C.
Mesmas funções que acima, mas o Ticket C será criado novo com implement
os existentes.

Na minha opinião, esta é a principal necessidade de manter o sistema de tickets limpo.

DEPOIS, uma opção para alternar o Bilhete A ou o Bilhete B diretamente no Bilhete
C seria bom, mas acho que isso precisa de algum tempo (tema etc.) e não é
tão importante para o atm de fusão principal.

FELICIDADES!

Não acho que a mesclagem de tickets deva resultar na criação de um novo ticket

Não vou citar nomes, mas a forma como nossa solução atual funciona é que você escolhe o ID do ticket no qual deseja mesclar, então o outro tem todo o seu conteúdo substituído por uma mensagem com o efeito de "O ID do ticket XXX tem foi mesclado em ID YYY". Isso preserva o fato de que houve uma mesclagem realizada sem criar um novo ticket. No entanto, como faturamos com base no uso do ticket, isso ainda deixa dois tickets quando deveria haver apenas um.

Portanto, é importante manter um registro do que aconteceu, mas também é importante fazê-lo de maneira limpa e intuitiva.

Uma maneira que o OTRS fez isso foi "vincular" tickets. Por exemplo, um ticket seria considerado "o mestre" e outros tickets seriam mesclados a ele.

Na tela, toda a correspondência seria "sindicalizada" e exibida cronologicamente, independentemente de quais bilhetes vinculados a correspondência veio.

Isso permite um relacionamento pai-filho. Você também pode "vincular" tickets de forma que eles estejam relacionados, mas ainda dois tickets separados.

Os tíquetes considerados filhos não apareceriam na exibição ou na contagem "Aberto/Fechado/Resolvido".

Eu concordo com @greezybacon que a fusão NÃO deve criar um novo ticket.

Na minha opinião sincera, uma vez que os tickets são criados, eles não devem ser modificados na estrutura do banco de dados, mas usar um software para "mesclar" eles. Dessa forma, a "desfusão" é possível, embora a nova correspondência só seja adicionada ao bilhete "mestre", mesmo que o antigo bilhete tenha recebido nova correspondência. Embora isso não seja realmente necessário, acho que seria mais limpo "congelar" os tickets filhos quando eles estão vinculados a um pai/mestre.

Não no primeiro sentido, correto.

Mas muitas vezes você precisa dessa opção ao limpar os ingressos.
Então você reconheceu novas atualizações ou conexões.

Agora você pode adicioná-lo a um ticket existente, mas não sabe para qual ou você cria primeiro um novo e depois os mescla.

Por que não há opção de mesclar diretamente para o novo?

Novamente eu entendo que o "merge" na primeira maneira significa juntar as coisas, mas na última opção você cria talvez um novo ticket para fazer exatamente isso.

PS: Apenas meus dois centavos sobre isso com certeza :P

FELICIDADES

@Hannibal226 -- Criando um novo ticket -- como um cliente responde ao ticket antigo? Como isso é tratado? Pelo menos mantendo a estrutura de dados a mesma e criando um link entre dois tickets, um cliente pode responder a qualquer ticket e o código de tratamento de resposta não precisa ser alterado -- ele pode entrar em qualquer ticket (sim, isso não é o que eu sugeri com o congelamento do bilhete infantil, estou descartando as opções). Tudo o que você precisa fazer ao retirar um ticket é:

• Este bilhete tem filhos? Em caso afirmativo, obtenha todas as respostas desse ticket e mescle-as com este ticket para exibição.
• Este bilhete tem um pai? Em caso afirmativo, redirecione e exiba o pai em vez do filho
• Na contagem e nas exibições de tickets "abertos/fechados/resolvidos", ignore e não conte tickets vinculados como filhos a outro ticket pai/mestre.

As modificações são muito mais simples, porque você não precisa alterar a lógica para lidar com uma resposta recebida... muito. Eu só pensei em algumas coisas.

• Mudanças de Status: Fechando o Master fecha a(s) criança(s)? Ou o status de criança/filhos é ignorado?
• Uma resposta do cliente ao ticket filho deve reabrir o ticket master.
• O status deve ser sincronizado entre mestre/filho?

Acho que manter a estrutura do sistema existente o mais semelhante possível, adicionando complexidade apenas quando absolutamente necessário, e não copiando dados ou executando atualizações em IDs, servirá melhor e provavelmente reduzirá o desafio de fazê-lo funcionar.

Pessoalmente, gosto da ideia de tickets "vinculados" e penso em uma mesclagem mais como um "grupo de tickets". Então, quando o usuário Alice, Bob e Charlie relatam o mesmo problema, esses tickets são vinculados uns aos outros e um agente pode (pense no recurso "responder" versus "responder a todos") e atualizar, responder etc. usuários (Alice Bob Charlie) por meio desses tickets vinculados / mesclados ou para apenas um único usuário (Bob).

Acho que, se fizer dessa maneira com tickets vinculados, a parte mais difícil é tornar a interface do usuário tão intuitiva que seja fácil e claramente compreensível se você, como agente, atualizar / responder / etc. a um "grupo de tickets" (como eu chamaria isto) ou a um único bilhete.

Do ponto de vista do usuário final, acho que faria sentido obter as informações de que outros usuários relataram o mesmo e todos ou apenas eu (como um único usuário final) obter agora uma resposta do agente com base em fatos e sentido, como a importância do mensagem de um agente.

Mesclar tickets é realmente difícil de perceber, eu acho, pois há muitas maneiras de como isso pode ser implementado e também muitos casos de uso diferentes para abordagens de mesclagem de tickets.

Saúde,
Michael

Conversamos sobre a adição do conceito de "Problema". Os problemas são como a relação entre tickets e tarefas. No entanto, os tickets são grampeados aos problemas como um relacionamento pai/filho. O caso de uso que usei com frequência é uma interrupção do datacenter. O grupo de TI provavelmente receberá várias notificações de tíquetes enraizados no "problema" de interrupção do datacenter. Portanto, um novo problema pode ser criado e todos os tickets podem ser associados ao problema. As respostas ao problema são transmitidas aos respectivos proprietários de ingressos. Quando o problema é encerrado, todos os tíquetes filhos também o são.

Acho que a fusão é algo completamente diferente. Muitas vezes pensamos na fusão como mais uma operação de substituição. Ao mesclar tickets, todos, exceto o último ticket, são efetivamente excluídos. Os encadeamentos são acessíveis apenas a partir do ticket mesclado restante. As respostas por e-mail na v1.10 não estão mais associadas ao ticket; em vez disso, eles são associados ao encadeamento. Portanto, se o ticket for removido quando mesclado e o thread estiver de alguma forma associado ao ticket mesclado, as respostas nos tickets recolhidos/excluídos continuarão no ticket mesclado por meio de seu(s) thread(s).

@ooglek

Mas o que você tem de um Ticket C mesclado quando o usuário responde ao Ticket A e B?
Eu acho que com as coisas de "pais/filhos" é mais complicado do que apenas ter links que acabaram de fechar.

Então, com certeza, todos os usuários e colaboradores devem ser mesclados na minha opinião...

Para ficar no exemplo de novo ticket (que não é a principal função de que falamos), sempre temos que ir adiante de um ticket:

Então entre no Ticket B e crie um novo Ticket C, o que significa que todos os usuários e colaboradores serão usados ​​como em B.
Então você tem que mesclar o Ticket A, que só incluirá os Colaboradores caso ainda não exista para C.

FELICIDADES

@Chefkeks Não posso concordar com o agrupamento de ingressos da perspectiva do usuário. Isso está muito perto de misturar informações potencialmente privadas de tickets de clientes separados e tornaria muito fácil a ocorrência de contaminação cruzada.

Eu acho que é aqui que o Issues seria útil. Como exemplo de fluxo de trabalho:

Três organizações/usuários separados estão relatando o mesmo bug no processo de atualização, então criamos um problema como "Erro recebido ao atualizar" e vinculamos esses tickets a esse problema. Em seguida, crie uma tarefa para resolver o bug e vincule essa tarefa a esse problema e, por associação, os tickets.

-desculpe, aperte o botão errado no novo aplicativo-

Estou muito interessado nisso, no entanto, parece bastante complexo. meus requisitos - (e esses podem ser apenas meus) são muito mais simples.

o cliente a cria um ticket, o cliente b (ou cliente a com um endereço de e-mail diferente) escreve sobre esse ticket, mas não responde no tópico original. Agora copio o conteúdo do e-mail como uma nota interna e adiciono o segundo endereço de e-mail como colaborador.

Isso funciona, mas o problema é que os anexos não podem ser transferidos via copiar e colar.
então, para mim, uma mesclagem muito simples ou uma mensagem anexada ao ticket existente seria suficiente.

@snizzleorg
Isso não é mais simples o que você quer dizer, o que você faz é apenas mais manualmente :P

Então, estamos falando para fazer um link para um ticket inteiro, você está falando sobre receber uma mensagem de texto do ticket.
Pelo menos todos nós precisamos do mesmo, mas existem várias maneiras e agora há a questão das mais práticas/úteis.

Ou você quer me dizer que um botão não seria melhor que copiar e fechar tudo manualmente? :P
(até mesmo a cópia do anexo seria possível)

FELICIDADES

Ok, bem, acho que "problemas" como @greezybacon explicou é o que eu tinha em mente com "grupo de ingressos".

Em relação à perspectiva do usuário final e à segurança de dados / informações privadas de tickets separados, você pode ter me entendido um pouco errado.
Minha ideia era mais como uma resposta normal que é transmitida para todos os proprietários de tickets para que todos obtenham as informações do agente e também possam, com base na organização a que os proprietários do ticket pertencem, o que outros usuários relataram. Portanto, mantendo os tickets individuais para os usuários finais, mas com algumas possibilidades para os agentes lidarem mais facilmente com tickets com o mesmo problema.

Dito isso e leia o que Jared escreveu sobre "problemas" e como ele pensa sobre a fusão de ingressos como algo completamente diferente, tenho que admitir que sou mais um "fã" dos "problemas" e sinto que pode ser uma maneira melhor de mesclando ou digamos manipulação/gerenciamento de tickets.

Michael

@chefkeks

Mas você não acha que está ficando confuso e complicado (na codificação) ter um ticket/transmissão para a equipe, mas separado para os usuários?

Eu acho que é muito mais fácil substituir os tickets existentes de usuários por um ou melhor dito por um.
Então isso deve acontecer automaticamente, quando os tickets "antigos" forem fechados e o mesmo usuário/colaborador r no novo ticket.

O usuário agora também pode ver que algo está acontecendo neste caso, que talvez seja apenas uma parte, já que são coisas do segundo ticket (um pouco teoricamente agora xD)

FELICIDADES

Há necessidade de ambos. Há a necessidade de lidar com várias solicitações de um único usuário que devem ser consolidadas ou "mescladas". Há uma necessidade separada de consolidar várias solicitações diferentes que estão relacionadas por meio de um "problema" comum. O agrupamento de problemas não implica em conceder aos usuários acesso aos tickets uns dos outros. No entanto, isso implica o conceito de "tíquetes públicos" em que um problema pode ser postado no portal do cliente, indicando algo como "Estamos cientes dos problemas do datacenter neste momento..."

Os dois devem se tornar recursos separados. Eles não devem ser combinados.

Eu concordo totalmente com isso!

Os dois devem se tornar recursos separados. Eles não devem ser combinados.

Então, acho que, com seu último post em mente, Jared, deve haver 2 problemas de RFC aqui no github para discutir ambos independentemente um do outro, mas com uma referência um ao outro, para que as pessoas estejam discutindo apenas a mesclagem de tickets ou problemas/grupos de tickets .

Felicidades
Michael

PS: Como a equipe do osTicket é realmente experiente em codificação e design de interface do usuário, não me preocupo com o fato de poder ser muito confuso nem para os agentes nem para os usuários finais.

@greezybacon

Mas por que tão "complicado"?

Os usuários só podem acessar os tickets que eles têm permissão.
Então por que não concluir o que você quer, já que os usuários não podem acessar por exemplo um ticket de outro, se não forem colaboradores?
Acho que, se os privilégios funcionarem bem, não precisa haver uma separação disso.

Você até poderia nomear o "problema" - "projeto" ou "tarefa" ou "grupo", mas a pessoa x só pode acessar o ticket principal (mesclado) e os tickets dentro dele, desde que seja criador ou colaborador disso.

Talvez eu ache um pouco pequeno neste caso, mas não tenho certeza se isso se tornará grande se você começar a se separar, pois talvez venham novos casos e solicitações de casos entre, ou?

PS: Estou apenas pensando em forma de usuário e quase implementação, desculpe se soa tão facilmente e não é com certeza xD xD

FELICIDADES

"Problema" implica um novo paradigma para os usuários OST entenderem e gerenciarem. Como o @snizzleorg disse, quando os emails do cliente A e os emails do cliente B (ou emails do cliente A de um endereço diferente), esses são 90% dos meus casos de mesclagem.

Por um tempo, foi bom ter um ticket e poder se comunicar com a Pessoa A sobre um problema e depois se comunicar com o Fornecedor B sobre o mesmo problema, mas excluindo a Pessoa A, mas todos ainda no mesmo ticket, no OTRS. Mas eu não preciso disso, apenas foi bom.

Eu pessoalmente não gosto da ideia de um "Problema" ser criado porque eu disse ao sistema que esses dois tickets são sobre o mesmo problema, independentemente de quem está no ticket.

Como o @tmcnag mencionou, acho que "contaminação cruzada" é algo que o usuário deve decidir, não a ferramenta. Em alguns casos eu posso querer "contaminar cruzado" na sua opinião, mas na minha é uma ferramenta.

Por que um Ticket A e um Ticket B, onde um cliente enviou um e-mail uma vez e, em seguida, enviou um e-mail novamente 5 minutos depois para dizer "Opa, não importa", mas não respondeu ao Ticket A, por que isso deveria se tornar "um problema" - eles realmente são apenas um tíquete que o cliente não conseguiu fazer como um tíquete. Eu só quero verificar os dois (ou três ou quatro) tickets e "mesclar" eles (o IMO os vincula caso eu mescle os errados) e ter uma linha do tempo única e unificada de respostas e conversas que me permitam gerenciar tudo em um ticket, como _I_ pretendia, mesmo que o cliente não tenha "feito a coisa certa" respondendo ao e-mail certo.

Acho que adicionar "Problemas" torna isso ainda mais complexo - 90% dos casos serão de um cliente que receberá dois e-mails sobre a mesma coisa e eu os quero no mesmo ticket.

Concordo com @greezybacon -- Problemas são um conceito útil. Mesclar tickets é uma função útil. Eles devem ser desenvolvidos separadamente e não cooptados.

Eu gosto da ideia de um novo tipo de ticket (emissão) que seria como um mega ticket. Que poderia ser usado para combinar vários tickets em um único problema ... ou até mesmo aberto pela equipe quando / se algo grande acontecesse que afetasse muitos. Pessoalmente, eu raramente usaria isso em qualquer um dos meus sites ao vivo. Mas talvez eu queira usá-los para coisas como manutenção programada, grandes interrupções de rede etc.

Dito isto, eu provavelmente usaria um recurso de mesclagem com mais frequência. Espero que seja algo parecido com como fazemos manualmente agora. Que é atualizar um ticket (o criado posteriormente) dizendo que já existe um ticket aberto para este problema (ticket de referência #) fechando ticket duplicado. e, em seguida, atualizar o ticket original com qualquer informação adicional e adicionar o abridor do segundo como colaborador.

Estou com @ooglek Issues e a fusão seria duas coisas diferentes. A fusão seria mais útil para nossa empresa enquanto o conceito de questões - não tenho certeza se precisamos disso. É legal mesmo...

Sinto que ainda há alguma confusão.

Mesclar tickets, proprietários, threads e dados é:

• o que causa "contaminação"
• para ajudar a manter o mesmo problema da mesma pessoa ou grupo de pessoas nos mesmos dados e linha de comunicação
• (possivelmente) remove tickets quando mesclados em outro

Associando tickets por meio de um problema

• mantém (todas) as coisas separadas
• permite comunicação separada, dados, proprietários, colaboradores, em questões "relacionadas"
• adiciona tickets "relacionados" a uma visualização de ticket
• adiciona uma nova lista de itens ao sistema, "problemas"
• permite a comunicação de massa e fechamento

@greezybacon bom resumo. basicamente dois novos recursos

@snizzleorg Estou sugerindo que é assim que os dois recursos funcionariam. Espero remover alguma confusão sugerindo propósitos distintos para dois recursos distintos. Minha esperança é colocar todos na mesma página para que possamos trabalhar para avançar com RFC e implementações para os recursos.

Agradável. Como disse, estou mais interessado na fusão e acho que pelo menos esse recurso está bem definido. Permanece a questão de como selecionar o ticket resultante do proprietário se os dois tickets iniciais forem diferentes e resolver conflitos nos próprios dados do ticket.

Eu sugiro:

1 + mesclar 2 = dados/proprietário do ticket 1

2 + mesclar 1 = dados/proprietário do ticket 2

Eu voto para dar ao usuário (agente) a escolha de quais dados o ticket mesclado terá.

Então dê ao usuário uma predefinição/sugestão dos dados do ticket mesclado que ele pode
A) aceitar e prosseguir com a fusão ou
B) alterar completamente a direção das fusões (assim 2 + merge 1 = dados/proprietário do ticket 1 em vez do ticket 2) ou
C) editar campos únicos (por exemplo, tópico da Ajuda) antes da mesclagem dos tickets

@greezybacon Sobre a mesclagem de tickets, acho que há alguma confusão sobre o efeito de uma mesclagem para o usuário e os meios reais da mesclagem no back-end.

• Contaminação -- se ambos os tickets forem mantidos separados no banco de dados, não haverá contaminação. Em uma ação de "mesclar", um "link" entre dois tickets seria criado e um tipo de relacionamento (o ticket 3 é filho do ticket 4, o ticket 4 é pai do ticket 3). O software manteria os status de ticket vinculados em sincronia – quando um status de ticket pai é alterado, todos os status de ticket filho mudam. Quando um ticket filho recebe uma comunicação por email, essa comunicação de ticket é atualizada e qualquer alteração de status de um filho é sincronizada em todos os tickets vinculados. O Ticket 4 exibiria a comunicação atualizada no Ticket 3. Nesse caso, não haveria contaminação, e você sempre poderia desvincular (unmerge) os dois tickets com pouco ou nenhum efeito (o único efeito que consigo pensar é se você adicionasse colaboradores de tíquetes filho para tíquetes pai ao mesclar, e você provavelmente não gostaria de desfazer isso ao desfazer a mesclagem).
• Retenção de Colaboradores -- Acredito que 90% das fusões serão da mesma pessoa, seja do mesmo e-mail ou de dois e-mails diferentes gerenciados pela mesma pessoa. A preocupação desses 10% é apenas documentar pesadamente (e também na interface do usuário no momento da mesclagem) o que será feito (Adicionar automaticamente colaboradores ao ticket mestre a partir de ticket(s) filho(s)) e garantir que o usuário saiba que se isso não é o que eles querem, para desfazê-lo. Ou adicione uma caixa de seleção marcada por padrão "Mesclar proprietários de tickets com colaboradores no pai/mestre" e, se você desmarcar, os colaboradores não serão modificados no pai.
• Removendo Tickets -- NÃO! Não faça isso. Isso é ruim.

Problemas é um novo recurso, até agora (que eu saiba) não projetado, não especificado e amorfo. Você poderia usar os problemas para mesclar tickets? Totalmente! Mas essa é realmente a intenção do recurso Problemas, mesclar tickets? Ou você está enrolando os problemas para permitir a mesclagem porque isso parece mais fácil?

Se os problemas forem problemas comuns que vários clientes estão tendo, os usuários/administradores do OST realmente desejam ver vários problemas de "Ticket mesclado" na lista? Para muitos usuários OST, eles podem não precisar de problemas, e eu ficaria confuso se a mesclagem de tickets "criasse" um problema. Você perde o contexto do ticket quando ele se torna um problema - agora eu tenho que lidar com "Tickets mesclados" de maneira diferente dos tickets normais e mudar para uma área totalmente diferente no OST para gerenciar tickets mesclados, que ficam fora das regras, escalonamento e operação em OST de Tickets Regulares.

Eu realmente sinto fortemente que usar problemas para implementar tickets de mesclagem causará muito mais problemas e desafios, tanto para o desenvolvimento de OST quanto para usuários de OST, do que descobrir uma maneira de implementar tickets de mesclagem de forma não destrutiva dentro da estrutura existente de tickets à medida que eles existem hoje, com a adição de uma tabela ou duas no banco de dados e algum código e gatilhos para lidar com ações em tickets que estão vinculados.

@snizzleorg Acho que você não entendeu o comentário do @greezybacon - ele não estava dizendo "dois recursos diferentes", ele estava dizendo "Problemas resolve tudo de forma limpa". Do que discordo acima.

@ooglek Você está combinando os conceitos de problemas (tíquetes vinculados) e mesclagem. Como você pode mesclar duas coisas e terminar com duas coisas que estão ligadas? A ideia de fundir implica juntar várias coisas em uma só; daí a remoção de itens mesclados.

@greezybacon @ooglek

MINHA opinião sobre isso é que, na visualização do banco de dados, ooglek está certo e os tickets não devem ser apenas excluídos.
No site de uso/interface, o greezy está correto e você precisa ocultar/substituir o material antigo, caso contrário, a fusão não faz sentido.

MAS, novamente, por que tão complicado?
Por que os tickets são fechados com a mesclagem (talvez um status de mesclagem específico)?

Isso significa que os tickets ainda podem ser acessados ​​ou melhor visualizados por meio do ticket/problema principal, mas não podem mais ser alterados.
Ou talvez um tipo de instantâneo seja implementado, para que você possa alterná-lo etc ... (mas isso é design depois)

E esse é o ponto em que mesclagem e emissão podem se separar (minha opinião), então na mesclagem dos tickets fechados e em emissão é uma listagem de tickets 'abertos'.

FELICIDADES

@greezybacon A mesclagem é um conceito de interface do usuário, não um conceito de back-end. Do ponto de vista do usuário, o ticket parece mesclado, porque uma vez que ele realiza a ação de Mesclar, ele vê que o ticket mestre tem toda a correspondência em ordem cronológica em sua visão, e a resposta vai para todas as partes mescladas (ou excluídas no momento da mesclagem ). Assim, o usuário vê um ticket mesclado.

No back-end, você deseja tornar as coisas o mais limpas e desfazíveis possível. Ao criar uma relação entre 2+ tickets, você pode:

• Aceite respostas a tickets filho por email porque esse ticket ainda existe – nenhum código adicional ou estrutura de banco de dados é necessário para lidar com emails recebidos com tickets que não existem mais.
• Unmerge -- as respostas ficarão com seus respectivos tickets -- o único problema remanescente são os colaboradores mesclados -- que também podem ser tratados na unmerging
• Histórico -- O histórico do ticket ainda existe e você pode visualizá-lo diretamente, sem novas alterações de software
• Visualização Aberta/Resolvida/Fechada -- como os tickets filho são, do ponto de vista do usuário, mesclados, os tickets filho não são listados nessas visualizações.

Para implementar o Merge dessa maneira não destrutiva, vejo três grandes mudanças e uma pequena adição de recurso/função:

• Tabela de relacionamentos. Vincula um ticket a outro ticket com um tipo de relacionamento.
• Modifique a visualização Aberta/Resolvida/Fechada de tickets. Exclua os ingressos que são filhos.
• Modificar o ticket de visualização. Mesclar a correspondência dos bilhetes Pais e Filhos, em tempo real -- por exemplo, selecione * da correspondência onde bilhete em (bilheteA, bilheteB) ordene por receiveDate desc. E ao visualizar um ticket filho, deixe claro que ele está ativamente rotulado como filho e é somente leitura e você não pode responder a ele. Adicione um link ao ticket mestre.
• Novo código: Mesclar adiciona o relacionamento e copia (caixa de seleção opcional ou, melhor ainda, uma caixa de seleção múltipla com todas as informações do cliente e do colaborador) cliente e colaboradores como colaboradores no ticket mestre.

Isso simplifica muito a mesclagem, permite que você não modifique grandes trechos de código para lidar com tickets "mesclados", deixa um rastro de histórico para que você possa investigar quando um ticket foi "mesclado" ou "não mesclado" e é quase completamente não destrutivo (a modificação no bilhete Master dos colaboradores pode ser interpretada como destrutiva; acho que não, mas não quero desconsiderar esse ponto de vista).

@ Hannibal226 e parece que concordamos na maioria dos pontos. Eu não acho que o(s) ticket(s) filho(s) mesclado(s) deve(m) ser fechado(s) - acho que quando o status principal muda, o status filho muda e vice-versa.

Por exemplo, se o tíquete mestre for "Resolvido" e um cliente com o tíquete filho responder por e-mail, o tíquete filho deverá voltar para "Aberto" e, portanto, o mestre e todos os outros tíquetes filhos também deverão voltar para "Aberto".

Se você fechar todos os tickets filho como "Mesclados", terá que modificar mais fortemente a lógica de lidar com novos e-mails recebidos. O ticket está com o status "Mesclado?" Você ainda adiciona a correspondência ao bilhete filho original? Ou agora você modifica o Master (o que eu acho que poderia levar a uma bagunça gigante se a mesclagem foi um erro cometido ontem à noite, o(s) cliente(s) respondeu(m) três vezes diferentes, então eu fui desmembra-los - e agora o cliente Uma correspondência está no ticket do cliente B.

@ooglek

Então, do seu jeito, você quer abrir o Ticket A, B e o "master" C até um e-mail entrando no ticket A.

Mas sem saber o código, eu diria isso pelo menos no difícil/fácil quando o correio entra em A, que é mesclado de C.
O que significa que apenas C muda para online.
Portanto, aqui apenas uma rotina é necessária (sinalizador ou via tabela de relacionamentos [como não mencionado]).

A sensação de fusão está limpando. Portanto, abrir tickets, que também foram mesclados, é desnecessário como mantê-los abertos, quando mesclados. (Na minha opinião)
Portanto, o ticket A e B apenas se tornam invisíveis/substituídos (para todos os usuários e colaboradores) assim que são mesclados, para que possam ser fechados (terminar/esquecer).
Na maioria dos casos, você nunca mais precisa deles, então por que manter o status mudando?
Apenas em alguns casos você pode querer verificar algo, então você pode ir até ele através de links e na última opção para desfazer a mesclagem.

Então eu vejo nossos acordos em:

• Sem fechamento de ticket
• Os problemas não são mesclados, mas a mesclagem pode lidar com problemas (pelo menos eu entendo você assim)
• Função Mesclar/Descombinar
• Mesclar principalmente UI apenas menos DB

mas nossas visões diferentes reais talvez em:

• child - master (porque mais DB do que UI na minha opinião)
• status alterado em todos os tickets, e não apenas no "mestre"

FELICIDADES!

@ Hannibal226

Meu cenário funciona assim:

• Emails do cliente A, cria Ticket A
• E-mails do cliente A, mesmo endereço de e-mail, cria o Ticket B
• Emails do cliente A, endereço de email diferente, cria Ticket C

O Usuário/Agente OST decide usar o Ticket A como o "Mestre" e mesclar o Ticket B e o Ticket C com o Ticket A.

• OST Cria um relacionamento vinculado, o Ticket B é filho do Ticket A
• OST Cria um relacionamento vinculado, o Ticket C é filho do Ticket A
• Como há dois e-mails diferentes nesses três tickets, o usuário/agente OST decide mesclar outros usuários além do mestre como colaboradores; O e-mail do cliente A B se torna um colaborador no Ticket A

E agora terminamos.

Se o Cliente A enviar um e-mail para o Ticket C, essa correspondência será adicionada ao Ticket C, exatamente como está agora. Se essa correspondência acionar uma mudança de estado (Resolvido -> Aberto), o estado do Ticket C muda, como acontece agora, mas também altera o estado do Ticket A e do Ticket B para corresponder.

Se o Cliente A enviar um e-mail para o Ticket B, a mesma coisa acontece.

Se o Cliente A enviar um e-mail para o Ticket A, a mesma coisa acontece.

Quando o usuário/agente OST carrega o ticket A (Ticket mestre mesclado), ele vê toda a correspondência do ticket A, B e C, em linha. Podemos ou podemos optar por não mostrar que eles são do ticket mesclado na Visualização de tickets.

Quando o usuário/agente OST carrega o ticket B ou C, ele vê um aviso de que este é um ticket filho vinculado, com um link de URL para o ticket mestre, e que tudo aqui é somente leitura, e as respostas devem ser feitas no mestre Bilhete.

Eu não estou realmente certo do que você quer dizer no seu 2º parágrafo. Você pode reformular?

Parágrafo 3: Ainda discordo que os Tickets Criança (na sua nota, Ticket A e Ticket B) devam ser fechados. O que acontece quando um cliente responde a esse ticket filho? Agora você precisa modificar como lidar com tickets que estão em um novo estado (Closed Merged) ou em um estado mais status de relacionamento (Closed + Child) e adicionar lógica para alterar o estado do Master. E se o status for Fechado, a correspondência não deve ser adicionada a esse ticket, mas ao Master. Mas quando você faz isso, você perde a capacidade de unmerge porque agora a Correspondência que veio destinada ao Ticket A (filho) é escrita no DB para o Ticket C (master) e se você un-merge, como você puxa a correspondência Bilhete C (mestre) destinado ao Bilhete A (filho) de volta ao Bilhete A?

Acredito que os clientes mantêm os tickets por um longo tempo -- recebi e-mails de clientes de volta sobre tickets abertos há 2 anos -- e quero ter certeza de que esses tickets sejam resolvidos.

Vejo nosso acordo aqui como:

• Sem fechamento de ticket
• Ofereça uma funcionalidade de mesclagem e desunião
• A mesclagem é principalmente apenas alterações de interface do usuário, alterações mínimas de banco de dados e minimizar alterações de código e processo

E discordamos em:

• Como implementar a relação filho-mestre
  ** eu: Apenas uma tabela de relacionamentos
  ** vocês: ??
• questões
  ** me: Problemas é um recurso separado mencionado neste tópico, mas o IMO não está relacionado à implementação de recursos de mesclagem
  ** vocês: ??
• Estado dos Bilhetes Master e Child
  ** eu: acredito que o estado do ticket mestre e filho deve permanecer em sincronia, para que os clientes possam responder a qualquer um dos tickets, e que a correspondência vá para o ticket pretendido pelo cliente, para que durante um Unmerge haja consistência e nenhuma mistura de respostas não intencionais
  ** vocês: ??

Estou ansioso para você compartilhar seus pensamentos sobre onde diferemos.

Existe um grupo mestre de desenvolvedores OST? Algum tipo de processo?

@ooglek

• Como implementar o relacionamento filho-mestre ** me: Apenas uma tabela de relacionamento ** você: ??
• Estado dos tíquetes mestre e filho ** eu: acredito que o estado do tíquete mestre e filho deve permanecer em sincronia, para que os clientes possam responder a qualquer um dos tíquetes, e essa correspondência vá para o tíquete pretendido pelo cliente, para que durante um unmerge haja é consistência e nenhuma mistura de respostas não intencionais ** você: ??
  
  
  
  • Em primeiro lugar, nos aproximamos da relação "mestre-filho" e da tabela de relações.
  
  
  • Portanto, concordo aqui, MAS não com o gerenciamento de status por meio de vários tickets.
    
    Reabrir as alterações de status deve ter efeito apenas no "mestre" (no seu exemplo A) - na minha opinião.
  
  
  • Toda comunicação deve ser apenas "redirecionada" para o mestre, desde que seja mesclada. Porque por que você deve usar merge, quando você quer adicionar algo ao ticket B ou C depois? [portanto, desmembrar]
  
  
• Problemas ** eu: Problemas é um recurso separado mencionado neste tópico, mas o IMO não está relacionado à implementação de recursos de mesclagem ** você: ??
  
  
  
  • Porque Questões: Você está certo e podemos discutir isso em outro momento :P
    
    Eu acho que apenas um tratamento de status diferente (separado do mestre) e a criação de novos tickets poderiam trazer um recurso de problema, sem "redesign/-implementar" completamente as coisas aqui.
  
  

Estou feliz com o interesse e movimento neste 'request-request' ;)

FELICIDADES!

@ Hannibal226

• Relacionamento -- acordado
• Estado dos tíquetes -- A razão pela qual estou sugerindo que mantenhamos o estado em sincronia com o Mestre e o Filho é devido ao caso em que um e-mail chega destinado ao Filho.
  
  
  
  • Se "fecharmos" os tickets das crianças, o que fazemos com esse novo e-mail? Se o adicionarmos à correspondência do Mestre, não poderemos "Desfazer a mesclagem" de forma limpa. Se o adicionarmos à correspondência do Child para permitir um unmerge seguro, agora temos que desfazer o código de mudança de status existente que tornaria o Child "open" mas agora temos que suprimir isso e apenas alterar o Master para "open ". Essas são algumas mudanças fundamentais.
  
  
  • Se mantivermos o filho/mestre em sincronia, o novo email entrará no ticket filho, o status do filho será atualizado e isso (código adicional, não modificando o código existente) acionará uma atualização de status nos outros tickets filho e mestre. É um pedaço de código adicionado, não uma mudança lógica no código de tratamento de novos e-mails.
  
  
  • Eu acho que o último é mais limpo, mantendo a lógica como está e simplesmente adicionando uma etapa extra para os tickets que fazem parte da tabela de relacionamentos mencionada anteriormente.
  
  
• Questões -- Nós concordamos! :-)

@greezybacon Adoraria ouvir seus pensamentos. E essa é uma daquelas coisas que você gostaria que eu fizesse um fork, modificasse e então enviasse uma pull request? Ou você quer implementar?

@ooglek

• Estado do Bilhete
  
  
  
  • Touché. Esqueci a opção de unmerge, que com certeza será mais fácil e estruturada, se os e-mails entrarem nele diretamente enquanto são mesclados.
  
  

Bom ver que estamos nos reunindo aqui :P

FELICIDADES ;)

A interface do usuário de mesclagem pode acompanhar o recurso de encadeamento recolhível aqui:#2699

Acho que deveríamos ter um ícone na lista de tickets indicando se um ticket tem tickets mesclados. Em seguida, os agentes saberão se podem desfazer a mesclagem da lista de tickets ou da visualização real do ticket.

É necessário que haja um evento de sistema da mesclagem e quando ocorreu na visualização do ticket. Os tíquetes que estão sendo mesclados precisam ter um indicador de cor separado mostrando que são os tíquetes mesclados dentro do encadeamento. como as cores das mensagens e notas.

Na parte inferior da caixa de diálogo de resposta, ele pode listar os endereços de e-mail de todos os tickets mesclados e o agente pode removê-los manualmente ao responder. Ou use um menu suspenso no botão de envio para escolher "Responder a todos" ou "Responder tíquete dos pais". Responder a todos pode preencher automaticamente os endereços dos remetentes com a opção de remover manualmente. Estou pensando alto aqui.

Na mesclagem real após os tickets serem verificados e a mesclagem é selecionada, um modal com opções sobre qual ticket é pai? Quais endereços de e-mail manter para enviar respostas? Opções para fechar, reivindicar ou transferir tickets após a realização de uma mesclagem devem estar disponíveis. Possivelmente uma opção para anexar a mesclagem ou embaralhar a mesclagem por data? Vou pensar em outras coisas depois. Isso é puramente UI pensando que vou deixar vocês discutirem o back-end, vou tentar acompanhar. :sorriso:

+1

+1

Olá,

Alguma notícia sobre esse recurso desejado?

+1

+1

Eu já fiz isso para a minha versão (v1.9.12). A função como abaixo:

• Usuário (convidado) Foo usa o email [email protected] para enviar ao sistema, ele cria o ticket X-1234.
• O usuário Foo esquece o email que ele usa para o ticket X-1234, então ele usa o email [email protected] para enviar para o sistema. Agora o assunto do email é novo e não tem o número do ticket. Sistema cria ticket X-2345.
• A equipe (agente) abrirá o ticket X-1234, escolha Mesclar tickets. A forma do ticket X-1234 e seus threads serão mantidos. Os threads do X-2345 serão mesclados no X-1234. Os detalhes dos formulários do X-2345 permanecerão para verificação adicional.

@cosmospham que soa exatamente como o que eu precisaria. você tem uma filial ou alguma maneira de baixar seu código?

@snizzleorg Desculpe porque este é um repositório privado. Portanto, só posso capturar as alterações do commit para você. Veja as alterações em 03 arquivos de captura de tela https://github.com/cosmospham/test-0

Em primeiro lugar, adicione um menu.
Em segundo lugar, adicione uma regra de rota.
Em seguida, crie uma caixa de diálogo ajax.
Em seguida, escreva a função de mesclagem.
Aviso: Apenas atualize a página após a mesclagem.

Acho que você pode entendê-los.

Minha empresa atualmente usa o recurso de mesclagem de tickets para os seguintes cenários:

1. Temos alertas de monitoramento para nosso sistema de tickets. Digamos que recebemos um alerta de que o firewall caiu. Em seguida, recebemos um tíquete 30 minutos depois de que o firewall está de volta. O que fazemos então é mesclar os dois tickets e fechá-lo. Quando a mesclagem acontece, ela mescla os dois tickets e o ticket que foi criado primeiro permanece como o ticket e o novo ticket que chegou, passa a fazer parte do histórico do ticket.
2. E-mails de usuários sobre um problema. Em seguida, os e-mails novamente sobre o mesmo problema, mas como não enviaram o e-mail com o número do ticket no assunto, o sistema cria outro ticket para o mesmo problema aberto pelo mesmo usuário. Mesclar os dois tickets junto com o primeiro ticket, mantendo o ticket visível e o segundo ticket aberto, torna-se parte do histórico do ticket.

Ser capaz de combinar um monte de tickets relacionados em um "problema" pai é uma ótima ideia, mas acho que deve ser separado (como outras pessoas pensam) do recurso de mesclagem.

+1

+1, esse recurso seria muito valioso para nós. Uma parte muito importante de nossos usuários responde às notificações de e-mail do osticket usando um cliente de e-mail que não respeita os cabeçalhos esperados pelo osticket

Esta é uma grande demanda para ter o recurso de mesclar tickets desde 2009, as pessoas discutem no fórum osticket.
E também verifico se há alguma atualização de tempos em tempos, mas, infelizmente, só há espera de novo e de novo.

Por que esse recurso é tão importante (dentro da empresa)?

• Se um dos serviços estiver inativo e 10 usuários enviarem feedback para você sobre o mesmo problema, 10 tickets serão criados.

• Se o provedor de serviços ou fornecedor resolver um problema para você e você desejar anexar como um documento de tíquete de fechamento, não será possível encaminhar a mensagem para osticket e mesclar o tíquete existente. Você precisa copiar o conteúdo ou salvar como pdf para fazer o upload. Mas que tal uma mensagem que seu provedor de serviços anexa com muitos anexos? Você terá muitos trabalhos manuais para fazer.

• Um usuário cria um novo ticket de feedback de algum problema do sistema, mas na verdade já fornecemos a solução há um ano. Por que precisa mesclar o ticket antigo com este novo? Porque lidar com funcionários de escritório você precisará refrescar sua memória, deixe-os saber que eles repetem a mesma pergunta.

+1

+1

+1

+1

Por trabalhar em MSPs, entendo como isso prejudicaria sua produtividade, pois você teria que trabalhar em cada ticket individualmente. Seria um ótimo complemento!!!

+1

+1

+1

Adoraríamos mudar nosso sistema de tickets internamente (para longe do Zendesk). A capacidade de mesclar/dividir tickets são fatores-chave em nossa decisão. Não é incomum receber mais de 20 ingressos de várias fontes (vendas, revendedores, vendedores, transportadores, sistemas automatizados, respostas de clientes, etc. etc.). A ideia de juntar tudo isso manualmente não passaria de um pesadelo.

Estaríamos dispostos a contribuir financeiramente com alguns dólares para ajudar a dar andamento ao processo. Não tenho ideia de quanto isso pode custar, mas ficaria feliz em configurar uma página do GoFundMe. Parece que temos "+1" suficiente aqui para que alguns dólares de todos financiem o tempo de desenvolvimento e nos economizem uma fortuna em nossa hospedagem Zendesk.

+1 para a versão 1.10

+1

+1

Alguma notícia se isso vai acontecer?

+1
Isso é tão necessário que posso até contribuir com código para que isso aconteça

Devo observar que já implementamos esse recurso usando links de tickets e o código foi postado online aqui:

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

Incluímos um link para um desenvolvedor que pode implementá-lo para você, caso não se sinta à vontade para fazê-lo por conta própria.

Parece que algo aconteceu.... #3768
Obrigado por compartilhar o trabalho @Micke1101

Fico feliz em ver que há algum trabalho sendo feito sobre isso. +1

@Micke1101 Muito bem nessa solicitação de pull! Espero que seja incorporado ao núcleo em breve! +1

3768 Precisa de mais visibilidade.

Alguma novidade neste tópico?

Então, acho que 2020?

Queremos mesclar tickets também no osTicket 0.12.2! Vote nesta funcionalidade :)
Não importa se é construído como plugin ou no núcleo.
Obrigada!

@antiuser

O recurso oficial do Ticket Merge está localizado no link abaixo. Siga esse tópico para se manter atualizado:

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

Felicidades.