Osticket: Permita que los agentes respondan a los nuevos tickets por correo electrónico

¿Cómo propondría que se manejara la colisión de agentes?
(dos agentes que responden al mismo ticket en rápida sucesión)
¿O bloqueo de billetes?
¿O asignación de entradas?

Quizás te interese un mod que hice para hacer exactamente lo que quieres. Ha estado funcionando durante un par de años y no he tenido problemas con él. Modifiqué class.ticket.php y class.thread.php. Puede obtenerlos aquí: http://we.tl/4X0cUWgNtZ

Los mods están marcados entre "// LUIS MOD" y "// END LUIS MOD". En class.thread.php necesitaría los dos mods, pero en class.ticket.php solo necesitaría "// LUIS MOD: función postResponse, para agregar respuestas de correo electrónico del personal como Respuestas, no Notas".

Desearía poder convertir estos mods en complementos, por lo que no necesito copiar y pegar todas las cosas cada vez que actualizo.

Hola @molul, ¿tu mod funciona para 1.9.12? ¿Puedes publicarlo de nuevo? No puedo encontrar ninguna otra modificación tan actual como la tuya. Esto parece que realmente debería ser una configuración estándar disponible en osticket.

¡Seguro! Aquí está:
luis-mod.zip

¡Espero eso ayude!

Gracias por enviarlo, intenté copiar solo la sección "LUIS MOD" en los archivos existentes, pero no funcionó porque hay algunas otras diferencias en los archivos. Luego intenté reemplazar todos los archivos con los que publicaste y funciona. ¿Para qué versión están creados?
Gracias por esto, espero que osticket eventualmente lo incluya como una opción en el panel de administración en una versión futura.

¡Oh! Lo siento por eso. Fue creado para 1.9.x (no recuerdo exactamente cuál) y luego portado a 1.9.8 simplemente copiando y pegando las partes "// LUIS MOD".

Ojalá supiera cómo convertir estos mods en complementos, para poder actualizar fácilmente a versiones más nuevas.

Esto funciona perfectamente, una cosa me estaba preguntando. ¿Es posible que lo asigne al miembro que responde por correo electrónico? Para propósitos de colisión, haga que verifique si ya está asignado antes de asignarlo. Solo estoy buscando que active la alerta de correo electrónico de asignación para los otros miembros del equipo notificándoles que uno de nosotros lo está mirando. Esto nos ayudará cuando no estemos en nuestro escritorio pero podamos ayudar con un problema.

Bueno, supongo que habría una forma, haciendo coincidir el correo electrónico del agente y ejecutando los comandos necesarios, pero me temo que no sé cómo :(

Sería genial tener esto como una característica habitual en osTicket. Quiero decir, agentes que responden al ticket por correo electrónico y asignan tickets desde ese correo electrónico.

Con respecto al mod anterior, probé la versión 1.9.14 y la funcionalidad con los correos electrónicos funciona como se esperaba. El problema es que perdí la funcionalidad para editar el ticket a través de la interfaz web. ¿Alguna idea?

UPS. No tengo idea, me temo :( Estoy usando 1.9.12 y no tengo problemas.

funcionó, reemplacé el archivo al principio usando sus archivos y la funcionalidad de edición se rompió en la interfaz web, pero luego lo intenté agregando solo las secciones entre "// comentarios de LUIS MOD y funcionó. ¡¡Gracias molul !!

Oh eso tiene sentido. ¡Me alegra saber que lograste que funcionara!

molul,

Agregué tus modificaciones a una implementación que estoy haciendo y funciona de maravilla. ¡Gracias por tus contribuciones! Pregunta rápida: ¿qué tan difícil sería enviar el correo electrónico de respuesta al equipo asignado al ticket también en lugar de solo al remitente?

¡Gracias de nuevo!

Me alegro de que sea útil para ti :)

Sobre tu pregunta, me temo que no lo sé. Ha pasado mucho tiempo desde la última vez que usé este mod, y no he investigado cómo se envían los correos electrónicos a los equipos :(

Me lo imaginé.

Copié el siguiente código de la función postMessage en class.ticket.php y lo agregué a la función postResponse que hiciste:

    //If enabled...send alert to staff (New Message Alert)
    if($cfg->alertONNewMessage()
            && ($email = $dept->getAlertEmail())
            && ($tpl = $dept->getTemplate())
            && ($msg = $tpl->getNewMessageAlertMsgTemplate())) {

        $msg = $this->replaceVars($msg->asArray(), $variables);

        //Build list of recipients and fire the alerts.
        $recipients=array();
        //Last respondent.
        if($cfg->alertLastRespondentONNewMessage() || $cfg->alertAssignedONNewMessage())
            $recipients[]=$this->getLastRespondent();

        //Assigned staff if any...could be the last respondent
        if ($cfg->alertAssignedONNewMessage() && $this->isAssigned()) {
            if ($staff = $this->getStaff())
                $recipients[] = $staff;
            elseif ($team = $this->getTeam())
                $recipients = array_merge($recipients, $team->getMembers());
        }

        //Dept manager
        if($cfg->alertDeptManagerONNewMessage() && $dept && ($manager=$dept->getManager()))
            $recipients[]=$manager;

        // Account manager
        if ($cfg->alertAcctManagerONNewMessage()
                && ($org = $this->getOwner()->getOrganization())
                && ($acct_manager = $org->getAccountManager())) {
            if ($acct_manager instanceof Team)
                $recipients = array_merge($recipients, $acct_manager->getMembers());
            else
                $recipients[] = $acct_manager;
        }

        $sentlist=array(); //I know it sucks...but..it works.
        foreach( $recipients as $k=>$staff) {
            if(!$staff || !$staff->getEmail() || !$staff->isAvailable() || in_array($staff->getEmail(), $sentlist)) continue;
            $alert = $this->replaceVars($msg, array('recipient' => $staff));
            $email->sendAlert($staff, $alert['subj'], $alert['body'], null, $options);
            $sentlist[] = $staff->getEmail();
        }
    }

Esto nos sirvió.

¡Frio! :D

Sería genial tener esto como una característica habitual en osTicket. Quiero decir, agentes que responden al ticket por correo electrónico y asignan tickets desde ese correo electrónico.

Pista * Pista * osTicket

@ ets-phill, ¿podría publicar un archivo de diferencias para estos cambios? 👍
Estoy trabajando con v1.10

Sí, necesito esta funcionalidad exageradamente para la versión 1.10. Creo que este sería un habitual en OsTicket.

¿Alguien ha actualizado esto para v1.10? Gracias.

Actualmente, con la versión 10, cuando un agente responde a un ticket por correo electrónico, publica la respuesta en una nota interna y nadie recibe una copia. Si el sistema puede leer la respuesta por correo electrónico del agente y publicarla en una nota interna, ¿por qué no puede enviar también la respuesta al creador del ticket?

¿O es esto lo que se supone que debe hacer el archivo adjunto?

Bien, acabo de revisar los archivos zip adjuntos y los archivos v. 10 que tengo en mi servidor y veo que ha habido mucho trabajo en ellos y no sé si es posible usar este código en esta versión. ¿Alguien tiene alguna idea para eso?

Sí, una diferencia estaría bien. No puedo conseguir tracción con este sistema porque los departamentos ocupados de un solo hombre quieren poder manejar las cosas desde su bandeja de entrada. Entonces, una vez que los clientes se dan cuenta de esto, terminan recurriendo nuevamente a los correos electrónicos directos en lugar del sistema de tickets.

Lo intenté y ese código no se puede aplicar simplemente usando el comando diff

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milán (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

2017-03-09 21:47 GMT + 01: 00 scslogin [email protected] :

Sí, una diferencia estaría bien. No puedo conseguir tracción con este sistema porque
los departamentos ocupados de un solo hombre quieren poder manejar las cosas desde su bandeja de entrada.
Entonces, una vez que los clientes se dan cuenta de esto, terminan recurriendo a correos electrónicos directos
de nuevo en lugar del sistema de tickets.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-285478201 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAH4imYl9ZLZr5-OmDMA782syzAXFXv2ks5rkGV1gaJpZM4FVyBD
.

Hola,
alguien en este hilo?

@rayfoss por favor marque esta pregunta.
Gracias.

Realmente me gustaría ver esto actualizado para la v.10.

@scslogin, ¿ te refieres a actualizado para la v1.11? 1.10 está y ha estado fuera por algún tiempo.

@ntozier , en realidad estaba hablando de 1.10, actual estable. Este código descrito en este hilo no encaja con 1.10. Demasiado código nuevo.

Modificación que creé trabajando con v1.10: también asigna el ticket a la persona que responde si el ticket no está asignado. Solo he estado usando esto durante un par de días, pero hasta ahora parece estar bien.

https://pastebin.com/RiAxWHbP

Bueno, he aplicado el parche muy fácilmente:
1) descargue el archivo de parche adjunto
responder.txt

2) vaya al directorio "incluir" de su instalación de osTicket
3) ejecute el parche de comando <respuesta.txt

Hecho 👍
He realizado una sola prueba por ahora y parece genial, ¡así que funciona para mí!

Buen trabajo, @ acetwenty8. Sería _muy útil_ si esto pudiera fusionarse en el código principal y habilitarse / deshabilitarse con un cuadro de opción en la interfaz de administración. Con varias personas pasando por la molestia de crear parches para múltiples versiones de osTickets, parece que este es un escenario muy real para varias personas.

@ acetwenty8 Gracias por el mod. Estoy seguro de que estoy haciendo algo mal, ¿alguien puede ayudarme? Ejecuté el parche y los 2 archivos se modificaron, pero nada parece haber cambiado. ¿Hay algo más que deba hacer? Ahora mismo, si un agente responde, se crea un nuevo ticket.

@ jayb80 No tienes que hacer nada más después de aplicar el parche. ¿Cómo está respondiendo al hilo del ticket por correo electrónico? La forma en que funciona es que los agentes responden al correo electrónico de 'Notificación de ticket nuevo' y se envía al hilo del ticket como una respuesta del agente, en lugar de una nota interna (que es el comportamiento predeterminado).

Hola,
He descargado y hecho lo que escribió theCloud. Pero si ejecuto el comando "parche <respuesta.txt" obtengo el siguiente resultado / error ->

web / include # parche <patch.txt
(Eliminando los CR finales del parche; use --binary para deshabilitar).
archivo de parcheo class.ticket.php
(Eliminando los CR finales del parche; use --binary para deshabilitar).
archivo de parcheo class.thread.php
el parche termina inesperadamente en medio de la línea
Hunk # 2 tuvo éxito en 417 con fuzz 1.

¿Qué hacer?

¡Gracias por su respuesta!

Hola,
¿Quizás el archivo se guardó en Windows y luego se aplicó a Linux?

Hola, sí. Lo descargué a través de Windows y lo copié en una versión posterior de Linuxbox. Descargué de nuevo ahora directamente con wget en la caja y parcheé los dos archivos originales una vez más ->

(Eliminando los CR finales del parche; use --binary para deshabilitar).
archivo de parcheo class.ticket.php
(Eliminando los CR finales del parche; use --binary para deshabilitar).
archivo de parcheo class.thread.php
el parche termina inesperadamente en medio de la línea
Hunk # 2 tuvo éxito en 417 con fuzz 1.

¿Quizás usted (o cualquier otra persona) podría enviarme los dos archivos parcheados en un zip (o descargarlos aquí)? Estoy usando el último OST 1.10 (descargado anteayer).

¡Muchas gracias!

Walhalla

@walhallaRV Tuve el mismo problema, lo que terminé haciendo para solucionar el problema fue simplemente agregar una línea al final del archivo reply.txt.

Abrí el archivo reply.txt en vi. fue a la última línea del archivo y agregó una línea y luego se guardó.

Luego corrió:
parche <respuesta.txt

Espero que esto ayude.

BINGO ->
(Eliminando los CR finales del parche; use --binary para deshabilitar).
archivo de parcheo class.ticket.php
(Eliminando los CR finales del parche; use --binary para deshabilitar).
archivo de parcheo class.thread.php

¡¡¡MUCHÍSIMAS GRACIAS!!! a veces las cosas pequeñas causan ... :)

Saludos Walhalla

Probado y funciona muy bien. ¡Gracias a la gente aquí por esta solución!

¡Pero no entiendo por qué OST está ignorando desde hace mucho tiempo las solicitudes de muchas personas con respecto a esta función! No tendrían que hacer muchas cosas, solo implementar esas líneas de código que otras personas escribieron. Al menos como una opción ("bajo mi propio riesgo").

Muchas gracias por esta solución que OST no puede realizar y su ayuda. ¡¡¡GRAN TRABAJO!!!

¡Walhalla, que está feliz ahora!

Bien,
Seamos justos: el producto es uno de los mejores y es gratis.
A veces, los clientes tienen prioridad sobre la comunidad y, por lo tanto, los desarrolladores deben cumplir con los requisitos comerciales.

De todos modos, estoy seguro de que osTicket agradecerá a los desarrolladores por desarrollar y probar esto y agregarlo al producto final.

Démosles algo de tiempo o simplemente spin-off :-)) ahah

Hay muchas solicitudes al respecto desde hace varios años. El único comentario / respuesta: "lo pensaremos".

Si hubiera alguna razón técnica para no implementarlo, sería bueno que uno de ellos respondiera y explicara por qué es imposible. Hace algunos años leí una respuesta como esta en cualquier lugar (no recuerdo): "No necesitamos, así que no trabajaremos en eso ..."?

Si no hubiera posibilidad de responder por correo electrónico, está bien. Pero el hecho de que los clientes puedan responder por correo electrónico, solo los agentes no pueden hacer esto ... nunca lo entendí.

Pero está bien, gracias a ti y a los chicos que están aquí, ¡está resuelto! Una vez mas, muchas gracias ...

Walhalla

OST es principalmente un sistema de tickets de código abierto, es apoyado por su comunidad y algunos desarrolladores que dedican su tiempo personal a OSTicket. Están trabajando en OSTicket de forma gratuita o sin apenas compensación alguna. Miles usan OSTicket y solicitan funciones, así es como salen las versiones más nuevas, pero dado que se solicitan tantas funciones o esas funciones son realmente locas en el aspecto del código, lleva tiempo implementarlo. Se agregan características, puede suceder en una versión principal que está a una versión o dos. Depende de lo que más se necesite. Una forma es ver cuánto quiere la comunidad una función, que este correo electrónico es una solicitud importante.

Con todo lo dicho, estoy seguro de que esto se implementará en un futuro cercano, tenga paciencia y siga solicitando las funciones que desea ver en ediciones posteriores de OSTicket.

El 20 de abril de 2017, a las 11:09 a.m., walhallaRV [email protected] escribió:

Hay muchas solicitudes al respecto desde hace varios años. El único comentario / respuesta: "lo pensaremos".

Si hubiera alguna razón técnica para no implementarlo, sería bueno que uno de ellos respondiera y explicara por qué es imposible. Hace algunos años leí una respuesta como esta en cualquier lugar (no recuerdo): "No necesitamos, así que no trabajaremos en eso ..."?

Si no hubiera posibilidad de responder por correo electrónico, está bien. Pero el hecho de que los clientes puedan responder por correo electrónico, solo los agentes no pueden hacer esto ... nunca lo entendí.

Pero está bien, gracias a ti y a los chicos que están aquí, ¡está resuelto! Una vez mas, muchas gracias ...

Walhalla

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

Es OT aquí y realmente no quiero discutir aquí. Pero les enviamos a dos de nuestros clientes y ellos pagan mucho dinero mensualmente. ¡¿Así que creo que a los desarrolladores también se les paga ?! Además: solo necesitarían copiar este parche desde aquí, implementarlo en un RC / beta para probarlo, listo. Como leí, ¿este parche existe desde la V 1.7?

Podría entender si hubieran respondido solo una vez: "Es imposible implementar esta función". Pero respondiendo "Pensará en esto". durante años sin ninguna decisión? Esos clientes también preguntaron varias veces. ¿Por qué piden solicitudes de funciones ... y no responden?

Pero de todos modos, encontré esta solución, no tengo que entender la política de ellos, no haré ninguna actualización y estoy feliz.

Hola,

Estaba buscando esta solución, pero yo mismo no soy un desarrollador. ¿Hay alguien que me ayude a obtener los archivos correctos para que esto funcione? su versión 1.10.

¡¡¡¡Atentamente!!!!

J

Salva a un animal, consigue un desarrollador :-)

Il giorno sab 22 lug 2017 alle 20:48 j070nl [email protected] ha
scritto:

Hola,

Estaba buscando esta solución, pero yo mismo no soy un desarrollador. Está ahí
¿Alguien que me ayude a obtener los archivos correctos para que esto funcione?

¡¡¡¡Atentamente!!!!

J

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-317178224 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAH4iilh9QVzNKJ3inWp6muFBLUGBtRFks5sQeGWgaJpZM4FVyBD
.

>

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milán (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

¿Eres uno?

Sería genial tener esto como una opción en osTicket. ¡Gracias por el parche @TheCloud !

@TheCloud Gracias por el archivo reply.txt. La ejecución del parche ha funcionado perfectamente en la versión 1.10 y está enviando correos electrónicos a los clientes cuando el personal envía respuestas. ¡Excelente!

Como solicitante original, me alegra que los usuarios de la comunidad / producto hayan creado una pequeña modificación, pero debo preguntar a los encargados del mantenimiento del proyecto si aún ven la posibilidad de incluir la función en el producto de forma predeterminada.

Podría darles a otros un cierre a una función que desean con osTicket.

@voarsh Es algo que está en nuestra hoja de ruta de desarrollo para futuras versiones, sí, pero no se implementará de inmediato. Con algo como esto, lo más probable es que usemos la idea de la solicitud de extracción como base y luego escribiremos la característica oficial en nuestro estilo / visión de codificación. Una vez que terminemos el desarrollo de la función, lo más probable es que la empujemos aquí para que la comunidad la pruebe por nosotros. Luego, una vez que se haya probado y aprobado por completo, se fusionará con la base de código central y será parte de la próxima versión. Espero que esto te aclare las cosas. Salud.

Gracias por el parche, ¡funciona muy bien!

Solo una pregunta: ¿es posible implementar esto también para el correo electrónico "Ticket asignado a usted"?

Escenario: asigno un ticket a un agente. Este agente recibe una notificación por correo electrónico y responde a ese correo electrónico. Desafortunadamente, esto crea un nuevo ticket en lugar de una nueva respuesta al ticket / cliente existente.

¿Es eso posible? ¡Sería genial!
Gracias chicos

@TheCloud Creo que uno de los desafíos reales que tiene osTicket es la falta de una dirección clara y verdadera sobre lo que sigue y cómo se deben enviar las modificaciones y alteraciones. Por ejemplo, esta característica es la más adecuada como complemento o como característica agregada al "núcleo". Si esto es algo que se adapta mejor como complemento, genial. Luego, como grupo, debemos transferirlo a uno. De lo contrario, dada la gran cantidad de apoyo a esto y el hecho de que han pasado años, veo esto como necesario.

A medida que crecen los proyectos de OSS, a menudo buscan usuarios de la comunidad activos y dedicados para intensificar y ayudar con la revisión de códigos, evaluaciones de características, mapas de ruta y diseño. Hay tanto código BUENO que se está quedando atrás con este producto que me temo que está perdiendo tracción que de otra manera podría estar ganando. Si se formara un grupo pequeño y se eliminaran los detalles, creo que la acumulación de código y una mayor claridad de lo que debería ser el núcleo frente a lo que debería ser un complemento se pueden abordar de manera limpia y rápida.

Hola,
¿Este parche de reproducción también funciona con la versión 1.10.4? ¿Alguien aplicó / probó / trabaja?

¡Gracias por su rápida respuesta!

Walhalla

Debería funcionar con 1.10.x; avísenos si no ... no se mantiene
fragmento de código

Il giorno gio 18 ott 2018 alle 03:55 walhallaRV [email protected]
ha scritto:

Hola,
¿Este replay.patch con la versión 1.10.4 también? Alguien aplicó /
probado / funciona?

¡Gracias por su rápida respuesta!

Walhalla

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-430848296 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAH4ivLGLj2zFUk4fGrRLc4LI7UoGcNcks5ul9-kgaJpZM4FVyBD
.

>

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milán (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Esto es asombroso. Recién parcheado y funciona muy bien. Muchas gracias @TheCloud !!

¿Alguien consiguió que esto funcione con la versión más reciente? El parche funcionó bien, pero no pareció cambiar nada.

¿Alguien consiguió que esto funcione con la versión más reciente? El parche funcionó bien, pero no pareció cambiar nada.

¿Cómo hiciste la prueba? ¿Respondiste por correo electrónico a un ticket?

@bevergit Necesita editar class.thread y class.ticket manualmente, los números de línea han cambiado desde que se publicó.

desafortunadamente no funciona con 1.11, no puedo hacer que $ mailinfo ['userClass'] sea igual a 'S', siempre es igual a 'M' ... un poco triste

alguna actualización para v1.12? Esperaba poder implementar esta función. Esta está demostrando ser una característica muy perdida.

Dan,
parece que OSTicket no está realmente interesado en escuchar a la comunidad
requisitos :-)

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milán (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Il giorno mer 19 giu 2019 alle ore 17:16 Dan [email protected] ha
scritto:

alguna actualización para v1.12? Esperaba poder implementar esta función. Este es
demostrando ser una característica muy perdida.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/osTicket/osTicket/issues/2242?email_source=notifications&email_token=AAA7RCS7GPKBINUUWVH3VGTP3JEVZA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DFVDVREXWG43V ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAA7RCXNJBKUKAJBDC7YIW3P3JEVZANCNFSM4BKXEBBQ
.

He intentado agregar @mudul MOD en v1.12 durante unos días, ahora el agente puede responder por correo electrónico.
Sin embargo, el sistema trata la respuesta como una respuesta del usuario (es decir, el color azul en el sistema) y no envía un correo electrónico de alerta al creador del ticket / colaboradores. (La segunda respuesta en la imagen de abajo en realidad es una respuesta de un agente por correo electrónico).

La última respuesta la realiza la cuenta del agente en la plataforma osticket, por lo que funciona correctamente.

La estructura general del código es bastante diferente entre el MOD v1.9 original y el v1.12 más nuevo.
Simplemente me quedé aquí y no puedo averiguar qué parte debería modificar.
He adjuntado la v1.12 class.ticket.php & class.thread.php con estos comentarios.

¿Alguien puede darme algunas pistas? o comparte tu MOD para v1.12?

Muchas gracias.
V1.12_thread y ticket.zip

Solo estoy probando v1.12.
Si consigo que funcione, se lo haré saber.
-As

He creado un parche actualizado para v1.12 que parece estar funcionando. No está en mi instancia de producción, pero mis pruebas indican que está funcionando bien ahora (creo). Hubo algunos cambios en la lógica de análisis de correo electrónico y el manejo de subprocesos, razón por la cual el parche anterior ya no funcionaba.

Creo que alguien preguntó en un momento si este parche funcionará respondiendo al correo electrónico asignado al ticket. No uso esto, pero parece que también funciona.

Este mod no es compatible en absoluto, y no garantizo que se actualice o arregle nunca. Pero si ve algún error importante mientras usa la v1.12 (no cualquier otra versión) con este parche instalado, intente publicar una publicación aquí para que pueda estar al tanto.

ace.patch.txt

-As

@ acetwenty8
¡Está funcionando bien! ¡Muchas gracias!

Hola @ acetwenty8 ,

Apliqué su archivo y actualización y parece funcionar correctamente. Es capaz de comparar y detectar los correos electrónicos de los agentes y hacer lo que debería.
Pero en nuestro entorno, cuando respondemos al usuario final, utilizamos el correo electrónico de soporte técnico. Que, en osTicket, se asigna como correo electrónico del sistema.
Cuando respondemos con eso, el código lo ignora, por lo que no se agrega ningún mensaje al ticket.
¿Hay alguna forma de hacer que el código también se verifique para el correo electrónico del sistema?

Gracias,
Leco

@lecobarros No tengo claro qué es el correo del sistema, pero creo que esto se refiere a la dirección de correo electrónico que osTicket verifica para recibir nuevos tickets del usuario. No creo que lo que estás diciendo funcionara en versiones anteriores del parche, ¿correcto?

Por lo que recuerdo haber trabajado con el código, tienen controles específicos para evitar esto. Lo más probable es que se deba a que podría crear un bucle de correo electrónico infinito con esta situación. Probablemente no recomendaría desactivar las comprobaciones por ese motivo.

En class.thread.php dentro de la función postEmail, creo que es este código aquí.

        // Don't process the email -- it came FROM this system
        elseif (Email::getIdByEmail($mailinfo['email'])) {
            return false;
        }

@ acetwenty8 , esa es la dirección de correo electrónico de la que estoy hablando, sí. Y esta es la primera vez que pruebo ese parche, pero según tu explicación, tienes razón, probablemente ese es el control que lo previene.

Tiene sentido que pueda crear un bucle infinito. Pero deshabilitamos todas las respuestas automáticas, por lo que eso podría evitarlo. Pero lo pensaré más, si deberíamos hacerlo o no.

¡Gracias por la ayuda con esto!

@ acetwenty8 y @ vincentchan925 ,

Por lo que probaron, ¿se está tratando correctamente el correo electrónico de los colaboradores?
Por mi parte, esos no se suman al hilo.

@ acetwenty8 y @ vincentchan925 ,

Por lo que probaron, ¿se está tratando correctamente el correo electrónico de los colaboradores?
Por mi parte, esos no se suman al hilo.

Sí, los colaboradores son tratados correctamente.
Se agregan al ticket automáticamente.

Modifiqué los archivos class.thread.php y class.ticket.php para incluir el último código ofrecido por Ace, pero cuando lo hago, el proceso de inicio de sesión de osTicket se interrumpe. Ya no muestra nuestro logotipo, y mientras las credenciales de inicio de sesión se reciben y se autorizan correctamente, el técnico nunca es redirigido fuera de /scp/login.php a / scp. Si el técnico intenta manualmente ir a / scp después de autenticarse, funciona, pero obviamente algo en el código no funciona. Estamos en v1.12.2

Si alguien estuviera dispuesto a brindar alguna orientación o una copia de sus archivos de trabajo, ¡estaría muy agradecido!

@ njohn858

No se probó con v1.12.2, solo 1.12

Parece que puede estar intentando editar los archivos manualmente, y existe una alta probabilidad de que se produzcan errores al hacerlo. Deberías usar el comando patch para aplicar el diff que creé.

-As

¡Ah! Eso podría solucionarlo, ¡lo intentaré! ¡Gracias!

Perdona mi ignorancia, pero no sé cómo usar el comando de parche ... ¿podrías darme alguna guía o indicarme un tutorial o algo así?

@ acetwenty8

Para referencia futura, si desea hacer un mod más "fácil de seguir", debe bifurcar el repositorio, hacer una bifurcación en su bifurcación y vincular a las personas con la bifurcación. Si la gente no sabe cómo usar las ramas, puede proporcionar un enlace a una diferencia o parche en lugar de crear uno manualmente y cargarlo como un archivo.

Esqueleto de enlace diferencial de rama:
https://github.com/osTicket/osTicket/compare/osticket:<branch-name>...<account-name>:<branch-name>.diff

Ejemplo de trabajo de enlace de diferencia de rama:
https://github.com/osTicket/osTicket/compare/osticket:develop-next...jedikev:issue/redactor-quicknotes.diff

(Si desea vincular a un parche en lugar de una diferencia, simplemente reemplace .diff con .patch ).

De esta manera, si alguien tiene problemas con su mod, puede crear un problema en su bifurcación para que el hilo del problema original no esté abarrotado de problemas de mod no compatibles que no estén relacionados con el problema original en cuestión.

Salud.

Gracias acetwenty8
Probado trabajando en 1.12.2

estamos trabajando con osticket v1.14.1
esta función no funciona

por favor ayuda
@ acetwenty8 @molul

trabajando con 12.5

Gracias por hacérmelo saber

Il giorno lun 6 gen 2020 alle 01:28 lyk2020 [email protected] ha
scritto:

trabajando con 12.5

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/osTicket/osTicket/issues/2242?email_source=notifications&email_token=AAA7RCUHI4E6DVU6E7ZALSLQ4J3MPA5CNFSM4BKXEBB2YY3PNVWWK3TUL52HS4DW2MVREXWWK3TUL52HS4DF2MVREXWWK3TUL52HS4DFMVREX
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAA7RCSFIUH7OHR22YNEGRDQ4J3MPANCNFSM4BKXEBBQ
.

>

Julien Buratto
Tel: +39.335.6359.515

Acabo de actualizar mi instalación anterior con el repositorio GIT, que informa ser: 1.12-git y lo parcheé con el comando file + patch. No soy muy bueno en GIT, ¿alguien puede ayudar en el proceso de enviar esta modificación a github?

@ acetwenty8

Para referencia futura, si desea hacer un mod más "fácil de seguir", debe bifurcar el repositorio, hacer una bifurcación en su bifurcación y vincular a las personas con la bifurcación. Si la gente no sabe cómo usar las ramas, puede proporcionar un enlace a una diferencia o parche en lugar de crear uno manualmente y cargarlo como un archivo.

Esqueleto de enlace diferencial de rama:
https://github.com/osTicket/osTicket/compare/osticket:<branch-name>...<account-name>:<branch-name>.diff

Ejemplo de trabajo de enlace de diferencia de rama:
https://github.com/osTicket/osTicket/compare/osticket:develop-next...jedikev:issue/redactor-quicknotes.diff

(Si desea vincular a un parche en lugar de una diferencia, simplemente reemplace .diff con .patch ).

De esta manera, si alguien tiene problemas con su mod, puede crear un problema en su bifurcación para que el hilo del problema original no esté abarrotado de problemas de mod no compatibles que no estén relacionados con el problema original en cuestión.

Salud.

¿Podrías ayudarme a solucionar fácilmente "paso a paso" con GIT? :-D

Hola a todos,

¿Alguna actualización para que esto funcione en v1.14.2?

Como espectáculo individual, ¡poder usar un dispositivo móvil para responder a los clientes rápidamente marcaría la diferencia! - ¿Por qué no puede ser una configuración para habilitar / deshabilitar la funcionalidad?

¡Gracias!

me pregunto si esto se puede hacer con un complemento,

Un escenario sería realmente agradable. +1 @ davewatson91

Se creó una bifurcación con el parche https://github.com/osTicket/osTicket/issues/2242#issuecomment -513056652 aplicado

https://github.com/YurkoWasHere/osTicket/tree/1.15.x_patched

Parece funcionar en 1.15.x
Esto no se puede escribir como un complemento, ya que cambia fundamentalmente la forma en que se procesan los mensajes.

Usa el parche manualmente

Cómo aplicar el parche de la cáscara

poner ace.patch.txt de la publicación en la carpeta include/ luego desde la ejecución de shell
patch -p0 < ace.patch.txt

Cómo parchear archivos reemplazando 1.15.x

En la carpeta include reemplace los siguientes dos archivos
https://raw.githubusercontent.com/YurkoWasHere/osTicket/1.15.x_patched/include/class.ticket.php
https://raw.githubusercontent.com/YurkoWasHere/osTicket/1.15.x_patched/include/class.thread.php

@YurkoWasHere
Muchas gracias por el parche y la descripción. Lo intenté con parches hace unos años, pero el problema es que una vez que se lanza un nuevo osticket, dejan de funcionar. Esto lo hace insoportable.

¿Sabes si hay alguna razón por la que esto no puede ser una configuración? No es un parche, sino una configuración con el código proveniente de osticket y no de un parche.

pero el problema es que una vez que se lanza un nuevo boleto, dejan de funcionar. Esto lo hace insoportable.

Estoy de acuerdo. La buena noticia es que este parche se aplica de 1.12 a 1.15 sin modificaciones. Entonces esa es una buena señal.

¿Sabes si hay alguna razón por la que esto no puede ser una configuración? No es un parche, sino una configuración con el código proveniente de osticket y no de un parche.

Dado que esto no se puede hacer como un complemento, la única forma de hacer que este parche no sea necesario cada vez es

• Implemente este parche en osTicket. Este medio típico:
  
  
  
  • Asegúrese de que el parche no sea un truco, sino un código de calidad.
  
  
  • Agregue un interruptor de configuración para habilitar / deshabilitar la función
  
  
  • Crea un PR contra osTicket
  
  
  • Convencer a osTicket de que esta es una función que quieren seguir apoyando
  
  
  • Consiga el PR fusionado en una nueva versión
  
  
• Haga que alguien mantenga una bifurcación pública de osTicket con un parche actualizado

Creo que la segunda opción es más factible a corto plazo. También creo que al hacer que este parche sea más accesible (en lugar de intentar perder tiempo leyendo todo el hilo para encontrar el archivo zip y aplicarlo) para que pueda usarse, alentaría la fusión exitosa con la primera opción.

PD: mis 2 centavos en la situación

Estaba pensando en la primera opción. No estoy seguro de si hay argumentos y razones por las que esta no es una opción. Supongo que los hay, pero no puedo encontrarlos. Lo que estoy tratando de entender es: si hay un PR, el osTicket lo aceptará.

No puedo hablar por esta situación en particular

Sé que en los otros proyectos los RP no se aceptaron debido a la decisión del desarrollador central interno de un proyecto de que no mantendrían una característica en el futuro.

Además, la calidad del código podría ser un factor importante

@thebravoman @YurkoWasHere

Por favor lee:

• https://github.com/osTicket/osTicket/issues/2242#issuecomment -353081378

Salud.

@JediKev gracias, lo leí. El comentario fue hace 3 años. ¿Ha cambiado algo desde entonces? También menciona que ha agregado esto a una hoja de ruta futura. ¿Hay algún caso en el que no acepte un RP sobre esto?

@thebravoman

¿Ha cambiado algo desde entonces? También menciona que ha agregado esto a una hoja de ruta futura.

No en este momento. Todavía está en nuestra hoja de ruta para un posible desarrollo futuro.

¿Hay algún caso en el que no acepte un RP sobre esto?

Hay muchas razones por las que una solicitud de extracción no sería aceptada, por ejemplo, si no está escrita correctamente, si no cubre todas las bases, si tiene errores, etc. En este caso particular, la función va mucho más allá de simplemente permitir las respuestas del agente a través de correo electrónico que se agregará a un hilo como respuesta.

Salud.

Personalmente,
He parcheado nuestra versión anterior para incluir la respuesta del agente y no lo hice.
actualizar / actualizar desde entonces, ya que todas las características que nos interesan son
laboral.

Julien Buratto
Amministratore
Linkas Srl
p: +390230321419 m: +393356359515
f: +390240700321
a: Via Cartesio 2
20124 - Milán (MI)
w: www.linkas.it e: [email protected]
http://julien.burat.to/

Il giorno lun 4 gen 2021 alle ore 17:11 JediKev [email protected]
ha scritto:

@thebravoman https://github.com/thebravoman

¿Ha cambiado algo desde entonces? También menciona que ha agregado esto
a una hoja de ruta futura.

No en este momento. Todavía está en nuestra hoja de ruta para un posible futuro
desarrollo.

¿Hay algún caso en el que no acepte un RP sobre esto?

Hay muchas razones por las que una solicitud de extracción no sería aceptada, como si
no está escrito correctamente, si no cubre todas las bases, si tiene errores,
etc. En este caso particular, la función es mucho más profunda que simplemente
permitiendo que las respuestas del agente por correo electrónico se agreguen a un hilo como respuesta.

Salud.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/osTicket/osTicket/issues/2242#issuecomment-754065645 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAA7RCXWFSS3MNPZ2RIGEXDSYHSD5ANCNFSM4BKXEBBQ
.

Gracias @JediKev. No pude hacer mi pregunta con claridad. Lo intentaré otra vez.
Contexto:
La comunidad osTicket ha preguntado acerca de esta función en varias ocasiones durante los últimos 5 años.
El equipo de osTicket ha agregado esto a la hoja de ruta
La comunidad osTicket ha intentado proporcionar comentarios, discusiones y parches de versiones desde al menos 10 (creo)
El equipo de osTicket está tratando de mantener un producto que funcione bien y de buena calidad.

Situación:
No existe tal característica.

Mi pregunta:
¿Hay razones subyacentes y creencias, que el equipo de osTicket sostiene, que tal característica no debería existir en absoluto? ¿Está esto alineado con la visión y dirección de osTicket o está en conflicto con la comprensión de lo que debería ser osTicket?

Dado que un PR no tiene errores, funciona para todos los casos, sigue las convenciones adecuadas, ¿hay alguna razón por la que me falta y no veo que dicho PR sea rechazado? ¿Existen otras razones, excepto la falta de recursos, por las que esta característica no existe? ¿Algo que se debe tener en cuenta?

Mi punto es que no vale la pena dedicar mucho tiempo a preparar un PR, si hay alguna razón, no será aceptado incluso si cumple con todos los requisitos.

Confirmado trabajando en 1.15.2

Encontré un error

Cuando el agente responde por correo electrónico, las variables no funcionan. O no llegan o están escritas. ver adjunto

De hecho, es extraño. las variables resaltadas en amarillo funcionan, las rojas no.