Actuaciones: Proveedores

Escalado

Este tipo de actuación supone realizar un escalado de la solicitud, terminando ésta 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 (v2.0) y la segunda para escalar la solicitud a un nuevo resolutor, modificando el asignado:

Requisitos funcionales

• • • La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.

    • La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.

    • 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.

    • 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.

• • • Se debe acompañar la acción de un comentario, que será visible por el usuario afectado de la solicitud.
    • El comentario enviado en cambio de asignado debe coincidir con el comentario de actuación.
    • El tipo de actuación debe pertenecer a la siguiente lista:

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 no marcar “Requiere RFC” en las opciones. Esta operación equivale a realizar tres operaciones, la primera para crear la actuación propiamente dicha (v2.0), la segunda para informar la causa raíz en la solicitud (v3.0) y la tercera para cambiar el estado de la solicitud a “Pdte. Conf. Cierre” (v2.0):

Requisitos funcionales

• • • La solicitud debe existir y el usuario debe tener permisos para trabajar con ella.

    • La solicitud debe encontrarse en estado “Abierta” y estar asignada actualmente al proveedor.

    • 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.

    • El único cambio de estado permitido es a “Pdte. Conf. Cierre”.

    • 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 cambio de estado será visible por el usuario afectado de la solicitud. 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.
    • El comentario enviado en cambio de estado debe coincidir con el comentario de actuación.
    • Enviar el tipo de actuacion "No aplica" (401113)

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 las opciones de versionado compatibles. La solicitud termina asociada con JIRA y en el estado “Pdte. Implantar”. Esta operación equivale a realizar tres operaciones, la primera para crear la actuación propiamente dicha (v2.0), 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):

Requisitos funcionales

• • • Mismos requisitos que para una actuación simple.
    • 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:

• • • 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.
    • No se pueden resolver por este método las solicitudes generadas mediante agenda con el usuario. (motivoPlanificacion.id=400015)

• • • Enviar el tipo de actuacion "No aplica" (401113)

• • • 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: