Flujo de trabajo
Aprenderemos a crear aplicaciones personalizadas mediante un ejemplo. Crearemos una aplicación sencilla de seguimiento de errores. Supondremos que contamos con dos equipos: Desarrolladores, quienes corrigen los errores, y Control de Calidad (QA, por sus siglas en inglés), quienes prueban las correcciones realizadas por los desarrolladores. Modelaremos el siguiente flujo de trabajo para la gestión de errores:
En lenguaje sencillo, el diagrama se traduce como:
- When a bug is reported, it is in the New state.
- QA verifies the bug. If it is not a bug, the bug moves to Closed; else to the Verified state.
- A verified bug fixed by a developer moves to the Fixed state.
- The fix is then tested by QA and the bug moves to Reopened, if test fails; or Closed, if the test passes.
- A Reopened bug fixed by the developer moves to the Fixed state.
Each bubble is represents a stage in the bug life-cycle while each arrow an end-user action. Next to each state we have defined the team responsible for it. Also, note that there is no way for a bug to move from any state directly to any other state e.g. A bug cannot move directly from New to Fixed
Nosotros mismos usamos nuestra propia aplicación de seguimiento de errores, pero contamos con muchos más estados para indicar si se incluyó un caso de prueba, si se actualizó la documentación, si se agregó un caso de prueba, etc. De manera similar, puedes hacer que el flujo de trabajo sea tan complejo o simple como desees. Pero por ahora, centrémonos en el flujo de trabajo simple que mencionamos anteriormente.
Creación de una aplicación
Para crear una aplicación, vaya a Menú principalAdministraciónAplicaciones personalizadasAplicaciones y haga clic en AgregarVerás un formulario con varias pestañas. A continuación, explicaremos cada una de ellas.
La pestaña Básico
Esta pestaña define algunas propiedades básicas de la aplicación. Además, también controla ciertos comportamientos de la misma.
| Nombre | El nombre de tu aplicación. Pondremos Bug aquí. |
| Plural | El nombre en plural. |
| Initial Assignee | Seleccione el usuario que se asignará automáticamente a las nuevas instancias. |
| App Client Reqd | Por defecto, el creador de un elemento de la aplicación también es quien lo solicita. Sin embargo, puede haber casos en los que desee 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, queremos que nuestros agentes de soporte puedan reportar errores en nombre de un cliente, pero también queremos que las actualizaciones se envíen al cliente. Por lo tanto, activamos esta opción. Cuando está habilitada, verá el "Solicitante" activado al crear una nueva instancia de la aplicación. |
| Use Due Date | Esta opción determina si se habilita o deshabilita el campo de fecha de vencimiento en el elemento de la aplicación Agregar/Editar. Como no queremos usar el campo de fecha de vencimiento, marcamos esta opción. |
| Use Priority | Esta opción determina si se habilita o deshabilita el campo Prioridad en el elemento de la aplicación Agregar/Editar. Como no queremos usar el campo Prioridad, marcamos esta opción. |
| ¿Hay tiempo disponible? | Si se permite registrar el tiempo en la aplicación. Queremos que nuestros desarrolladores y el equipo de control de calidad registren su tiempo, por lo que marcamos esta opción. |
| Is Client Initiable | Si desea que sus clientes creen nuevas instancias. Nos gustaría que nuestros clientes informaran de errores, por lo que marcamos esta opción. |
| Descripción | Una breve descripción de tu aplicación. |
| Seguidores | Selecciona los seguidores predeterminados. Los seguidores recibirán notificaciones cuando haya reasignaciones, cambios de estado o nuevos comentarios. |
| Activo | Para activar o desactivar la aplicación. Marcarla como inactiva no eliminará las instancias existentes de dicha aplicación. |
La pestaña Estados
Esta pestaña define los estados de la aplicación. También puedes marcar los estados de inicio y fin en el flujo de trabajo. Hemos enumerado todos los estados en nuestro flujo de trabajo de errores.
| Estado inicial | 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 pasa a este estado, el proceso se considera finalizado. En nuestro caso es Cerrado. |
La pestaña Flujo de trabajo
This tab defines all the arrows in the workflow diagram. Each arrow represents an end-user action. We shall see more about its usage later on in the documentation.
| Acción | El nombre de la acción. Este se utilizará en los menús de acciones para los errores. |
| De | El estado de donde proviene la flecha. |
| A | El estado donde termina la flecha. Una vez realizada la acción, nuestro error pasará a este estado. |
| Asignar a | El usuario al que se asignará el flujo de trabajo después de que se realice la acción. El mensaje en Rol: Desarrollador indica que al usuario que realiza la de Verificar en el error se le mostrará una lista de desarrolladores de entre los que podrá elegir al nuevo responsable. |
| Action Allow User | Determina si un usuario puede realizar esta acción. En algunos casos, no queremos que los usuarios finales la realicen. Por ejemplo, en los sistemas de soporte técnico, los tickets sin respuesta se cierran automáticamente tras unos días de inactividad. |
La pestaña Disparadores
Using triggers you can tell Celoxis to perform state transitions when it receives an email from the requestor.
In our bug tracking app, we don't need any triggers. However, let's take this help desk workflow for example. In case of the help desk app, the requestor will be the person who asked a question. When
that
person replies via
, we would want the ticket to be automatically moved to the Unresolved state as then it would be brought to the attention of the support team. In other words, we would want the Reopen transitions to happen. In this case, we would be defining our triggers like this:
La pestaña de administradores estatales
A state managers is a user who is treated as a Manager when an app is in a particular state. They are notified when things happen to an item in this state. In our example below, Mark is the QA manager, so he is responsible for the New and Fixed states where the QA team is supposed to do work.
You can override state managers at a project level if the person managing that state is different.
¿Qué sigue?
Hemos creado una aplicación personalizada para nuestro flujo de trabajo de errores. En el próximo capítulo, añadiremos algunos campos personalizados al informe de errores.