Flujo de trabajo
Aprenderemos a construir aplicaciones personalizadas a través de un ejemplo. Construiremos una sencilla aplicación de seguimiento de errores. Asumiremos que tenemos dos equipos: Los desarrolladores - arreglan los errores y QA (abreviatura de Garantía de Calidad) - prueban las correcciones de los desarrolladores. Le daremos al modelo el siguiente flujo de trabajo de errores:
En palabras simples, el diagrama se traduce a:
- Cuando se informa de un fallo, éste se encuentra en el estado Nuevo.
- QA verifica el error. Si no es un fallo, el fallo se mueve a Cerrado; si no, al estado Verificado.
- Un error verificado y arreglado por un desarrollador se mueve al estado Fijo.
- El arreglo es entonces probado por QA y el error se mueve a Reabierto, si la prueba falla; o Cerrado, si la prueba pasa.
- Un error reabierto y arreglado por el desarrollador pasa al estado Fijo.
Nosotros mismos usamos nuestra propia aplicación de seguimiento de fallos pero tenemos muchos más estados para indicar si un caso de prueba estuvo presente, si la documentación fue actualizada, si un caso de prueba fue añadido, etc. Del mismo modo, puede hacer que el flujo de trabajo sea tan complejo o simple como desee. Pero por ahora, vamos a atenernos al sencillo flujo de trabajo que hemos discutido anteriormente.
Creación de una aplicación
Para crear una aplicación, vaya a Menú Principal ▸ ▸ Admin ▸ Aplicaciones personalizadas ▸ Aplicaciones y haga clic en Añadir. Verá un formulario con muchas pestañas. Cubrimos cada pestaña a continuación.
La ficha Básica
Esta pestaña define algunas propiedades básicas de la aplicación. Además, también controla ciertos comportamientos de la aplicación.
| Nombre | El nombre de tu aplicación. Pondremos a Bug aquí. |
| Plural | El nombre en plural del nombre. |
| Asignar inicialmente a | Seleccione el usuario que será asignado automáticamente a las nuevas instancias. |
| Usar Campo del Solicitante | Por defecto, el creador de un elemento de aplicación es también el solicitante de dicho elemento. Sin embargo, puede haber casos en los que quieras iniciar una aplicación en nombre de otra persona y que las notificaciones y actualizaciones se envíen a esa persona y no al creador. En nuestra aplicación, nos gustaría que nuestros agentes de soporte pudieran abrir los errores en nombre de un cliente, pero nos gustaría que las actualizaciones se enviaran al cliente. Así que lo encendemos. Cuando se activa, verá un campo Solicitante activado mientras crea una nueva instancia de una aplicación. |
| Use el campo Fecha de vencimiento | Esta opción determina si se activa o desactiva el campo de fecha de vencimiento en el elemento de la app Añadir/Editar. Como no queremos utilizar el campo Fecha de vencimiento, marcamos esta opción. |
| Use campo de Prioridad | Esta opción determina si se activa o desactiva el campo Prioridad en el elemento Añadir/Editar app. Como no queremos utilizar el campo Prioridad, marcamos esta opción. |
| Permitir registrar tiempo | Si se debe permitir el tiempo de registro en la posición de la aplicación. Nos gustaría que nuestros desarrolladores y el equipo de control de calidad registren el tiempo, así que marcamos esta opción. |
| Los clientes pueden iniciar esta aplicación | Si quiere que sus clientes creen nuevas instancias. Nos gustaría que nuestros clientes reportaran los errores, por lo que marcamos esta opción. |
| Descripción | Una breve descripción de su aplicación. |
| Seguidores | Seleccione los seguidores predeterminados. Los seguidores recibirán notificaciones cuando haya reasignación, cambio de estado o nuevos comentarios. |
| Activo | Si activar o desactivar su aplicación. Si se marca como inactiva no se eliminarán las instancias existentes de esa aplicación. |
La ficha Estados
Esta pestaña define los estados de la aplicación. También se pueden marcar los estados de inicio y final en el workflow. Hemos enumerado todos los estados en nuestro flujo de trabajo de errores.
| Estado de Inicio | Cuando se crea un elemento de la aplicación, se mueve a este estado. En nuestro caso, es nuevo. |
| Estado final | Cuando un elemento de la aplicación se mueve a este estado, el proceso se considera como terminado. En nuestro caso está cerrado. |
La pestaña Workflow
Esta pestaña define todos los flechas en el diagrama de flujo de trabajo. Cada flecha representa una acción del usuario final. Veremos más sobre su uso más adelante en la documentación.
| Acción | El nombre de la acción. Esto se usará en los menús de acción para los bichos. |
| De | El estado donde se origina la flecha. |
| Para | El estado donde termina la flecha. Una vez realizada la acción, nuestro fallo se moverá a este estado. |
| Asignar a | El usuario al que se asignará el workflow después de realizar la acción. El estímulo en el papel: El desarrollador indica que el usuario que realiza la acción Verificar en el fallo se le presentará una lista de desarrolladores entre los que elegir el nuevo asignado. |
| Permitir usuario | Determina si esta acción puede ser realizada por un usuario. En algunos casos, no queremos que los usuarios finales realicen la acción. Por ejemplo, en los sistemas de asistencia técnica, los tickets que no responden se cierran automáticamente después de unos días de inactividad. |
La pestaña de los gatillos
En nuestra aplicación de seguimiento de errores, no necesitamos ningún activador. Sin embargo, tomemos como ejemplo este flujo de trabajo de la mesa de ayuda. En el caso de la aplicación de help desk, el solicitante será la persona que hizo la pregunta. Cuando esa persona responda por correo electrónico, quisiéramos que el ticket se moviera automáticamente al estado de No Resuelto, ya que entonces se pondría en conocimiento del equipo de soporte. En otras palabras, quisiéramos que las transiciones de Reapertura ocurrieran. En este caso, estaríamos definiendo nuestros disparadores de esta manera:
La pestaña Administradores de estado
Un gestor de estado es un usuario que es tratado como un Manager cuando una aplicación está en un estado particular. Se les notifica cuando le pasan cosas a un artículo en este estado. En nuestro ejemplo a continuación, Mark es el gerente de QA, por lo que es responsable de los estados Nuevo y Fijo donde se supone que el equipo de QA debe hacer el trabajo.
