Recientemente hemos recibido permiso para escribir en este subforo algunos How-To, por lo que me he tomado la iniciativa para enseñaros algunas pequeñas modificaciones que realizo para permitir la casuistica de mi empresa. Usalo bajo tu propio riesgo.
INTRODUCCION:
En versiones hasta la 3.0.11 (version donde se realiza el how-to) disponemos de un limite maximo de 16 campos libres (13,14 si se usa ITSM). Ante posibles necesidades tales como un Flujo de trabajo dividido por variables de primer nivel (incident, request,...) seguidas de variables de segundo nivel (Colas, Servicios,...) se precisa reformar completamente los campos libres requeridos al usuario como por ejemplo un Catalogo de peticiones.
Lo primero de todo es saber como funcionan los formularios (freetext) en otrs. Los freetext son campos libres dispuestos en los archivos de configuracion (xml) bajo la ruta /$HOMEOTRS/otrs/Kernel/Config/Files. Al crear un ticket desde el frontal cliente se cargan estos freetext en los diferentes campos y una vez selecionados/escritos al hacer submit se insertan conjuntamente con el registro principal del ticket en la tabla ticket en sus respectivas columnas freetext1, 2 ,...
Por tanto, la pagina Nuevo ticket es el archivo de ultimo nivel antes de registrar nuestro ticket, y en el podemos modificar a placer nuestros 16 campos libres indiferentes de si no hay configuracion para ellos o lo que contuvieran. Para ello inicialmente activaremos tantos freetext como nuestra solicitud con mayor numero de campos en el sysconf en Ticket::Frontend::CustomerTicketMessage###TicketFreeText.
Despues para modificar los freetext nos serviremos de las actualizaciones de pagina dentro del archivo dtl /$HOMEOTRS/otrs/Kernel/Output/HTML/Standard/CustomerTicketMessage.dtl (funcion Nuevo ticket del frontal cliente)
MODIFICACION:
Primero nos situamos al final del fichero dtl, en este apartado realizaremos los cambios pertinentes.
Code: Select all
<!-- dtl:js_on_document_complete -->
<script type="text/javascript">
Core.Customer.InitFocus();
>>> INSERTA AQUI <<<
</script>
<!-- dtl:js_on_document_complete -->Code: Select all
function hide (){
document.getElementById('TicketFreeText1').style.display = 'none';
document.getElementById('LabelTicketFreeText1').style.display = 'none';
}
switch ($('#Dest').val() ) { //Dest recoge el valor del desplegable cola seleccionada (Tiene un formato id||nombre_cola)
case "3\|\|Junk": // caso de cola Junk, escaparemos los | para que los reconozca como literal.
switch ($('#TypeID').val()) { //TypeID recoge el identificador del tipo de solicitud, en mi caso tengo (incident 1,request 2)
case "2": //caso request de la cola Junk
hide()
//El freetext1 corresponde a mi catalogo de peticiones (desplegable recargado por cada tipo de solicitud)
document.getElementById('TicketFreeText1').style.display = 'block'; //con block hacemos visible el desplegable
document.getElementById('LabelTicketFreeText1').style.display = 'block';
//inicializamos el indice del desplegable (borrando su contenido)
document.forms['compose'].TicketFreeText1.options.length= null;
// rellenamos con los nuevos valores, el primer valor es el mostrado en el desplegable, el segundo valor es insertado en BBDD
document.forms['compose'].TicketFreeText1.options[0]= new Option("Borrado cuentas","borrado","","");
document.forms['compose'].TicketFreeText1.options[1]= new Option("Alta cuentas","alta","","");
document.forms['compose'].TicketFreeText1.options[2]= new Option("Modificacion cuentas","modificacion","","");
break;
default: //caso que no tengamos controlado, defecto
document.compose.RichText.value = "Cola " + $('#Dest').val() + "<br/>Tipo de Solicitud " + $('#TypeID').val();
//con none ocultamos el campo
document.getElementById('TicketFreeText1').style.display = 'none';
document.getElementById('LabelTicketFreeText1').style.display = 'none';
}
break;
default:
}
Esta funcionalidad es tan grande como vuestros conocimientos/ganas de Javascript tengais. Podemos retocar al mismo tiempo los archivos dtl referentes a la visualizacion del agente, creaciones ticket mail, creaciones de ticket phone con esta misma mecanica entre otros; o definir un SLA para una casuistica especifica manteniendo ocultos los desplegables de sla para el cliente con funciones .selected.
Para los que dispongan de la nueva version 3.1, sigue funcionando ya que los campos dinamicos son renombrados:
TicketFreeText1 => DynamicField_TicketFreeText1
LabelTicketFreeText1 => LabelDynamicField_TicketFreeText1
Espero que os sirva de ayuda, y os anime a contribuir con vuestras experiencias.
Un saludo.
