Osticket: Error v1.9.12: los colaboradores no notifican por correo electrónico en la primera entrada de amenaza de ticket

Encontré un problema relacionado previamente informado como # 1130 pero en esta fecha aún no están implementados

¿Dónde debo editar para hacer esto?

Aún así, de alguna manera, si está presente en la marca 1.10, aún 1.10 no es estable y no puedo proponer en la organización para usar en producción ...

¡Casi un año todavía esperando esta NECESIDAD FEAURED de colaboradores adicionales cuando el agente abre tickets para los usuarios al menos que csn hice para la marca 1.9 por amor a dios y extraterrestres!

@mckaygerhard no enviamos el correo electrónico inicial porque los colaboradores ya estaban incluidos en el correo electrónico que se utilizó para crear el ticket. ¿Por qué deberían recibir un segundo correo electrónico con la misma información?

becose aquellos destinatarios recibieron un evento normal por correo electrónico y una notificación de ostiket

si puedo hacer un ticket desde la interfaz y aquí en un primer paso agrego que colaboratos, el mail que se enviará será para todos los relacionados (el autor, el cliente y el colaborador)

debido a que las personas involucradas recibieron un correo electrónico normal, luego respondieron con correos electrónicos normales, y todas las amenazas ocurren fuera de la amenaza. un verdadero dolor para el técnico de soporte

como dije @greezybacon debido a que las personas involucradas recibieron / enviaron correos electrónicos normales de Fitrs Step, luego respondieron con correos electrónicos normales, ¡y todas las amenazas ocurren fuera del Thiket Thiket! un verdadero dolor para el técnico de soporte

¿Sin solución todavía?

por supuesto, no hay solución ... hasta que algo como suceda con owncloud subir a este proyecto ... levantar una bifurcación y el desarrollo se ralentizará ... la migración a la nueva bifurcación

@inphower Ver:
greezybacon comentó el 25 de junio de 2016
"mckaygerhard no enviamos el correo electrónico inicial porque los colaboradores ya estaban incluidos en el correo electrónico que se utilizó para crear el ticket. ¿Por qué deberían recibir un segundo correo electrónico con la misma información?"

Hay:
R: no hay forma de abrir un ticket en la interfaz de usuario con colaboradores.
B: la única forma de abrir un ticket con colaboradores es enviando un correo electrónico al sistema de tickets y CC a la gente. Y los DEV decidieron no enviar a todos los destinatarios dos correos electrónicos en lugar de uno.

Repito: las personas involucradas reciben / envían correos electrónicos normales de Fitrs Step, luego responden con correos electrónicos normales, ¡y todas las amenazas ocurren fuera del Thiket Thiket! un verdadero dolor para el técnico de soporte

Entonces tu argumento es:
Si envío un correo electrónico a: [email protected].
y CC a [email protected] , [email protected] y [email protected].
¿Que Jon, Mary y Jane no recibirán el correo electrónico original?

Pero cuando enviamos la primera respuesta de osTicket, esto solo va a un correo electrónico porque los CC de la primera entrada no están incluidos ,,,

Uds. saben

@inphower que

el problema aquí todos ustedes, es que aquellos que enviaron por correo en CC, recibirán un correo fuera de la amenaza del boleto ...

así que si uno de estos responde, el tiket obviamente no recibió el historial de amenazas debido a que no está en el correo de respuesta.

Quiero decir: Jon, Mary y Jane reciben el correo original, pero debido al "envío" no solo al boleto, estos tipos no son "notificados" de que el destinatario final y verdadero es "un boleto".

si después de ese correo que Jon, Mary y Jane, hay otro con el boleto, entonces pensarán "ah, está bien, fue un boleto, no una conversación privada".

por supuesto, estamos lidiando con gente "tonta", ¡ese es el motivo de la encuesta de tickets, soporte de tickets o lo que sea!

Entonces la amenaza se vuelve dolorosa debido a que la historia se perderá cuando eso sucedió.

@inphower creo que u se refiere cuando un partidario abre un ticket como autor, y por supuesto en este caso y en la serie 1.9 de osticket esto no es posible, pero no hay dificultad para hacerlo .. la respuesta de los chicos de osticket fue "use 1.10 "eso fue hace casi 1,5 años ... en este momento 1.10 era inestable, por lo que la sugerencia fue usar inestable en producción ... ¡genial!

Ahora parece que el tirón resuelve la situación # 3353 parece muy fácil, ¿por qué fue tan complicado para los desarrolladores implementarlo en 1.9, en ese tiempo!

este problema todavía sucedía en 1.10 ... ¡los colaboradores no se muestran y no se notifican!

@mckaygerhard

La línea de pensamiento aquí es que dado que los Colaboradores reciben el correo electrónico original del Usuario, no es necesario que reciban la Alerta de Nuevo Ticket. Eres más que bienvenido a modificar el código base a tu gusto si esto no es algo que deseas.

Salud.

Parece que las soluciones están en el n. ° 3353, pero los desarrolladores nuevamente no se hacen cargo de ese problema. Es por eso que hay tantos comentarios "eliminados".

@mckaygerhard

No hay una "solución" ya que no hay un problema real, así es como se pretende que funcione. Como mencioné antes, puede modificar el código base / aplicar la solicitud de extracción que mencionó y terminar con ella.

Salud.

entonces el tirón # 3353 ¡así que combínalo!

oye tirar están en # 3353 unos 10 años .. y ahora @protich dice : "queremos llegar con la comunidad"! ???? umm ...

Oigan todos. Me alegro de que esté teniendo una conversación, sin embargo, quisiera señalar que está completamente fuera del tema de este informe de problemas. Mantenga los informes de problemas sobre el tema. Gracias.

Cuál es el problema ... él está cooperando y todavía se quejan