Foro - Perl en Español

¡ Hola colegas !

Existen una variedad de sistema de tiques, yo lo haría muy fácil.
Obtener los datos de un mail no es complicado, Uds. se refieren a cómo captar ese email.

Si utilizan un sistema pop3, recibirían los "reclamos/incidencias" (tiques), ahí solo queda aprender el protocolo de transmisión de comandos y utilizarlos.

Sería muy simple, un mail directo a la casilla o desde un webmail podrían recibir los tiques. Podrían centralizarlo en una web en la intranet en caso de ser un helpdesk on site, si trabajan para cubrir soporte móvil, igual pueden usar una web.

Yo les recomendaría que usen algún sistema open source: http://osticket.com/tour/

Y luego para organizarse internamente utilizar taskfreak.

Voy a ver si les encuentro algún otro sistema de tiques, en español sobre todo.

teofederico escribiste:Existen una variedad de sistema de tiques, yo lo haría muy fácil.

El tema no trata de resolver un problema de tiques, sino de hacerlo

teofederico escribiste:Obtener los datos de un mail no es complicado, Uds. se refieren a cómo captar ese email.

Sí, el título del tema lo dice así.

teofederico escribiste:Si utilizan un sistema pop3, recibirían los "reclamos/incidencias" (tiques), ahí solo queda aprender el protocolo de transmisión de comandos y utilizarlos.

El protocolo POP3 se refiere a la transmisión de correos desde el PostOffice (servidor de correo) hasta el gestor de correo del cliente. Pero en este caso no es necesario aprender ningún protocolo: en Perl ya existen los módulos que nos permiten dialogar con el servidor usando POP3, IMAP y otros, y entregarnos el contenido de las bandejas de entrada, la lista de mensajes, y cada correo por separado.

teofederico escribiste:Sería muy simple, un mail directo a la casilla o desde un webmail podrían recibir los tiques. Podrían centralizarlo en una web en la intranet en caso de ser un helpdesk on site, si trabajan para cubrir soporte móvil, igual pueden usar una web.

Sí, es lo que está comentado: un proceso periódico (como el cron, por ejemplo), lanza nuestro programa, accede al buzón, lee los mensajes, extrae la información, y crea los tiques, que, normalmente, serán guardados en una base de datos, o saldrán por pantalla, o activarán un sirena luminosa o una bocina o un motor que mueva algo.

teofederico escribiste:Yo les recomendaría que usen algún sistema open source: http://osticket.com/tour/
Y luego para organizarse internamente utilizar taskfreak.
Voy a ver si les encuentro algún otro sistema de tiques, en español sobre todo.

Gracias, pero el objetivo del tema no es el uso de sistemas de tiques, sino de transformar los correos que llegan a tiques para luego mostrarlos en web.

Es claro que hay sistemas ya hechos que hacen justamente eso (recibir tiques por correo, guardarlos en la base de datos para luego ser mostrados en la web), pero aquí intentamos dar una respuesta a la gente que quiere hacérselo en lugar de depender de un producto hecho por otros (esto tiene ventajas e inconvenientes).

Las ventajas de usar un sistema prefabricado son claras: enseguida empiezas a trabajar. Solo tienes que instalarlo.

Los inconvenientes:
* debes ajustarte a su forma de trabajar
* no siempre está en tu idioma
* si es un servicio web que no puedes descargar y instalar en tu máquina, debes ajustarte a la legislación local tuya, para ver si se permite el envío de información sensible a otro país (algunas veces, no es posible)
* si hay errores en el programa, depende de si dispones del código fuente, quizás puedas arreglarlos. Sino, tendrás que informar y esperar a que los arreglen, y comenzar el proceso de instalación o actualización. Esto también quiere decir que debes estar al tanto de la presencia de esos errores. Debes suscribirte a los boletines de seguridad de la aplicación, para estar atentos de nuevos errores y correcciones.

Los más jóvenes son propensos a instalar software prefabricado, porque obtienen resultados inmediatos. Los más mayores, se piensan a veces en la posibilidad de hacerlo uno mismo, al tener la experiencia de que ese software prefabricado, en realidad, les ha llevado casi el mismo tiempo de mantenimiento, que de desarrollo.

Naturalmente, esto es mi humilde opinión, que, quizás, no sea la más correcta.

Hay casos en los cuales no vas a programar tu mismo la solución, como por ejemplo, un Office. En esa situación, no te queda más remedio que buscar una solución ya hecha (LibreOffice) o comprar una licencia de una solución cerrada (Office). Con la licencia, va incluido el compromiso de la empresa en que arreglará los errores encontrados.

En Perl, el más famoso, es el Request Tracker, de la empresa Best Practical. Es el sistema que se usa para informar de errores a los programadores que contribuyen en CPAN. Como se ve en esa primera página, se puede informar de errores desde la web, desde el correo electrónico, y a través del comando perlbug.

Y, obviamente, en CPAN, hay un montón de módulos, al respecto.

En resumidas, la idea es aportar, ya sea comentando ideas, bases o lo que salga.
En mi caso, es lo que me salió a mi.

¡¡ Saludosss !!