si, estoy contigo 100%
Este es mi sueño también. una función de combinación sea genial!
Debido a que a menudo los clientes comienzan un nuevo correo electrónico y no responden con el número de ticket... entonces sería genial "combinar" esta respuesta con un ticket existente.

Sí.
Incluso el problema es que no hay un "enlace de boleto público" que pueda agregarse.
Entonces, incluso esto ayudaría si puede cerrar un ticket y decir "Ver número de ticket: # 12345",
que vinculará un personal Y un usuario al ticket.
Esto podría ser, por un lado, ayuda si la fusión no es posible, por otro lado, si tiene boletos,
que siguiendo a otro, puedes crear una especie de "camino lógico".

Pero veamos qué piensan los desarrolladores sobre esto;)

¡SALUD!

Me gusta la idea del enlace automático (ver #12345683)

@grezybacon

¿Debería abrir otro hilo para esto?

Entonces, la idea detrás de esto es "solo" presionar un botón y puede escribir un número de boleto (o seleccionar, pero esto es pesado).
Después de esto, se agregará un enlace al ticket.

Nuevamente, el problema no es agregar el enlace en sí, es que solo el personal O un usuario puede ver esto.
Como dije, el seguimiento de los problemas y cambios que haces sería genial para manejar de principio a fin, sin buscar.

Pero tampoco puede, por ejemplo, crear un enlace a un ticket en la base de conocimientos, lo que tal vez también podría explicar algo mejor.

Me gustaría agregar mi apoyo a esta solicitud de función. Mis usuarios son muy buenos para enviar varios correos electrónicos sobre el mismo problema sin incluir el número de ticket, y rápidamente pierdo la pista de toda la información necesaria para resolver el problema.

¡Combinar entradas sería genial! Incluso si es simplemente ingresando un número de boleto.

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

Por favor busque antes de enviar un nuevo problema!

Bueno, en general es citar lo mismo.
Pero, por otro lado, se separa con mi explicación, ya que un enlace automático es otra característica que fusionar boletos.

Así que no tengo idea de cómo manejar esto ahora.

En mi opinión, el primer paso "más fácil" sería agregar una opción para vincular a un ticket que pueda ser visto por el personal y/o el usuario.
Entonces puedes crear una especie de proceso/historia cuando intentas encontrar soluciones o entender algo.

Pero sería genial en el futuro tener una especie de "boleto principal" al que solo se puedan agregar boletos nuevos/iguales/dobles.
Para que obtenga un ticket y vea todas las soluciones diferentes, las formas de los usuarios en una lista de tickets que se fusionaron.

Esa es mi idea de esto, pero no sé si alguien puede entender y ver esto tan sensato como yo lo veo.

SALUD

Referenciar / Vincular es la sugerencia original de @greezybacon en la que están trabajando y se llama 'Problemas'. Agrupar boletos similares tiene mucho sentido, pero es diferente a fusionarlos. Con una combinación, solo tiene que 'mover' todas las entradas de boletos al nuevo boleto, vincular/agrupar requeriría una nueva tabla.
Así que sí, es más o menos lo mismo de lo que estás hablando @ Hannibal226

Voy a programar esto en los próximos días/semanas. y publicarlo como solicitud de extracción.

Creo que no es tan difícil "combinar tickets" si los mensajes están ordenados por tiempo. y en la mayoría de los casos, si fusiona un ticket, solo tiene "un" mensaje. Porque tal vez sea un nuevo ticket que el usuario final respondió incorrectamente/escribió un nuevo correo electrónico y no usó el botón de respuesta.

mi idea es:

• tiene un botón "Combinar con otro ticket".
• si lo presiona, se abre una ventana emergente y escribe/busca el ticket donde desea fusionar este ticket.
• de lo que se le ha pedido que agregue al remitente como colaborador (si no es el mismo correo electrónico que el del propietario)
• de lo que se le ha pedido que cierre el "nuevo ticket" al final o lo elimine.
  si lo cierra, se agrega una nota con toda la información como:
  quién lo envió (correo electrónico/nombre) hora/fecha y número de ticket del ticket cerrado
  O
  quién lo envió (correo electrónico/nombre) hora/fecha

final.
Creo que es una función realmente necesaria. A menudo tengo clientes que escriben un nuevo correo electrónico y no usan el botón de respuesta. entonces cierro manualmente el nuevo boleto y agrego el número del boleto al "boleto principal". Pero esto no es tan bueno si necesita cambiar de un boleto a otro para comprender qué sucede.

@ mrsaw12 , ¿puedo sugerir que intente implementarlo como un complemento?

@Mrsaw12

Esto suena gr8 y realmente me gustaría probarlo;)
Y como dijiste, no es tan complicado en absoluto, pero de todos modos no estoy muy interesado en PHP y MySQL, por lo que es difícil para mí.

Mucho éxito y avísanos cuando esté listo ;)

¡Salud Amigo!

@kordianbruck

Así que de todos modos no estoy seguro.
Son dos formas si obtienes de un ticket que dice que debe fusionarse y/o vincularse a cualquier cosa O eliges varios tickets y los agrupas.

Una vez más, esto es demasiado profundo y falta alguna de estas funciones y estoy feliz de que tengamos gente tan activa como @ mrsaw12 que está dedicando un poco de tiempo a ayudar rápidamente aquí.

Seguro que los desarrolladores principales como @greezybacon o todos los muchachos a su lado están haciendo más que suficiente y esto no debería significar una presión o algo así.

De todos modos, gracias por pensar juntos y tal vez con una solución, ambas partes están felices con el resultado, para que podamos decir "sí, es lo mismo";)

SALUD

En los próximos meses agregaremos la posibilidad de que un ticket tenga varios subprocesos (a través de "tareas"). Sería interesante ver si eso ayudaría en la fusión de tickets.

@greezybacon Genial, ¡es bueno escucharlo!

¡Hola! Me pregunto si hay alguna actualización de esta mejora. muy necesitado ¡Gracias!

+1

@greezybacon ¡Es bueno escucharlo y gracias!

también buscando una actualización sobre esto. Combinar tickets es esencial para nuestro flujo de trabajo, gracias.

Hola tios,

He usado muchos sistemas de emisión de boletos y todos se fusionan a través de la misma metodología básica (Ceberus, Zendesk, RT, etc.)

Me encantaría ver una combinación en osTicket consistente con lo que ofrecen la mayoría de los otros sistemas de emisión de boletos.

1) Permita que el agente seleccione varios boletos desde cualquier vista (lista de resultados de búsqueda, lista de mis boletos, otras listas) y presione el botón COMBINAR.

2) Una vez que se presiona el botón COMBINAR

• TODOS los datos se fusionan en un hilo de ticket, ordenados por fecha
• El número de billete MÁS ANTIGUO es el número de billete del billete fusionado
• TODOS los colaboradores y agentes están en el nuevo ticket

Es una fusión: tomas todo y lo pones en una cosa que está representada por la cosa ORIGINAL (la más antigua).

La fusión y la reducción de duplicados son las características más críticas en un entorno de gran volumen para reducir el trabajo sin sentido e innecesario en la emisión de boletos. Son, en mi humilde opinión, enormes agujeros de características en osTicket.

+1 ricobodo

+1 !!!

a pesar de muchas solicitudes para una función de combinación, ¿no hay progreso?

:( ¿llevará mucho tiempo? Merge ticket es muy útil.

La combinación no es particularmente importante para hacer, ya que hay características/funcionalidades más importantes por encima de ella.
No esperaría una función de combinación por un tiempo.

Triste por eso :) pero puedo entender que tienes mucho trabajo.
En estos días, había usado muchas funciones de combinación en otros tickets de código abierto, así que... realmente se echa de menos en OsTicket.

Bueno, espero ver este proyecto Merge no olvidado.

Para mí, OsTicket tiene cosas para implementar/arreglar:

• Boletos combinados (este número)
• Edición de tema en el ticket (ya está hecho y se lanzará pronto, ¡excelente!) https://github.com/osTicket/osTicket-1.8/issues/1173
• Corrija la hora incorrecta en la página de registro de usuario https://github.com/osTicket/osTicket-1.8/issues/1842
• Soluciona un error en el enlace del ticket https://github.com/osTicket/osTicket-1.8/issues/2024
• Tal vez un tema receptivo https://github.com/osTicket/osTicket-1.8/issues/2030
• Boleto de cierre automático en ciertas estatuas https://github.com/osTicket/osTicket-1.8/issues/2036
  Y OsTicket será el mejor código abierto

Mucha gente está siguiendo esto :-) Combinar boletos, ¡genial!

¡Esperando la fusión con ansiosa anticipación!

Estoy agregando el código yo mismo por ahora, así que no actualizaré más allá de 1.9.4 hasta que Merge sea una de las características agregadas.

Si existe un código estable para combinar boletos, ¿por qué no agregarlo a la rama principal?
Parece que hay una demanda para ello...
¡La fusión sería una gran mejora para nosotros!

Sí, fusionar tickets muy llenos de usuarios.

Inviato a dispositivo móvil. | Enviado por dispositivo móvil
Il 13/Mar/2015 07:03, "Eddie-BS" [email protected] ha escrito:

Si existe un código estable para fusionar tickets, ¿por qué no agregarlo a la principal?
rama ?
Parece que hay una demanda para ello...
¡La fusión sería una gran mejora para nosotros!

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/osTicket/osTicket-1.8/issues/1225#issuecomment-101513518
.

La fusión de tickets sería un gran beneficio para nosotros, ya que nos hemos encontrado muchas veces con el caso de que un usuario ha creado tickets con dos direcciones de correo electrónico y queremos fusionarlos todos en una sola cuenta y actualmente tiene que hacerse uno a la vez. usando el propietario del cambio (o tiene que escribir una consulta para hacerlo desde el back-end, pero eso siempre es peligroso porque puede perder algo que el software normalmente habría manejado).

El usuario también fusionará el mismo ticket de usuario pero un ticket diferente, por lo que si el usuario A crea dos tickets diferentes, la capacidad de fusionarse en uno.

+1 para esto también. Realmente deseo que OSTicket tenga esta función algún día.

+1 para esta función, sería perfecto si esto fuera posible

+1

Imagínese si Github no tuviera una función de combinación...

+1

Fusionar tickets sería una adición muy útil. Me encanta cómo van las cosas con 1.10rc1, pero ha habido tantos cambios en el código que los viejos ajustes de combinación no son tan fáciles de implementar. Desearía ser más experto en PHP.

+1

+1 ¡Es muy necesario!

La característica de internacionalización asombrosamente detallada implementada en 1.10 está lista y ahora la otra característica que queda es Merging Tickets, que es esencial para los centros de soporte de gran volumen. Espero que esto llame la atención para 1.10 o 1.11 para que osTicket se adelante a otras soluciones.

+1

Sí estoy de acuerdo

+1

¿Qué se necesitaría para que alguien desarrollara esta función y la fusionara con OSTicket?

A pesar del comentario de ntozier de "Fusionar no es particularmente importante, ya que hay características/funcionalidades más importantes por encima. No esperaría una función de Fusión por un tiempo". basándome en la gran cantidad de +1 y tickets abiertos duplicados, diría que la demanda es bastante alta.

He estado escribiendo PHP durante 16 años. Podría escribir un método de combinación. Me gustaría hablar con los desarrolladores principales sobre el esquema de base de datos y sus opiniones sobre la mejor manera de implementar la combinación. O puedo revisar el esquema y sugerir una implementación. Pero antes de hacer nada de eso, me gustaría asegurarme de que mi trabajo pueda llegar a OSTicket Trunk.

¿Es esa una posibilidad?

:+1: para @ooglek

@ooglek
Suena bien y razonable para mí. :)

Desarrolladores, ¿qué opinan?
@protich
@grezybacon
@nfebrero

¡Sí!

:+1:

@ooglek
Genial que muestres esta iniciativa!

Estoy bastante seguro de que @greezybacon también está agradecido, pero seguro que no sé cuáles son sus reglas sobre agregar a alguien a github.
¿Tal vez puedas crear una función de combinación al lado?

Pero tenemos que esperar a los desarrolladores y ver.

Gracias de nuevo.

Re: "pero seguro que no sé cuáles son sus reglas sobre agregar a alguien a github".
Cualquiera puede unirse a github y hacer una solicitud de extracción.
Los desarrolladores revisarán los cambios y los aceptarán o rechazarán.

@ntozier
OK, lo siento, quise decir 'la parte de github de osticket', no github en general, lo siento: P

Pero parece que es posible para @ooglek entonces;)

Esto es definitivamente algo que me encantaría ver agregado a osticket. Esta característica definitivamente me ayudaría a vender esto a la gerencia al adoptar esto sobre otro sistema de emisión de boletos que estamos usando.

+1

Arrojando mi propio +1 a la mezcla.

Estamos buscando migrar lejos de otra solución de emisión de boletos, y la fusión es esencial. Recibimos muchos boletos nuevos que deberían ser respuestas a los existentes, y dado que necesitamos realizar un seguimiento preciso del uso de los boletos, terminamos fusionándonos mucho.

He estado pensando en esto durante los últimos días. Trabajaré en la interfaz de usuario, y hablé con @greezybacon y él también mencionó poner algo de energía en él (su horario es un poco loco, así que tenlo en cuenta) @ooglek cualquier ayuda es bienvenida, tú y yo podemos discutir la interfaz de usuario y puede discutir el backend con @greezybacon. Creo que podemos hacer que esto funcione. ah y +1

¿Podría alguien quizás armar un RFC más formal sobre el proceso de fusión para que podamos considerar los problemas con el proceso de fusión y elaborar algunas definiciones sobre cómo lograr esto en osTicket? Creo que algunas de las cuestiones planteadas hasta ahora:

• ¿Cómo se fusionan los hilos? Son los elementos de los billetes dispares:
  
  
  
  • entrelazados en orden cronológico
  
  
  • El hilo de los tickets contraídos se agrega al final del hilo del ticket fusionado
  
  
  • Subprocesos separados que se muestran en la interfaz de usuario a través de pestañas separadas
  
  
  • No se realiza ninguna fusión de subprocesos. En su lugar, los tickets se cierran y se agregan enlaces de "ticket relacionado" al ticket fusionado
  
  
• ¿Cómo se fusionan los metadatos? Específicamente
  
  
  
  • La fecha de vencimiento
  
  
  • Asignados (personal y equipo), así como departamento enrutado
  
  
  • Datos personalizados y formularios agregados a los respectivos boletos
  
  
• ¿Cuál es el proceso de fusión?
  
  
  
  • Acción de selección múltiple de la cola de listado de boletos
  
  
  • Acción del menú desplegable más en la vista de ticket
  
  

Podría intentar escribir algo, pero no tengo un caso de uso sólido para la función, por lo que creo que otros probablemente tendrán mejores sentimientos y orientación sobre cómo deberían funcionar las cosas.

Algo ocupado en este momento, pero mis pensamientos inmediatos son:

• Elección caso por caso de fusión cronológica o adición de hilos
• Decisiones por artículo para fecha de vencimiento, cesionarios, etc.
• Acción del menú desplegable "Más"

Nuestro problema actual (y esto podría mitigarse un poco al tener un portal en lugar de solo correo electrónico) es que un usuario abrirá un ticket, no recibirá una respuesta dentro de unas pocas horas (es posible que haya abierto un ticket fuera de nuestro horario de oficina o podríamos estar de vacaciones) y luego abrir otro preguntando si obtuvimos el primero. O tenemos que cerrar uno que deshaga nuestra contabilidad, o fusionarnos.

El otro caso es cuando las personas abren un ticket y luego envían más información en un correo electrónico separado que, debido a una línea de asunto diferente, se registrará como un nuevo ticket. Esto también se mitigaría potencialmente mediante el uso del portal, pero queremos conservar la capacidad de permitir tickets basados ​​en correo electrónico.

@grezybacon
Creo que primero sería bueno ver dos opciones:

1)
Desde el Ticket A y el Ticket B para fusionarse (como nota vinculada) al Ticket C.
Con este paso, automáticamente se debe enviar una información sobre la fusión al usuario y
cerrar A y B.

• Es decir, ahora, cuando ve debajo de 'abrir' el Ticket C, puede ver más antiguo o
  más opciones simplemente yendo a los vinculados.

2)
Del boleto A y el boleto B se fusionan en un NUEVO boleto C.
Mismas funciones que las anteriores, pero el Ticket C se creará nuevo con implement
los existentes.

En mi opinión, esto es lo más importante para mantener limpio el sistema de tickets.

DESPUÉS, una opción para alternar el boleto A o el boleto B directamente en el boleto
C estaría bien, pero creo que esto necesita algo de tiempo (temática, etc.) y no es
tan importante para el cajero automático de fusión principal.

¡SALUD!

No creo que la combinación de tickets deba dar como resultado la creación de un nuevo ticket.

No daré nombres, pero la forma en que funciona nuestra solución actual es que usted elige el ID del ticket con el que desea fusionarse, luego el otro tiene todo su contenido reemplazado por un mensaje que dice "El ID del ticket XXX tiene se ha fusionado con ID YYY". Esto conserva el hecho de que se realizó una fusión sin crear un nuevo ticket. Sin embargo, dado que facturamos en función del uso de boletos, todavía quedan dos boletos cuando en realidad debería haber solo uno.

Por lo tanto, es importante mantener un registro de lo que sucedió, pero también es importante hacerlo de una manera limpia e intuitiva.

Una forma en que OTRS lo hizo fue "vincular" los boletos. Por ejemplo, un ticket se consideraría "el maestro" y otros tickets se fusionarían con él.

En la pantalla, toda la correspondencia se "sindicalizaría" y se mostraría cronológicamente, independientemente de los tickets vinculados de los que proviniera la correspondencia.

Esto permite una relación padre-hijo. También puede "vincular" los boletos de tal manera que estén relacionados, pero aún así sean dos boletos separados.

Los boletos que se consideraban niños no aparecían en la pantalla o conteo "Abierto/Cerrado/Resuelto".

Estoy de acuerdo con @greezybacon en que la fusión NO debería crear un nuevo ticket.

En mi opinión, una vez creados los tickets, no se deben modificar en la estructura de la base de datos, sino usar un software para "fusionarlos". De esta manera, es posible "deshacer la fusión", aunque la nueva correspondencia solo se agregaría al boleto "maestro", incluso si el boleto antiguo recibió nueva correspondencia. Aunque eso no es realmente necesario, pero creo que sería más limpio "congelar" los boletos secundarios cuando están vinculados a un padre/maestro.

No de primera manera, correcto.

Pero a menudo necesitas esta opción mientras limpias las entradas.
Así que reconociste nuevas cosas, actualizaciones o conexiones.

Ahora puede agregarlo a un ticket existente, pero no sabe a cuál o crea primero uno nuevo y luego los fusiona.

¿Por qué no hay opción para fusionar directamente a nuevo?

De nuevo, entiendo que la "combinación" en la primera forma significa juntar las cosas, pero en la última opción puede crear un nuevo ticket para hacer exactamente esto.

PD: Solo mis dos centavos en esto seguro: P

SALUD

@Hannibal226 -- Creación de un nuevo ticket -- ¿cómo responde un cliente al ticket anterior? ¿Cómo se maneja eso? Al menos manteniendo la misma estructura de datos y creando un enlace entre dos tickets, un cliente puede responder a cualquiera de los tickets, y el código de manejo de respuesta no necesita cambiar, puede entrar en cualquiera de los tickets (sí, este no es lo que sugerí con congelar el boleto del niño, estoy descartando opciones). Todo lo que necesita hacer cuando saca un boleto es:

• ¿Este billete tiene niños? Si es así, obtenga todas las respuestas de ese ticket y combínelas con este ticket para mostrarlas.
• ¿Este boleto tiene un padre? Si es así, redirija y muestre el padre en lugar del hijo
• En el recuento y visualización de tickets "abiertos/cerrados/resueltos", ignore y no cuente los tickets que están vinculados como secundarios a otro ticket principal/maestro.

Las modificaciones son mucho más simples, porque no tienes que cambiar la lógica para manejar una respuesta entrante... mucho. Solo pensé en algunas cosas.

• Cambios de estado: ¿Cerrar el maestro cierra el niño o los niños? ¿O se ignora el estado del niño/niños?
• Una respuesta del cliente al Boleto Niño debería reabrir el Boleto Maestro.
• ¿Debe sincronizarse el estado entre maestro/hijo?

Creo que mantener la estructura del sistema existente lo más similar posible, solo agregar complejidad donde sea absolutamente necesario y no copiar datos ni ejecutar actualizaciones en las identificaciones, servirá mejor y probablemente reducirá el desafío de hacer que funcione.

Personalmente, me gusta la idea de los boletos "vinculados" y pienso en una fusión más como un "grupo de boletos". Entonces, cuando el usuario Alice, Bob y Charlie informan el mismo problema, estos tickets se vinculan entre sí y un agente puede (piense en la función "responder" del correo electrónico frente a "responder a todos") y luego actualizar, responder, etc. usuarios (Alice Bob Charlie) a través de esos boletos vinculados/combinados o a un solo usuario (Bob).

Creo que si se hace de esa manera con tickets vinculados, la parte más difícil es hacer que la interfaz de usuario sea tan intuitiva que sea fácil y claramente comprensible, ya sea que usted, como agente, actualice/responda/etc. a un "grupo de tickets" (cómo llamaría yo esto) o a un billete sencillo.

Desde la perspectiva del usuario final, creo que tendría sentido obtener la información de que otros usuarios informaron lo mismo y todos o solo yo (como usuario final único) obtenemos ahora una respuesta del agente basada en sentido y hechos como la importancia de la mensaje de un agente.

La combinación de tickets es realmente difícil de realizar, creo, ya que hay muchas formas de implementar esto y también muchos casos de uso diferentes para los enfoques de combinación de tickets.

Salud,
Miguel

Hemos hablado sobre agregar el concepto de "Problema". Los problemas son como la relación entre los tickets y las tareas. Sin embargo, los tickets están sujetos a problemas como una relación padre/hijo. El caso de uso que he usado a menudo es una interrupción del centro de datos. Es probable que el grupo de TI reciba varias notificaciones de tickets originados en el "problema" de interrupción del centro de datos. Por lo tanto, se podría crear un nuevo problema y todos los boletos podrían asociarse con el problema. Las respuestas al problema se transmiten a los respectivos propietarios de boletos. Cuando se cierra el problema, también se cierran todos los boletos para niños.

Creo que la fusión es algo completamente diferente. A menudo hemos pensado en fusionarnos más como una operación de reemplazo. Al fusionar tickets, todos excepto el último ticket se eliminan efectivamente. Solo se puede acceder a los subprocesos desde el ticket combinado restante. Las respuestas por correo electrónico en v1.10 ya no están asociadas con el ticket; en cambio, están asociados con el hilo. Por lo tanto, si el ticket se elimina cuando se fusiona y el hilo está asociado de alguna manera con el ticket fusionado, las respuestas en los tickets contraídos/eliminados continuarán en el ticket fusionado a través de sus hilos.

@ooglek

Pero, ¿qué tiene de un Boleto C combinado cuando el usuario responde al Boleto A y B?
Creo que con las cosas de "padres/hijos" es más complicado que simplemente tener tickets de enlaces que acaban de cerrarse.

Así que seguro que todos los Usuarios y Colaboradores deben fusionarse en mi opinión...

Para quedarnos en el ejemplo de un nuevo ticket (que no es la función principal de la que estamos hablando), siempre tenemos que avanzar desde un ticket:

Así que ur en el Ticket B y cree un nuevo Ticket C, lo que significa que todos los usuarios y colaboradores se usarán como en B.
Luego, debe fusionar el Ticket A, que solo incluirá a los Colaboradores si aún no existe para C.

SALUD

@Chefkeks No estoy de acuerdo con agrupar boletos desde la perspectiva del usuario. Eso está demasiado cerca de mezclar información potencialmente privada de boletos de clientes separados, y facilitaría que ocurra una contaminación cruzada.

Creo que aquí es donde los problemas serían útiles. Como ejemplo de flujo de trabajo:

Tres organizaciones/usuarios separados informan el mismo error en el proceso de actualización, por lo que creamos un problema como "Error recibido al actualizar" y luego vinculamos esos tickets a ese problema. A continuación, cree una tarea para resolver el error y vincule esa tarea a ese problema y, por asociación, a los tickets.

-lo siento, presioné el botón equivocado en la nueva aplicación-

Estoy muy interesado en esto, sin embargo, parece bastante complejo. mis requisitos (y esos podrían ser solo míos) son mucho más simples.

el cliente a crea un ticket, el cliente b (o el cliente a con una dirección de correo electrónico diferente) escribe sobre este ticket pero no responde en el hilo original. Ahora copio el contenido del correo como una nota interna y agrego la segunda dirección de correo electrónico como colaborador.

Esto funciona, pero el problema es que los archivos adjuntos no se pueden transferir mediante copiar y pegar.
por lo tanto, para mí, sería suficiente combinar o adjuntar un mensaje a un ticket existente.

@snizzleorg
Esto no es más simple a lo que te refieres, lo que haces es más manual: P

Entonces, estamos hablando de hacer un enlace a un boleto completo, estamos hablando de recibir un mensaje de texto fuera del boleto.
Al menos todos necesitamos lo mismo, pero hay varias formas y ahora queda la cuestión de las más prácticas/útiles.

¿O quieres decirme que un botón no sería mejor que copiar y cerrar todo manualmente? :PAGS
(incluso la copia del archivo adjunto sería posible)

SALUD

Ok, bueno, creo que "problemas", como explicó @greezybacon , es lo que tenía en mente con "grupo de boletos".

Con respecto a la perspectiva del usuario final y la seguridad de los datos/información privada de tickets separados, es posible que me haya equivocado un poco.
Mi idea era más como una respuesta normal que se transmite a todos los propietarios de boletos para que todos obtengan la información del agente y también, según la organización a la que pertenecen los propietarios de boletos, lo que otros usuarios han informado. Por lo tanto, mantener los boletos individuales para los usuarios finales, pero con algunas posibilidades para que los agentes manejen más fácilmente los boletos con el mismo problema.

Dicho esto y lea lo que Jared escribió sobre "problemas" y cómo piensa acerca de fusionar boletos como algo completamente diferente, debo admitir que soy más un "fanático" de los "problemas" y siento que puede ser una mejor manera de fusionando o digamos manejando/administrando boletos.

Miguel

@chefkeks

Pero, ¿no cree que se vuelve confuso y complicado (en la codificación) tener un boleto/emisión para el personal, pero separado para los usuarios?

Creo que entonces es mucho más fácil reemplazar los tickets existentes de los usuarios o, mejor dicho, contra uno.
Entonces, esto debería suceder automáticamente, cuando los tickets "antiguos" se cierran y el mismo usuario/colaborador r en el nuevo ticket.

El usuario ahora también puede ver que algo está sucediendo en este caso, que tal vez sea solo una parte, ya que son cosas del segundo boleto (un poco teórico ahora xD)

SALUD

Hay una necesidad de ambos. Existe la necesidad de manejar múltiples solicitudes de un solo usuario que deben consolidarse o "fusionarse". Existe una necesidad separada de consolidar varias solicitudes diferentes juntas que están relacionadas a través de un "problema" común. La agrupación de problemas no implica otorgar a los usuarios acceso a los tickets de los demás. Sin embargo, implica el concepto de "tickets públicos" en los que se puede publicar un problema en el portal del cliente indicando algo como "Somos conscientes de los problemas del centro de datos en este momento..."

Los dos deben convertirse en características separadas. No deben combinarse.

¡Estoy totalmente de acuerdo en eso!

Los dos deben convertirse en características separadas. No deben combinarse.

Entonces, creo que con su última publicación en mente, Jared, debería haber 2 problemas de RFC aquí en github para discutir ambos de forma independiente, pero con una referencia entre sí, por lo que las personas están discutiendo solo la combinación de boletos o problemas/grupos de boletos .

Salud
Miguel

PD: Dado que el equipo de osTicket tiene mucha experiencia en codificación y diseño de interfaz de usuario, no me preocupo porque puede ser demasiado confuso ni para los agentes ni para los usuarios finales.

@grezybacon

Pero, ¿por qué tan "complicado"?

Los usuarios solo pueden acceder a los tickets que tienen permitido.
Entonces, ¿por qué no concluir lo que quieres, ya que los usuarios no pueden acceder, por ejemplo, a un ticket de otro, si no son colaboradores?
Creo que si los privilegios funcionan bien, no tiene que haber una separación de eso.

U incluso podría nombrar el "asunto" - "proyecto" o "tarea" o "grupo", pero la persona x solo puede acceder al boleto principal (combinado) y los boletos internos, en la medida en que sea creador o colaborador de eso.

Tal vez creo que es un poco pequeño en este caso, pero no estoy seguro de si esto se vuelve demasiado grande si comienzan a separarse, ya que tal vez surjan nuevos casos y solicitudes de casos entre ellos, ¿o?

PD: solo estoy pensando en la forma de usuario y casi en la implementación, lo siento si suena tan fácil y no es seguro xD xD

SALUD

"Problema" implica un paradigma completamente nuevo para que los usuarios de OST entiendan y manejen. Como dijo @snizzleorg , cuando el Cliente A envía correos electrónicos y el Cliente B envía correos electrónicos (o el Cliente A envía correos electrónicos desde una dirección diferente), estos son el 90% de mis casos de fusión.

Por un tiempo fue bueno tener un ticket y poder comunicarse con la Persona A sobre un problema, y ​​luego comunicarse con el Proveedor B sobre el mismo problema, pero excluyendo a la Persona A, pero todos aún en el mismo ticket, en OTRS. Pero no necesito eso, solo fue agradable.

Personalmente, realmente no me gusta la idea de que se cree un "Problema" porque le dije al sistema que estos dos tickets son realmente sobre el mismo problema, independientemente de quién esté en el ticket.

Como mencionó @tmcnag , creo que la "contaminación cruzada" es algo que el usuario debe decidir, no la herramienta. En algunos casos, puede que quiera "contaminar de forma cruzada" en su opinión, pero en la mía es una herramienta.

¿Por qué un Boleto A y un Boleto B, donde un cliente envió un correo electrónico una vez, luego volvió a enviar un correo electrónico 5 minutos después para decir "Vaya, no importa" pero no respondió al Boleto A, por qué eso debería convertirse en "un problema" - realmente lo son solo un boleto que el cliente no pasó por el proceso para hacer como un solo boleto. Solo quiero verificar los dos (o tres o cuatro) boletos y "combinarlos" (en mi opinión, vincularlos en caso de que fusione incorrectamente los incorrectos) y tener una sola línea de tiempo unificada de respuestas y conversaciones que me permita administrar todo. en un ticket, como _yo_ pretendía, incluso si el cliente no "hizo lo correcto" al responder al correo electrónico correcto.

Creo que agregar "Problemas" hace que esto sea aún más complejo: el 90 % de los casos serán un cliente al que se le enviará dos correos electrónicos sobre lo mismo y los quiero en el mismo Ticket.

De acuerdo con @greezybacon : los problemas son un concepto útil. Combinar tickets es una función útil. Deben desarrollarse por separado y no cooptarse.

Me gusta la idea de un nuevo tipo de boleto (emisión) que sería como un mega boleto. Que podría usarse para combinar múltiples boletos en un solo problema... o incluso abierto por el personal cuando/si sucediera algo importante que afectara a muchos. Personalmente, rara vez usaría esto en cualquiera de mis sitios en vivo. Pero es posible que quiera usarlos para cosas como mantenimiento programado, grandes cortes de red, etc.

Dicho esto, probablemente usaría una función de combinación con más frecuencia. Espero que sea algo así como lo hacemos manualmente ahora. Que consiste en actualizar un ticket (el que se creó más tarde) diciendo que ya hay un ticket abierto para este problema (número de ticket de referencia) cerrando el ticket duplicado. y luego actualizando el ticket original con cualquier información adicional, y agregando al abridor del segundo como colaborador.

Estoy con problemas de @ooglek y la fusión sería dos cosas diferentes. La fusión sería más útil para nuestra empresa mientras el concepto de problemas, no estoy seguro de si lo necesitamos. Aunque es agradable...

Siento que todavía hay algo de confusión.

Fusionar tickets, propietarios, hilos y datos es:

• qué causa la "contaminación"
• para ayudar a mantener el mismo problema de la misma persona o grupo de personas en los mismos datos e hilo de comunicación
• (posiblemente) elimina boletos cuando se fusiona con otro

Asociación de tickets a través de un problema

• mantiene (todas) las cosas separadas
• permite la comunicación separada, datos, propietarios, colaboradores, sobre temas "relacionados"
• agrega boletos "relacionados" a una vista de boleto
• agrega una nueva lista de elementos al sistema, "problemas"
• permite la comunicación masiva y el cierre

@greezybacon buen resumen. así que básicamente dos nuevas características

@snizzleorg Sugiero que así es como funcionarían las dos funciones. Espero eliminar cierta confusión al sugerir propósitos distintos para dos características distintas. Mi esperanza es que todos estén en la misma página para que podamos trabajar en avanzar con RFC e implementaciones para las funciones.

Bonito. Como dije, estoy más interesado en la fusión y creo que al menos esta función está bien diseñada. Queda la pregunta de cómo seleccionar el ticket resultante del propietario si los dos tickets iniciales son diferentes y cómo resolver los conflictos en los datos del ticket.

Yo sugiero:

1 +merge 2 = datos/propietario del ticket 1

2 +merge 1 = datos/propietario del ticket 2

Voto para darle al usuario (agente) la elección de qué datos tendrá el ticket combinado.

Dele al usuario una predefinición/sugerencia de los datos del ticket fusionado que puede
A) aceptar y proceder con la fusión o
B) cambiar completamente la dirección de las fusiones (por lo que 2 + fusionar 1 = datos/propietario del boleto 1 en lugar del boleto 2) o
C) editar campos individuales (p. ej., tema de ayuda) antes de fusionar los tickets

@greezybacon Sobre la fusión de tickets, creo que existe cierta confusión sobre el efecto de una fusión para el usuario y los medios reales de la fusión en el backend.

• Contaminación : si ambos boletos se mantienen separados en la base de datos, no hay contaminación. Tras una acción de "combinación", se crearía un "vínculo" entre dos tickets y un tipo de relación (el Ticket 3 es un hijo del Ticket 4, el Ticket 4 es el padre del Ticket 3). El software mantendría sincronizados los estados de los tickets vinculados: cuando se cambia el estado de un ticket principal, todos los estados de los tickets secundarios cambian. Cuando un ticket secundario recibe una comunicación por correo electrónico, esa comunicación del ticket se actualiza y cualquier cambio de estado de un niño se sincroniza en todos los tickets vinculados. El ticket 4 mostraría la comunicación actualizada en el ticket 3. En este caso, no habría contaminación y siempre podría desvincular (descombinar) los dos tickets con poco o ningún efecto (el único efecto que se me ocurre es si agrega colaboradores de Tickets secundarios a Tickets primarios cuando fusionó, y probablemente no quiera deshacer eso cuando deshaga la fusión).
• Retención de colaboradores : creo que el 90% de las fusiones serán de la misma persona, ya sea del mismo correo electrónico o de dos correos electrónicos diferentes administrados por la misma persona. La preocupación de ese 10 % es simplemente documentar en gran medida (y también en la interfaz de usuario en el momento de la fusión) lo que se hará (agregar automáticamente colaboradores al ticket maestro desde el (los) ticket(s) niño(s)) y asegurarse de que el usuario sepa que si eso no es lo que quieren, deshacerlo. O agregue una casilla de verificación que esté marcada de manera predeterminada "Combinar propietarios de tickets con colaboradores en principal/maestro" y, si desmarca, los colaboradores no se modifican en el principal.
• Eliminación de boletos -- ¡NO! no lo hagas Eso es malo.

Los problemas son una característica nueva, hasta el momento (que yo sepa) sin diseño, sin especificar y amorfa. ¿Podría usar Problemas para fusionar tickets? ¡Totalmente! Pero, ¿es esa realmente la intención de la función Problemas, fusionar tickets? ¿O está complicando los problemas para permitir la fusión porque parece más fácil?

Si los problemas son problemas comunes que tienen varios clientes, ¿los usuarios/administradores de OST realmente quieren ver un montón de problemas de "ticket combinado" en la lista? Para muchos usuarios de OST, es posible que no necesiten problemas, y me confundiría si la combinación de tickets "creara" un problema. Pierdes el contexto del ticket cuando se convierte en un problema; ahora tengo que manejar los "tickets combinados" de manera diferente a los tickets normales, y cambiar a un área completamente diferente en OST para administrar los tickets combinados, que luego quedan fuera de las reglas. escalado y operación en OST de Billetes Regulares.

Realmente creo firmemente que el uso de Problemas para implementar Merge Tickets causará muchos más problemas y desafíos, tanto para el desarrollo de OST como para los usuarios de OST, que encontrar una manera de implementar Merging Tickets de manera no destructiva dentro del marco existente de Tickets. existen hoy, con la adición de una tabla o dos en la base de datos y algunos códigos y disparadores para manejar acciones en los tickets que están vinculados.

@snizzleorg Creo que no entendiste el comentario de @greezybacon : no estaba diciendo "dos características diferentes", estaba diciendo "Los problemas resuelven todo limpiamente". A lo que no estoy de acuerdo anteriormente.

@ooglek Está combinando los conceptos de problemas (tickets vinculados) y fusión. ¿Cómo puedes fusionar dos cosas y terminar con dos cosas que están vinculadas? La idea de fusionar implica colapsar varias cosas en una sola; por lo tanto, la eliminación de elementos combinados.

@grezybacon @ooglek

MI opinión sobre esto es que la vista de la base de datos ooglek es correcta y los boletos no deberían simplemente eliminarse.
En el sitio de uso/interfaz greezy es correcto y tienes que ocultar/reemplazar las cosas viejas, de lo contrario, la fusión no tiene sentido.

PERO de nuevo, ¿por qué tan complicado?
¿Por qué los tickets simplemente se cierran con la fusión (tal vez un estado de fusión específico)?

Esto significa que aún se puede acceder a los boletos o que se pueden ver mejor a través del boleto/problema principal, pero ya no se pueden cambiar.
O tal vez se implementará una especie de instantánea, para que pueda alternarla, etc. (pero esto es un diseño posterior)

Y ese es el punto donde la fusión y la emisión pueden separarse (MI opinión), por lo que al fusionar los boletos cerrados y en emisión es una lista de boletos 'abiertos'.

SALUD

@greezybacon Merging es un concepto de interfaz de usuario, no un concepto de back-end. Desde la perspectiva del usuario, el ticket parece fusionado, porque una vez que realizan la acción Fusionar, ven que el ticket maestro tiene toda la correspondencia en orden cronológico en su vista, y la respuesta va a todas las partes fusionadas (o excluidas en el momento de la fusión). ). Entonces, el usuario ve un ticket combinado.

En el backend, desea que las cosas sean lo más limpias y desarmables posible. Al crear una relación entre más de 2 entradas, puede:

• Acepte las respuestas a los tickets secundarios por correo electrónico porque ese ticket aún existe; no se necesita un código adicional ni una estructura de base de datos para manejar los correos electrónicos entrantes con tickets que ya no existen.
• Separar: las respuestas se mantendrán con sus respectivos tickets; el único problema persistente son los colaboradores combinados, que potencialmente también podrían manejarse en la separación.
• Historial: el historial de tickets todavía existe y puede verlo directamente, sin nuevos cambios de software.
• Vista abierta/resuelta/cerrada: dado que los tickets secundarios, desde el punto de vista del usuario, están fusionados, los tickets secundarios no se enumeran en estas vistas.

Para implementar Merge de esta manera no destructiva, veo tres cambios importantes y una característica/función adicional adicional:

• Tabla de relaciones. Vincula un ticket a otro ticket con un tipo de relación.
• Modificar la vista Abierta/Resuelta/Cerrada de los tickets. Excluir boletos que son niños.
• Modificar Ver Ticket. Combine la correspondencia de los boletos de Padres e Hijos, en tiempo real, por ejemplo, seleccione * de la correspondencia donde el boleto en (boletoA, boletoB) ordene por fecha de recepción desc. Y cuando vea un ticket para niños, deje en claro que está etiquetado activamente como niño y es de solo lectura y no puede responder a él. Agregue un enlace al ticket maestro.
• Nuevo código: Merge agrega la relación y copia (casilla de verificación opcional, o incluso mejor, una casilla de selección múltiple con toda la información del cliente y del colaborador) el cliente y los colaboradores como colaboradores en el ticket maestro.

Esto simplifica enormemente la fusión, le permite no modificar grandes franjas de código para manejar tickets "fusionados", deja un rastro de historial para que pueda investigar cuándo un ticket se "fusionó" o "no fusionó", y es casi completamente no destructivo. (la modificación en el ticket Master de los colaboradores podría interpretarse como destructiva; no creo que lo sea, pero no quiero descartar ese punto de vista).

@ Hannibal226 y parece que estoy de acuerdo en la mayoría de los puntos. Sin embargo, no creo que los boletos combinados de los niños deban cerrarse; creo que cuando cambia el estado maestro, cambia el estado del niño, y viceversa.

Por ejemplo, si el ticket maestro está "Resuelto" y un cliente con el ticket secundario responde por correo electrónico, entonces el ticket secundario debería volver a "Abierto" y, por lo tanto, el maestro y todos los demás tickets secundarios también deberían volver a "Abierto".

Si cierra todos los tickets secundarios como "Fusionados", entonces tendrá que modificar más la lógica de manejo de nuevos correos electrónicos entrantes. El ticket tiene el estado "¿Fusionado?" ¿Todavía agrega la correspondencia al boleto original del niño? ¿O ahora modifica el Maestro (que creo que podría conducir a un gran lío si la fusión fue un error cometido anoche, los clientes respondieron tres veces diferentes, luego fui a desfusionarlos, y ahora el cliente Una correspondencia está en el ticket del cliente B.

@ooglek

Entonces, a su manera, desea abrir el boleto A, B y el "maestro" C en cuanto a un correo que ingresa al boleto A.

Pero sin conocer el código, diría que esto es al menos difícil/fácil cuando el correo ingresa a A, que es uno combinado de C.
Lo que significa que solo C cambia a en línea.
Entonces, aquí solo se necesita una rutina (bandera o mediante tabla de relaciones [como no mencionada]).

El sentido de fusión es limpieza. Por lo tanto, abrir tickets, que también se fusionaron, no es necesario, ya que mantenerlos abiertos cuando se fusionan. (en mi opinión)
Entonces, el ticket A y B simplemente se vuelven invisibles/reemplazados (para todos los usuarios y colaboradores) tan pronto como se fusionaron, por lo que se pueden cerrar (finalizar/olvidar).
En la mayoría de los casos, nunca los necesitará de nuevo, entonces, ¿por qué seguir cambiando el estado?
Solo en algunos casos, tal vez desee verificar algo, por lo que puede acceder a él a través de enlaces y, en la última opción, desvincularse.

Así que veo nuestros acuerdos en:

• Sin cierre de ticket
• Los problemas no se fusionan, pero la fusión puede manejar los problemas (al menos entiendo que te gusta eso)
• Función Fusionar/Separar
• Fusionar principalmente UI solo menos DB

pero nuestras diferentes opiniones reales pueden ser sobre:

• niño - maestro (porque más DB que UI en mi opinión)
• el estado cambió en todos los tickets, que solo el "maestro"

¡SALUD!

@Hannibal226

Mi escenario funciona así:

• Cliente A envía correos electrónicos, crea Ticket A
• El cliente A envía correos electrónicos, la misma dirección de correo electrónico, crea el Ticket B
• Correos electrónicos del cliente A, dirección de correo electrónico diferente, crea el ticket C

El usuario/agente de OST decide usar el boleto A como "maestro" y fusionar el boleto B y el boleto C con el boleto A.

• OST Crea una relación vinculada, el boleto B es un elemento secundario del boleto A
• OST Crea una relación vinculada, el Ticket C es un elemento secundario del Ticket A
• Dado que hay dos correos electrónicos diferentes en estos tres tickets, el usuario/agente de OST decide fusionar a otros usuarios que no sean el maestro como colaboradores; El cliente A, el correo electrónico B se convierte en colaborador en el ticket A

Y ahora hemos terminado.

Si el Cliente A envía un correo electrónico al Ticket C, esa correspondencia se agrega al Ticket C, tal como está ahora. Si esa correspondencia desencadena un cambio de estado (Resuelto -> Abierto), el estado del Ticket C cambia, como lo hace ahora, pero también cambia el estado del Ticket A y el Ticket B para que coincidan.

Si el Cliente A envía un correo electrónico al Ticket B, sucede lo mismo.

Si el Cliente A envía un correo electrónico al Ticket A, sucede lo mismo.

Cuando el usuario/agente de OST carga el boleto A (boleto maestro fusionado), ve toda la correspondencia del boleto A, B y C, en línea. Podríamos o podemos optar por no mostrar que son del boleto fusionado en la Vista de boletos.

Cuando el usuario/agente de OST carga el ticket B o C, ve un aviso de que se trata de un ticket secundario vinculado, con un enlace de URL al ticket maestro, y que todo aquí es de solo lectura, y las respuestas se deben realizar dentro del maestro. Boleto.

No estoy muy seguro de lo que quieres decir en tu segundo párrafo. ¿Puedes reformular?

Párrafo 3: Sigo sin estar de acuerdo con que los Boletos para niños (en su nota, Boleto A y Boleto B) deban cerrarse. ¿Qué sucede cuando un cliente responde a ese ticket secundario? Ahora debe modificar cómo manejar los tickets que están en un estado nuevo (Cerrado combinado) o en un estado más estado de relación (Cerrado + Niño) y luego agregar lógica para cambiar el estado del Maestro. Y si el estado es Cerrado, la correspondencia no debe agregarse a ese ticket sino al Máster. Pero cuando hace eso, pierde la capacidad de anular la fusión porque ahora la correspondencia que entró destinada al ticket A (secundario) se escribe en la base de datos para el ticket C (principal) y si anula la fusión, ¿cómo extrae la correspondencia? ¿El Boleto C (maestro) destinado al Boleto A (hijo) de regreso al Boleto A?

Creo que los clientes se aferran a los boletos durante mucho tiempo; he recibido correos electrónicos de clientes sobre boletos abiertos hace 2 años, y quiero asegurarme de que se aborden esos boletos.

Veo nuestro acuerdo aquí como:

• Sin cierre de ticket
• Ofrezca una funcionalidad de combinación y separación
• Fusionar es principalmente solo cambios en la interfaz de usuario, cambios mínimos en la base de datos y minimizar los cambios de código y proceso

Y no estamos de acuerdo en:

• Cómo implementar la relación niño-maestro
  ** yo: solo una tabla de relaciones
  ** Uds: ??
• Asuntos
  ** yo: los problemas son una característica separada mencionada en este hilo, pero en mi opinión no están relacionados con la implementación de las características de combinación
  ** Uds: ??
• Entradas Estado de Máster y Niño
  ** yo: creo que el estado del ticket maestro y el secundario deben permanecer sincronizados, de modo que los clientes puedan responder a cualquiera de los tickets, y que la correspondencia entre en el ticket previsto por el cliente, de modo que durante un Unmerge haya consistencia y no se mezclen respuestas no deseadas
  ** Uds: ??

Espero que comparta sus pensamientos sobre dónde diferimos.

¿Existe un grupo maestro de desarrolladores de OST? ¿Algún tipo de proceso?

@ooglek

• Cómo implementar la relación niño-maestro ** yo: Solo una tabla de relaciones ** tú: ??
• Estado de los tickets maestro y secundario ** yo: creo que el estado del ticket maestro y secundario debe permanecer sincronizado, de modo que los clientes puedan responder a cualquiera de los tickets, y esa correspondencia va al ticket previsto por el cliente, de modo que durante una desconexión no es consistencia y no hay mezcla de respuestas no intencionadas ** tu: ??
  
  
  
  • En primer lugar, nos acercamos a la relación "maestro-hijo" y la tabla de relaciones.
  
  
  • Así que estoy de acuerdo aquí, PERO no con la gestión de estados a través de múltiples tickets.
    
    Reabrir los cambios de estado del pedido solo debería tener efecto en "maestro" (en su ejemplo A), en mi opinión.
  
  
  • Toda la comunicación debe ser simplemente "redireccionar" al maestro, en la medida en que se fusione. Porque, ¿por qué debería usar fusionar, cuando desea agregar algo al boleto B o C después? [por lo tanto separar]
  
  
• Problemas ** yo: Problemas es una característica separada mencionada en este hilo, pero en mi opinión no está relacionada con la implementación de las características de Merge ** usted: ??
  
  
  
  • Porque Problemas: Tienes razón y podemos discutir esto en otro momento :P
    
    Creo que solo un manejo de estado diferente (separado del maestro) y la creación de un nuevo ticket podrían generar una función de problema, sin "rediseñar/implementar" completamente las cosas aquí.
  
  

Estoy feliz por el interés y el movimiento en esta 'solicitud de función';)

¡SALUD!

@Hannibal226

• Relación -- acordada
• Estado de los tickets: la razón por la que sugiero que mantengamos el estado sincronizado con el maestro y el niño se debe al caso en el que llega un correo electrónico destinado al niño.
  
  
  
  • Si "cerramos" las entradas de los niños, ¿qué hacemos con este nuevo correo? Si lo agregamos a la correspondencia del Maestro, entonces no podremos "Desfusionarnos" limpiamente. Si lo agregamos a la correspondencia del Niño para permitir una separación segura, ahora tenemos que deshacer el código de cambio de estado existente que habría hecho que el Niño se "abra", pero ahora tenemos que suprimir eso y solo cambiar el Maestro a "abrir". ". Esos son algunos cambios fundamentales.
  
  
  • Si mantenemos el niño/maestro sincronizados, el nuevo correo electrónico va al ticket secundario, el estado del niño se actualiza y eso (código adicional, sin modificar el código existente) activa una actualización de estado en los otros boletos secundarios y maestros. Es una pieza de código agregado, no un cambio lógico en el nuevo código de manejo de correo electrónico.
  
  
  • Creo que esto último es más limpio, manteniendo la lógica como está y simplemente agregando un paso adicional para los boletos que forman parte de la tabla de Relaciones mencionada anteriormente.
  
  
• Problemas -- ¡Estamos de acuerdo! :-)

@greezybacon Me encantaría escuchar sus pensamientos. ¿Y es esta una de esas cosas que le gustaría que bifurcara, modificara y luego enviara una solicitud de extracción? ¿O quieres implementar?

@ooglek

• Estado del billete
  
  
  
  • Touché. Olvidé la opción de no fusionar, que seguramente será más fácil y más estructurada, si los correos ingresan directamente mientras está fusionado.
  
  

Es bueno ver que nos reunimos aquí: P

SALUD ;)

La interfaz de usuario fusionada podría ir junto con la función de subproceso plegable aquí: # 2699

Creo que deberíamos tener un ícono en la lista de boletos que indique si un boleto tiene boletos combinados. Luego, los agentes sabrán si pueden desvincularse de la lista de boletos o de la vista real del boleto.

Debe haber un evento del sistema de la fusión y cuándo tuvo lugar en la vista del ticket. Los tickets que se fusionan deben tener un indicador de color separado que muestre que son los tickets fusionados dentro del hilo. como los colores para mensajes y notas.

En la parte inferior del cuadro de diálogo de respuesta, podría enumerar las direcciones de correo electrónico de todos los tickets combinados y el agente puede eliminarlos manualmente al responder. O use un menú desplegable en el botón Enviar para elegir "Responder a todos" o "Responder ticket principal". Responder a todos podría autocompletar las direcciones de los remitentes con la opción de eliminar manualmente. Estoy pensando en voz alta aquí.

En la combinación real después de que se verifican los boletos y se selecciona la combinación, ¿un modal con opciones sobre qué boleto es principal? ¿Qué direcciones de correo electrónico conservar para enviar respuestas? Deberían estar disponibles las opciones para cerrar, reclamar o transferir boletos después de realizar una fusión. ¿Posiblemente una opción para agregar la combinación o mezclar la combinación por fecha? Pensaré en otras cosas más tarde. Esto es puramente IU pensando. Les dejaré discutir el backend, trataré de mantenerme al día. :sonrisa:

+1

+1

Hola,

¿Alguna noticia sobre esta característica buscada?

+1

+1

Ya lo hice para mi versión (v1.9.12). La función de la siguiente manera:

• El usuario (invitado) Foo usa el correo electrónico [email protected] enviado al sistema, crea el ticket X-1234.
• El usuario Foo olvida el correo electrónico que usó para el ticket X-1234, luego usa el correo electrónico [email protected] para enviarlo al sistema. Ahora el asunto del correo electrónico es nuevo y no tiene el número de ticket. Sistema crea ticket X-2345.
• El personal (agente) abrirá el ticket X-1234, elegirá Combinar tickets. Se mantendrá el formulario del boleto X-1234 y sus hilos. Los subprocesos de X-2345 se fusionarán en X-1234. Los detalles de los formularios de X-2345 permanecerán para verificación adicional.

@cosmospham eso suena exactamente como lo que necesitaría. ¿Tienes una sucursal o alguna forma de descargar tu código?

@snizzleorg Lo siento porque este es un repositorio privado. Por lo tanto, solo puedo capturar los cambios de confirmación para usted. Ver cambios en 03 archivos de captura de pantalla https://github.com/cosmospham/test-0

En primer lugar, agregue un menú.
En segundo lugar, agregue una regla de ruta.
Luego crea un diálogo ajax.
Luego escribe la función de combinación.
Aviso: solo actualice la página después de la fusión.

Creo que puedes entenderlos.

Mi empresa utiliza actualmente la función de combinación de tickets para los siguientes escenarios:

1. Contamos con alertas de seguimiento acude a nuestro sistema de ticketing. Digamos que recibimos una alerta de que el firewall se cae. Luego, 30 minutos más tarde, recibimos un ticket de que el firewall está activo. Lo que hacemos entonces es fusionar los dos tickets y cerrarlo. Cuando ocurre la fusión, fusiona los dos tickets y el ticket que se creó primero permanece como el ticket y el nuevo ticket que entró se convierte en parte del historial de tickets.
2. Los correos electrónicos de los usuarios acerca de un problema. Luego vuelve a enviar correos electrónicos con respecto al mismo problema, pero como no enviaron un correo electrónico con el número de ticket en el asunto, el sistema crea otro ticket para el mismo problema abierto por el mismo usuario. La fusión de los dos boletos junto con el primer boleto permanece visible y el segundo boleto abierto pasa a formar parte del historial de boletos.

Poder combinar un montón de tickets relacionados en un "problema" principal es una gran idea, pero creo que debería estar separado (como piensan otras personas) de la función de combinación.

+1

+1, esta característica sería muy valiosa para nosotros. Una parte muy importante de nuestros usuarios responde a las notificaciones por correo electrónico de osticket utilizando un cliente de correo electrónico que no respeta los encabezados esperados por osticket

Esta es una gran demanda para tener la función de combinación de tickets desde 2009, la gente discute en el foro de osticket.
Y también compruebo si hay alguna actualización de vez en cuando, pero lamentablemente, solo hay que esperar una y otra vez.

¿Por qué esta característica es tan importante (dentro de la empresa interna)?

• Si uno de los servicios no funciona y 10 usuarios le envían comentarios sobre el mismo problema, se crearán 10 tickets.

• Si el proveedor de servicios o el proveedor resolvieron un problema por usted y desea adjuntarlo como un documento de ticket cerrado, no puede reenviar el mensaje a osticket y fusionar el ticket existente. Tienes que copiar el contenido o guardarlo como pdf para subirlo. Pero, ¿qué tal un mensaje que su proveedor de servicios adjunte con muchos archivos adjuntos? Tendrás muchos trabajos manuales que hacer.

• Un usuario crea un nuevo ticket y comenta algún problema del sistema, pero en realidad ya proporcionamos la solución hace un año. ¿Por qué es necesario fusionar el ticket antiguo con este nuevo? Debido a que trata con el personal de la oficina, necesitarás refrescar su memoria, hazles saber que repiten la misma pregunta.

+1

+1

+1

+1

Al trabajar en MSP, entiendo cómo esto afectaría su productividad, ya que tendría que trabajar en cada ticket individualmente. ¡¡¡Eso sería una gran adición!!!

+1

+1

+1

Realmente nos encantaría trasladar nuestro sistema de tickets internamente (fuera de Zendesk). La capacidad de fusionar/dividir boletos es un factor clave en nuestra decisión. No es raro que lleguen más de 20 tickets de varias fuentes (ventas, revendedores, proveedores, transportistas, sistemas automatizados, respuestas de clientes, etc., etc.). La idea de fusionar manualmente todas estas cosas no sería más que una pesadilla.

Estaríamos dispuestos a aportar unos cuantos dólares financieramente para ayudar a poner en marcha el proceso. No tengo idea de cuánto podría costar, pero me encantaría configurar una página de GoFundMe. Parece que tenemos suficiente "+1" aquí que unos cuantos dólares de todos deberían financiar el tiempo de desarrollo y ahorrarnos una fortuna en nuestro hospedaje de Zendesk.

+1 para la versión 1.10

+1

+1

¿Alguna noticia de si esto va a pasar?

+1
Esto es muy necesario, incluso puedo contribuir con código para que esto suceda.

Debo señalar que ya implementamos esta función usando enlaces de boletos y el código se publicó en línea aquí:

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

Incluimos un enlace a un desarrollador que puede implementarlo por usted si no se siente cómodo haciéndolo por su cuenta.

Parece que algo sucedió.... #3768
Gracias por compartir el trabajo @ Micke1101

Me alegra ver que se está trabajando en esto. +1

@ Micke1101 ¡ Bien hecho con esa solicitud de extracción! ¡Espero que se fusione con el núcleo pronto! +1

3768 Necesita más visibilidad.

¿Algo nuevo en este tema?

Entonces, ¿supongo que 2020?

¡También queremos fusionar boletos en osTicket 0.12.2! Vota por esta función :)
No importa si se construye como complemento o en el núcleo.
¡Gracias!

@antiusuario

La función oficial de fusión de boletos se encuentra en el siguiente enlace. Sigue ese hilo para mantenerte actualizado:

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

Salud.