Sistema de gestión de tickets: plataforma de código abierto O construir nosotros mismos

Estamos en el proceso de proponer una opción de tecnología para un sistema de gestión de tickets (piense en ticket en el sentido similar a "tarea de trabajo", "informe de incidente" o "caso de soporte"). Obviamente, no puedo exponer la especificación completa aquí, pero en resumen, podemos pensar en el sistema como un sistema de gestión de tickets con estos requisitos especiales:

• El formato de las entradas debe ser altamente, por no decir totalmente, configurable . Es decir, debemos poder cumplir con un modelo de datos que nuestro cliente especifica para el aspecto de un ticket con una cantidad de campos de datos que el reportero del ticket debe completar en diferentes formatos: campos de opción múltiple, campos de texto, campos numéricos , opción única. Obligatorio y Opcional. Etc. Ese es solo un requisito mínimo, sin embargo, nos sentiríamos mucho más cómodos si  se pudieran especificar en el sistema varios  modelos de datos diferentes o 'plantillas de boletos'/'tipos de boletos'.

• Así mismo los diferentes estados en los que puede estar un ticket deben ser configurables . Necesitamos poder especificar nuestra propia taxonomía de dichos estados (por ejemplo, "nuevo", "abierto", "cerrado", "pendiente de aprobación", etc.) y al pasar de un estado a otro queremos poder especificar que ciertos campos de datos se bloquearán para editarlos u ocultarlos.

• Debemos poder desencadenar acciones tanto cuando cambia el estado de un ticket como cuando cambia una propiedad del ticket. Dichas acciones pueden ser enviar un correo electrónico o ejecutar un script que extraiga y transfiera datos, etc.

• papeles _ La implementación de funciones en el sistema debe ser lo suficientemente flexible como para que se ajuste a una instalación de tipo multiusuario . Es decir, necesitamos poder agrupar usuarios en organizaciones. Y dentro de cada organización necesitamos un tipo de usuario con privilegios altos (o administrador de la organización si lo desea) con derecho a crear usuarios con privilegios bajos para esa organización. Además, necesitamos usuarios globales con privilegios bajos, que puedan realizar tareas simples como ver y editar algunas propiedades de los tickets en todas las organizaciones.

• Necesitamos poder guardar y mostrar el historial de ediciones en el ticket.

• Necesitamos poder configurar el sistema para que funcione con una base de datos cifrada .

• Cambie el nombre de las vistas, titulares, etc. en la interfaz de usuario.

• Un buen soporte para producir informes y estadísticas es una ventaja. La arquitectura conectable donde podemos escribir nuestros propios módulos también es una ventaja.

La pregunta es, ¿tenemos que construirlo nosotros mismos o existe un sistema/marco de código abierto que sea factible para esto? Los candidatos podrían ser Request Tracker, OTRS, Redmine. ¡O Mantis o SIÉNTATE! (Sin embargo, tenemos un sesgo en el grupo en contra de buscar algo construido en PHP). Otras sugerencias son bienvenidas si realmente encajan con las especificaciones anteriores. Agradecería escuchar alguna experiencia relevante aquí, si tiene experiencia tratando de modificar uno de los sistemas de tickets de código abierto de una manera similar o simplemente la experiencia suficiente en cualquiera de ellos para decir si los ajustes/requisitos son factibles. Además, para el caso de que terminemos construyéndolo nosotros mismos (Java, RoR u otros, todo lo posible excepto .NET o PHP), estoy interesado en consejos inteligentes sobre marcos de desarrollo/libs que podrían ser útiles al desarrollar este tipo de sistema.