De acuerdo con la documentación interna de MEGA: Una definición de flujo de trabajo (Workflow Definition) permite establecer una secuencia de operaciones ejecutadas por personas. Cuando se pone en marcha, el flujo de trabajo garantiza la gestión precisa de la secuencia de operaciones y notifica a las personas involucradas. Todo esto se aplica a un objeto de repositorio conocido como el "sujeto del flujo de trabajo" (Workflow subject), donde las operaciones esperadas están estrechamente vinculadas a este objeto (MEGA, HOPEX V5 EN Doc, Consultado el 11 de enero de 2024).
Ejemplificando lo anterior de forma breve, revisaremos el Workflow que se tiene de forma estándar para los Incidentes, por lo que, con el perfil de IRM Manager, creamos un incidente desde los registros de los mismos, cosa que se vería así:
Entonces, al momento de finalizar la creación ya comienza el flujo de trabajo y nosotros al entrar a las características, tenemos lo siguiente:
Y podemos ver como este ya se encuentra en la etapa de validado en todo el flujo de trabajo, nosotros podemos cerrar el incidente al marcar la etapa como terminada y también hay que notar que las etapas anteriores saltaron automáticamente.
Otro punto importante de esto es que el incidente al ser macado en una etapa de Cerrado, ya no es posible modificar algunas de sus propiedades listadas en la página de Características. Por lo que, el flujo no sólo representa una etapa en la que se encuentra el incidente, también podemos usar esta propiedad para determinar cuando es posible continuar modificando los objetos.
Es ahora cuando examinaremos los motivos del comportamiento de este flujo de trabajo y para esto accederemos al escritorio para visualizar los Workflow Definitions existentes y ubicaremos el de Declaración de Incidente.
Y posteriormente, al abrir el diagrama del Workflow definition, tenemos para el incidente lo siguiente:
Aquí podemos ver que el diagrama estándar, cuenta con dos posibles puntos de inicio del flujo de trabajo, esto es el causante de que con el perfil de IRM Manager, al crear un incidente, no pasemos por todas las etapas que hay en el flujo, ya que se puede ver una Transición de Flujo de Trabajo que va desde el inicio hasta el Estatus de Validado.
En cada una de las transiciones de los flujos de trabajo, tenemos la posibilidad de añadir condiciones en las transiciones o acciones, como se ven las siguientes que están creadas de forma estándar:
En el caso de las acciones podemos ver por los nombres que una de ellas actualiza el estatus de forma inmediata y también se envían correos electrónicos para los participantes que se tengan configurados.
Para las Condiciones, estas están normalmente definidas por Macros de VBs que ayudan a verificar como pre condiciones o post condiciones. En este caso vamos a alterar el diagrama a fin de que ningún perfil sea capaz de llegar directamente al estatus de Validado sin antes haber pasado por todos los estatus del incidente. Para ello, es importante dejar el diagrama de la siguiente manera:
Esto nos da una representación visual de lo que estará ocurriendo, sin embargo, aunque se haya ocultado el elemento, es posible que aún no se esté respetando el orden que nosotros tenemos planeado, se debe verificar que las transiciones entrantes y salientes en los elementos, no exista alguna que esté conectada desde el inicio al estatus de Validar, ejemplo, para el estatus de validado, sólo debemos ver las siguientes transiciones:
Ahora, agregaremos una condición adicional que ayude a verificar si el perfil que quiere ejecutar la transición de Validar, tiene asignado el perfil IRM Manager, en caso de que si lo tenga asignado, este perfil no podrá ejecutar esa transición y para esto se ocupará la Pre Condición, para que dicho perfil, no pueda ver la opción de enviar al estatus de Validado el Incidente. La macro quedaría:
'MegaContext(Fields,Types)Option Explicit
Function CheckCondition (objWorkflowContextCondition)
Dim mgRoot, creator, currentUser, currentProfile, IncidentsLossesAdministrator, message message = "" Set mgRoot = objWorkflowContextCondition.GetRoot
Dim mgobjWorkflowSubject Set mgobjWorkflowSubject = objWorkflowContextCondition.GetWorkflowSubject
'Get Current User currentUser = mgRoot.GetObjectFromID(mgRoot.CurrentEnvironment.GetCurrentUserId)
'Get Current Profile currentProfile = mgRoot.GetObjectFromID(mgRoot.CurrentEnvironment.GetCurrentProfileId)
'Add campaign Creator If currentProfile.sameId("~KXhs3uTHSfiT[Manager IRM]") Then 'OK message = "Profile IRM Manager, not permited" End if
CheckCondition = message
End Function
De esta manera estaremos verificando el perfil IRM Manager para esa última transición, por lo que, derivado de las modificaciones, se espera que primero, el perfil IRM Manager, tenga que pasar por todas las transiciones del flujo de trabajo y además, no pueda enviar a Validado el incidente.
Entonces, creando un nuevo incidente con el perfil de IRM Manager, tenemos el siguiente resultado:
Podemos ver, que a la creación, el incidente se mantiene en el estatus "Por Validar" y ya no está directamente en "Validado", ahora probaremos pasar por cada transición hasta llegar hasta Validado, pero veremos que esto no será posible.
Ya estando en el estatus que corresponde, al querer marcar la etapa como terminada, no será posible pasar al estatus de "Validado", en su lugar, se abrirá directamente el wizard para explicar el rechazo del incidente.
Finalmente, podemos ver que el incidente queda con el estatus de rechazado, y sólo es el camino posible debido a la configuración realizada:
Próximamente se harán más modificaciones a las condiciones de los flujos de trabajo o se crearán nuevas transiciones y acciones, esto únicamente ha sido una breve introducción a los componentes más representativos de estas Definiciones de Flujos de Trabajo y se espera que conociendo este alcance, se puedan realizar o planificar algunas pequeñas modificaciones útiles.