Actuación simple
Este tipo de actuación supone realizar una actuación única sobre la solicitud; no se trata de una operación por lotes.
Este tipo es equivalente a seleccionar la opción de “continuar actuando” sobre el formulario de NWT y la solicitud termina en el mismo estado y asignada al proveedor que realiza la actuación.
Esta acción no modifica el estado de la solicitud.
Requisitos funcionales
- La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.
- Debe ser posible realizar la actuación. La solicitud debe haber estado asignada a un usuario de la misma organización en algún momento y sólo se podrá actuar durante un plazo de 15 días tras la resolución de la solicitud.
- Sólo se podrá realizar la operación con solicitudes padres.
- Las horas deben tener punto decimal y dos cifras decimales.
- El delegado que realiza la operación debe estar dado de alta en CGES y pertenecer a la misma organización que el usuario de integración que hace uso de la API.
- Enviar el tipo de actuacion "No aplica" (401113)
- Los parámetros de actuación del perfil, horario (factorTiempo) y causa imputable se podrán obtener de las tablas maestras:
Escalado
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un escalado de la misma. Este tipo es equivalente a seleccionar la opción de “escalar” sobre el formulario en la NWT y la solicitud termina asignada a otro resolutor, dentro de la misma organización o no. Esta operación equivale a realizar dos operaciones, la primera para crear la actuación propiamente dicha, y la segunda para escalar la solicitud a un nuevo resolutor, modificando el asignado:
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto.
El usuario podría no tener permisos para realizar estas operaciones individualmente o, en caso de tenerlo, el resultado de la operación no será el esperado.
Requisitos funcionales
- Mismos requisitos que para una actuación simple, salvo por el envío del tipo de actuación, que no puede ser "No aplica" y debe pertenecer a la lista de tipos de actuación compatibles.
La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.
El comentario enviado en el cambio de asignado debe coincidir con el comentario de actuación.
- El tipo de actuación debe pertenecer a la siguiente lista:
- El usuario al que se va a escalar la solicitud debe estar permitido. Para consultar los usuarios a los que se puede escalar la solicitud, se debe hacer uso del siguiente recurso pasando el parámetro idSolicitud en la URL.
La respuesta, tanto en caso de éxito como de error, vendrá ordenada por el orden lógico de ejecución en el sistema y no necesariamente debe coincidir con el orden de los métodos enviados en el cuerpo de la petición.
Podrían obtenerse, además, mensajes adicionales que hagan referencia a operaciones intermedias ejecutadas por el sistema y que no dependen de elementos enviados en la petición.
Resolución simple
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un cambio de estado de esta a “Pte. Conf. Cierre” y finalizando con un cambio en la causa raíz de la solicitud. Este tipo es equivalente a seleccionar la opción de “resolver” sobre el formulario en la NWT y escoger “No aplica” en las opciones de versionado. Esta operación equivale a realizar dos operaciones, la primera para crear la actuación propiamente dicha, la segunda para cambiar el estado (v2.0) de la solicitud a “Pdte. Conf. Cierre” y terminar con el cambio de causa raíz (v3.0):
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto.
El usuario podría no tener permisos para realizar estas operaciones individualmente o, en caso de tenerlo, el resultado de la operación no será el esperado.
Requisitos funcionales
- Mismos requisitos que para una actuación simple.
- Para incidencias, se puede enviar el parámetro versionCausal con el código de versión de Jira que dio origen a la incidencia. La versión debe tener un código de versión informado en Jira y debe ser de la misma aplicación que la asociada a la incidencia.
La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.
El único cambio de estado permitido es a “Pdte. Conf. Cierre” (400001).
El comentario enviado en el cambio de estado debe coincidir con el comentario de actuación. Del mismo modo, el comentario de causa raíz debe ser diferente, ya que debe reflejar la justificación de elección de dicha causa.
Las causas raíces compatibles se obtienen con el siguiente método (filtrando por idSolicitud) y deben ir acompañadas de un texto de justificación en caso de que la causa raíz indicada sea diferente de “No Aplica”:
- Mismos requisitos que para una actuación simple.
Resolución con envío a JIRA
Este tipo de actuación supone realizar una actuación sobre la solicitud seguida de un envío de la solicitud como incidencia a JIRA y finalizando con la modificación de la causa raíz de la solicitud. Este tipo es equivalente a seleccionar la opción de “resolver” sobre el formulario en la NWT y escoger alguno de los versionados compatibles. La solicitud termina asociada con JIRA y cambia al estado “Pdte. Implantar”. Esta operación equivale a realizar tres operaciones, la primera para crear la actuación propiamente dicha, la segunda para lanzar la integración con JIRA y generar la solicitud en esta herramienta y finalizar con un cambio en la causa raíz de la solicitud (v3.0):
Para garantizar la integridad de la operación, estas modificaciones deberán realizarse a través de una operación de batch en el orden correcto.
El usuario podría no tener permisos para realizar estas operaciones individualmente o, en caso de tenerlo, el resultado de la operación no será el esperado.
Requisitos funcionales
- Mismos requisitos que para una actuación simple.
- Para incidencias, se puede enviar el parámetro versionCausal con el código de versión de Jira que dio origen a la incidencia. La versión debe tener un código de versión informado en Jira y debe ser de la misma aplicación que la asociada a la incidencia.
- Enviar el versionado de la actuación simple de forma acorde a la actuación que se quiere realizar para el envío a Jira. Por defecto, en caso de no enviar valores, se registrará como una issue de tipo Incidencia.
- La solicitud debe estar asociada a una aplicación válida y tramitable en JIRA. Se puede consultar el conjunto de aplicaciones de CMS a través del siguiente recurso, filtrando por el código de ámbito TIC de la factoría en estado activo:
- Mismos requisitos que para una actuación simple.
- La solicitud debe encontrarse en estado “Abierta”, estar tipificada como “Incidencia” y estar asignada actualmente al proveedor.
- Las causas raíces compatibles se obtienen con el siguiente método (filtrando por idSolicitud) y deben ir acompañadas de un texto de justificación en caso de que la causa raíz indicada sea diferente de “No Aplica”:
- El comentario enviado en el envío a JIRA debe coincidir con el comentario de actuación. Del mismo modo, el comentario de causa raíz debe ser diferente, ya que debe reflejar la justificación de elección de dicha causa.
- En función del versionado seleccionado...
- En caso de seleccionar el versionado "Incrementa versión (Modifica línea base)", se pueden obtener las versiones a asociar en el parámetro versionJira del siguiente método:
- En caso de seleccionar el versionado "No incrementa versión (sólo requiere petición de lanzamiento de datos)", se pueden obtener las PLs de Datos a asociar en el parámetro plJira del siguiente método:
- No se pueden resolver por este método las solicitudes generadas mediante agenda con el usuario. (motivoPlanificacion.id=400015)