Prioridad de los tickets

[doriath]

Saludos de nuevo,

Editado por Doriath

Redefino la pregunta,

Me explico:

Quiero modificar la prioridad de los tickets en función de cambios hechos en ellos, es decir si se hace alguna modificación en el ticket, nota, decisión, etc
que se le asigne una prioridad máxima para que el resto de agentes de la cola los vean como prioritarios.

Cuando se asigna el ticket a otro propietario ponerle una prioridad media o normal.

Todo esto quiero conseguir que los haga de forma automática, sin tener que hacer cambios en la prioridad de forma expresa, con el desplegable que se pueda habilitat
en el formulario.



Doriath

[doriath]

Además quiero cambiar los colores relacionados con las prioridades.


Doriath

[miguelmz]

Son css's los tienes definidos /opt/otrs/var/httpd/htdocs/skins/Agent en funcion del tema que tengas seleccionado sera una u otra ruta, el de por defecto es este: /opt/otrs/var/httpd/htdocs/skins/Agent/default/css/Core.Default.css

Las veras definidas en spans, solo tienes que cambiar el numero hexadecimal por un nuevo color. Si vas a toquetear prioridades estas te aparecen ordenadas por id, asi que seria poner por ejemplo uno mas pero con 6, en teoría (no lo he probado).

Code: Select all

.Flag span.PriorityID-1 {
    background-color:#03c4f0;
}

.Flag span.PriorityID-2 {
    background-color:#83bfc8;
}

.Flag span.PriorityID-3 {
    background-color:#cdcdcd;
}

.Flag span.PriorityID-4 {
    background-color:#ffaaaa;
}

.Flag span.PriorityID-5 {
    background-color:#ff505e;
}

Un saludo.

[doriath]

Saludos Miguel, yo y mis problemas, no se me cambian los colores, supongo que será por la caché de los css, la Puedo borrar?

En relación al tema este, no sabes como se pueden cambiar las prioridades de los tickets en función de acciones realizadas sobre ellos?,
la idea es ponerles una prioridad alta al asignarles un propietario , por ejemplo.

Con el generic agent lo único que puedo diferenciar son cambos en el ticket, pero no distinguir entre que tipo de cambio, y necesito
saberlo para asignar una prioridad en función del tipo de cambio que se le ha hecho al ticket.

Doriath

[miguelmz]

Tienes un script que te borra la cache en /opt/otrs/bin/otrs.DeleteCache.pl --all, aunque creo que no deberia interferir aqui la cache con un css deberia ser directo, comprueba a ver si has puesto bien el hexadecimal- Y si la cache siempre puedes borrarla, en especial la de javascript que crece muy rapido, solo ya sabes se hara mas lento.

Si quieres algo mas de colores deberias echar un vistazo a esto http://opar.perl-services.de/bin/index. ... viewHooked.

Respecto a lo que comentas de cambiar prioridades automaticamente depende de lo que quieras, ten en cuenta que si usa ITSM y tienes activos el impacto y la criticidad estas prioridades tambien te van a cambiar en funcion de ellas, puedes ver el mapa de cambios en la pestaña Administrar > "Categoria - Impacto - Prioridad" o "Urgencia - Impacto - Prioridad".

Si lo he entendido bien, cuando hago un cambio de propietario modificar la prioridad a normal, esto podria hacerlo entrando en esa Accion. Te fijas la url el nombre de la accion y buscas el modulo perl con ese nombre en /Kernel/Modules y alli podria emplear un objeto DBObject para hacer directamente una actualizacion sobre bbdd en ese registro. Esto es extensible al resto, bastara con buscar las otras action y hacer lo mismo, ahora unas anotaciones:

- Para usar un DBObject necesitas tener definido la creacion de ese objeto en la funcion new del perl que siempre tendra.
- Algunas Action son solamente llamadas al modulo action padre AgentTicketActionCommon, si tienes varias llamadas a este puedes meterte en la funcion run e identificar que action es usando un $Self->{Action}, esto te devolvera el nombre de la Action que ha ejecutado este perl en concreto, puedes usarlo en diferentes if para realizar tus cambios sobre el ticket.
- Si necesitas realizar una consulta para ver atributos del ticket en el momento de la ejecucion del perl puedes guardar en un hash la llamada a la funcion TicketGet que sera mas rapido que un DBObject.
- Controla muy bien que esto se haga a la hora de insercion de cambios, no solo en lanzamiento (por si hay cancelacion de cambio propietario, etc).
- Un ejemplo de DBObject de actualizacion sobre una BBDD seria este (donde variable contendria el id de la nueva prioridad):

Code: Select all

$Self->{DBObject}->Do(
	SQL => 'UPDATE ticket SET ticket_priority_id = ? WHERE ticket_id = ?',
	Bind => [ \$variable, \$Param{TicketID}, ]
				);

Un saludo.

[doriath]

Saludos de nuevo,

Finalmente he optado por otra solución no tan drástica, me explico

consiste en configurar para todos los módulos donde hacer modificaciones a los tickets el menú de selección de la prioridad, además de asignarle una
prioridad por defecto, la que me interese cambiar después de la modificación del ticket.

En el archivo AgentTicketActionCommon.pm se fuerza la carga de la prioridad por defecto como prioridad seleccionada en el menú de selección
en la subrutina _Mask comentada como #get Priority

Code: Select all

     #       $Priority{SelectedID} ||= $Param{PriorityID};
     if ( !$Self->{Config}->{PriorityDefault} ) {
	    $Priority{SelectedID} ||= $Param{PriorityID};
     }
     else
     {
	     $Priority{SelectedID} = $Self->{Config}->{PriorityDefault};
     }

Con la condición de que si no está activada la prioridad por defecto se carge la prioridad que trae el ticket.
El hecho de activar la carga del desplegable y de la prioridad por defecto es por que he visto que si no se activan los valores no estarán
disponibles en el controlador.

El siguiente paso consiste en ocultar el menú directamente en el archivo .dtl mediante javascript para evitar que el usuario la pueda cambiar
y de la impresión que se cambia de forma automática.

De esta forma conseguimos el poder cambiar la prioridad que se asignará al ticket desde la configuración del sistema y no tener un valor siempre fijo.

A ver que os paree esta solución y espero vuestros comentarios.

Doriath.

[miguelmz]

Es interesante, pero ten cuidado con las funciones de evento change, acuerdate de eliminar en el refresco la prioridad que dices o cualquier cambio que hagas sera inutil porque el AJAX recargara los valores iniciales.

Core.AJAX.FormUpdate($('#NewEmailTicket'), 'AJAXUpdate', 'TypeID', ['NewUserID', 'NewResponsibleID', 'NextStateID', 'PriorityID', 'ServiceID', 'SLAID', 'SignKeyID', 'CryptKeyID', 'TicketFreeText1', 'TicketFreeText2', 'TicketFreeText3', 'TicketFreeText4', 'TicketFreeText5', 'TicketFreeText6', 'TicketFreeText7', 'TicketFreeText8', 'TicketFreeText9', 'TicketFreeText10', 'TicketFreeText11', 'TicketFreeText13', 'TicketFreeText14', 'TicketFreeText15', 'TicketFreeText16', 'To', 'Cc', 'Bcc'],'');

Ahora bien dejas solo 2 opciones de prioridad Defecto y seleccionada, si quisieras aumentar las capacidades de la modificacion podrias jugar con $Data y javascript en los dtl.

Te comento brevemente:
El AgentTicketActionCommon.pm va guardando una serie de elementos en un hash llamado Param, este hash contiene toda serie de datos con sus respectivas claves. Al no existir ningun control ordenado de ellas no hay problemas en adulterar dicho hash con lo que te interese. Despues este perl llama al Layout.pm que a su vez llamara al layoutticket.pm dentro de System, estos perl realizan una sustitucion de las keys del hash que se les pasa en la llamada (Param) con las variables descritas en los dtl; de esta forma se generan los html.

Te pongo un ejemplo, podria generarme una construccion de unas tags html ocultas desde el pm (donde puedes controlar todas las circunstancias que desees) y despues realizar en el dtl bucles en javascript que en funcion de lo que se encuentre en esa tag modifique mi seleccion a mi antojo. Este tipo de arreglo es muy util si quieres controlar todas las posibles casuisticas para formularios completos desde lado cliente, porque javascript no permite el acceso con la BBDD, por esto en muchas ocasiones es necesaria la construccion dinamica de tags ocultas desde los pm para realizar una especie de tablas digamos donde alojar los datos que necesitaremos consultar desde javascript como si fuera una especie de bbdd.


Un saludo.

[doriath]

Es interesante, pero ten cuidado con las funciones de evento change, acuerdate de eliminar en el refresco la prioridad que dices o cualquier cambio que hagas sera inutil porque el AJAX recargara los valores iniciales.
Core.AJAX.FormUpdate($('#NewEmailTicket'), 'AJAXUpdate', 'TypeID', ['NewUserID', 'NewResponsibleID', 'NextStateID', 'PriorityID', 'ServiceID', 'SLAID', 'SignKeyID', 'CryptKeyID', 'TicketFreeText1', 'TicketFreeText2', 'TicketFreeText3', 'TicketFreeText4', 'TicketFreeText5', 'TicketFreeText6', 'TicketFreeText7', 'TicketFreeText8', 'TicketFreeText9', 'TicketFreeText10', 'TicketFreeText11', 'TicketFreeText13', 'TicketFreeText14', 'TicketFreeText15', 'TicketFreeText16', 'To', 'Cc', 'Bcc'],'');

Ya veo, no se si estoy en lo cierto, pero supongo que a los valores iniciales a los que te refieres son los precargados, los que obligo a cargar en el desplegable que oculto,
Debería eliminar la recarga de PriorityID del ajax?, la edición y modificación del código la tengo un poco limitada, sólo cambios imprescindibles.
De momento funciona bien, al hacer cambios en otros campos del formulario se recarga el desplegable de prioridad pero no cambia el valor que tiene seleccionado.
Además aunque ya combie el valor de ese desplegable al recargarse no cambia de valor. ¿Con que campos es posible que cambie el valor cargado en el desplegable?

Te pongo un ejemplo, podria generarme una construccion de unas tags html ocultas desde el pm (donde puedes controlar todas las circunstancias que desees) y despues realizar en el dtl bucles en javascript que en funcion de lo que se encuentre en esa tag modifique mi seleccion a mi antojo. Este tipo de arreglo es muy util si quieres controlar todas las posibles casuisticas para formularios completos desde lado cliente, porque javascript no permite el acceso con la BBDD, por esto en muchas ocasiones es necesaria la construccion dinamica de tags ocultas desde los pm para realizar una especie de tablas digamos donde alojar los datos que necesitaremos consultar desde javascript como si fuera una especie de bbdd.
Un saludo.

Esto es interesante, podrías poner algún ejemplo de código del lado servidor y del lado cliente?

Doriath.

[miguelmz]

Asi sin mas no tendrias problemas porque las prioridades son siempre las mismas y al no cambiar siempre se mantiene la seleccion, pero si esto lo extiendes a itsm con impacto y prioridades puedes tener un problema, porque lo cambiarias con javascript pero AJAX se ejecutaria despues y te lo volveria a cambiar porque no ejecuta recargo de pagina (ejecutando tu codigo de javascript del dtl) sino de campos.

respecto al ejemplo:

Lado Servidor (pm)

Code: Select all

## Creacion Label Copia
$Param{Copia}="<select name='Copia' id='Copia'>";

my $j = 0;
for ($j=0;$j<100;$j++)
{ 
    my $listado=$Self->{ConfigObject}->Get("Catalogo".$j);
    if ($listado eq ''){next;}
    while( my ($k, $v) = each %$listado) {
	$Param{Copia}.="<option value='$k'>$v</option>\n";
    }
}
$Param{Copia}.="</select>";

Lado cliente (dtl)

Code: Select all

<label id="LabelCopia">Copia:</label>
<div class="Field">
$Data{"Copia"}
</div>
<div class="Clear"></div>
[...]
document.getElementById('LabelCopia').style.display = 'none';      
document.getElementById('Copia').style.display = 'none';

Como ves por el lado cliente solamente hago lo basico, la tag principal donde pondre mi tag recreada dinamicamente desde el servidor, es este caso es un desplegable que recoge valores de un xml que tengo en configuracion del sistema para que asi los tecnicos puedan cambiar sus valores sin tener que estar yo modificando el codigo (pero tambien puede ser valores del ticket llamando a la funcion TicketGet o una llamada a la BBDD o lo que quieras). Con esto y despues el Javascript construyo una serie de freetext y sla predefinidos en el frontal agente en funcion de las primeras selecciones basicas y cliente seleccionado.

Algunas partes de Javascript las modifico directamente en AJAX (lo tienes en /opt/otrs/var/httpd/htdocs/js/Core.AJAX.js) para casos muy especificos que cambian siempre e identifico la accion que lo ha ejecutado pasandoselo por parametro con esa llamada Core.AJAX.FormUpdate adulterando la funcion con una variable mas.

Un saludo.

[doriath]

Gracias Miguel,

Creo que se me va un poco de las manos, entre mis escasos conocimientos de perl y la limitación que tengo en la modificación de código para prevenir
fallos en futuras actializaciones.

Doriath

[miguelmz]

De nada,

Todo es ponerse, yo hace 4 meses me podrias haber preguntado sobre OTRS y creer que fuera una tostadora
Si tienes problemas para implementar algunas cosas porque tienen miedo a que te cargues el sistema, siempre puedes usar los modulos opm.

viewtopic.php?f=84&t=14891

Al instalarse sobreescriben los archivos pero siempre dejan un backup en forma .save que es de donde recuperan cuando desinstalas el paquete. Solamente tienes que tener cuidado si tocas cosas de BBDD porque el Gestor de paquetes no es capaz por el momento de alterar BBDD al desinstalar y lo deja residual

Si te animas, haz siempre pruebas en una maquina de pruebas porque cuando lee el xml hace muchas cosas y si tienes el xml mal formado casca y deja inservible el gestor de paquetes. Obligandote a borrar cientos y cientos de caches y registros de BBDD... un coñazo. Yo tengo un linux virtual y revierto snapshot para las pruebas.

Es lo mismo que tocar, pero a los jefes les parece mejor idea por si algun dia tu no estas .

Un saludo.

[doriath]

OK,

No es miedo a joderlo, tengo una máquina virtual para hacer pruebas y petarla si es necesario, de hecho ya se ha petado alguna vez...

Tengo muy limitada la edición de código, de hecho ne debería tocar nada, pero hay casos en los que no queda otra, se han hecho otros cambios y
obligatoriamente ha tenido que ser por código.

También he probado algún paquete opm, pero casi todo lo que encuentro es para la versión 3.0 como mucho y se queja al instalarlo.

Saludos


Doriath

[miguelmz]

No me referia a instalar un opm ajeno, sino que las modificaciones que hagas las transformes tu en un opm. De esta manera, es mucho mas rapido aplicar y volver atras en produccion frente ir a manubrio.

Pero como siempre, con cuidado y pruebas en local.

Un saludo.