You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As User Management App user, I want a login page as a way of have a protected access to the app.
Acceptance Criteria (AC):
There must be a login page.
The login page must have a form with the following fields: email, password and
a submit button.
The email and password inputs are required.
If the user leaves empty fields and clicks the submit button, the login page
should display required messages as the format: “The [field name] is required”
aside of the proper field.
The email value should contain the proper email format (the “@”, domain value,
etc).
The submit button should be disabbled while the form page is fetching the
data. After fetching, the submit button does not have to be disabled.
There should be a loading indicator at the top of the form while it is
fetching.
In a unexpected server error, the form page must display the error message
“Unexpected error, please try again” from the api.
In the invalid credentials response, the form page must display the error
message “The email or password are not correct” from the api.
Inicio de sesión
Como usuario de la aplicación de la empresa, quiero una página de inicio de sesión como una forma de tener un acceso protegido a la aplicación.
Criterios de aceptación (AC):
Debe haber una página de inicio de sesión.
La página de inicio de sesión debe tener un formulario con los siguientes
campos: correo electrónico, contraseña y un botón de envío.
Se requieren las entradas de correo electrónico y contraseña.
Si el usuario deja campos vacíos y hace clic en el botón enviar, la página de
inicio de sesión debe mostrar los mensajes obligatorios con el formato: "El
[nombre del campo] es obligatorio" al lado del campo correspondiente.
Se validan las entradas de correo electrónico y contraseña.
El valor del correo electrónico debe contener el formato de correo electrónico
adecuado ("@", valor de dominio, etc.).
La entrada de la contraseña debe contener al menos: 8 caracteres, una letra
mayúscula, un número y un carácter especial.
El formulario debe enviar los datos a un servicio de punto final de backend.
El botón de envío debe estar desactivado mientras la página del formulario
está recuperando los datos. Después de la recuperación, no es necesario
deshabilitar el botón de envío.
Debe haber un indicador de carga en la parte superior del formulario mientras
se está recuperando.
En un error inesperado del servidor, la página del formulario debe mostrar el
mensaje de error "Error inesperado, inténtelo de nuevo" de la API.
En la respuesta de credenciales no válidas, la página del formulario debe
mostrar el mensaje de error "El correo electrónico o la contraseña no son
correctos" de la API.
Los usuarios no autenticados deben ser redirigidos a la página de inicio de
sesión al ingresar a páginas privadas (páginas de empleados y administrador).
As admin, I want to have full access to the user management app
Acceptance Criteria:
The admin must be redirected to the admin page after login.
The admin username should be displayed on the common navbar.
The admin page should list the users registered with pagination.
There should be 10 user per page.
There should be the next user info: Full name, email, profile picture, access status (active or disabled), role (enum: admin, member) and last login date (dd-mm-yyyy format).
The admin must have access to a search text field for filter users in the table.
The admin must have access to invite user button.
The admin must have access to update user data button.
The admin must have access to update user role button.
The admin must have access to disable user access button.
Autorización
Como administrador, quiero tener acceso completo a los módulos de la aplicación: página de miembros y página de administrador para poder operar en ellas.
Criterios de aceptación:
El administrador debe ser redirigido a la página de administración después de iniciar sesión.
El nombre de usuario del administrador debe mostrarse en la barra de navegación común.
La página de administración debe enumerar los usuarios registrados con paginación.
Debe haber 10 usuarios por página.
Debe haber la siguiente información del usuario: nombre completo, correo electrónico, imagen de perfil, estatus de acceso (activo o desactivado), rol (enumeración: administrador, miembro) y última fecha de inicio de sesión (formato dd-mm-yyyy).
El administrador debe tener acceso a un campo de búsqueda para filtrar usuarios en la tabla.
El administrador debe tener acceso para invitar al botón de usuario.
El administrador debe tener acceso para actualizar el botón de datos de usuario.
El administrador debe tener acceso para actualizar el botón de rol de usuario.
El administrador debe tener acceso para deshabilitar el botón de acceso de usuario.
As admin, I want to search users by name and email so I can find quickly an user
Acceptance Criteria:
When should display a loading state when is fetching the users
When the admin type in the search field, the app should filter the users by name and email following the search field value and update the table with the results
If there are not users matching with the search, then the app should show the message "There are not users that match with that search"
As admin, I want to invite users to my group members so I can grow my group
Acceptance Criteria:
When the admin click on "invite user" button, then the app should display a modal with a form with the fields:
first name.
last name.
email.
role (admin or member).
And a submit button.
All the fields are required. Display the error message bellow the field as: "the [input name] is required".
The submit button is disabled until the form is valid
When the user is invited successfully, there should display a toast element with a success message
When the form is valid, the user clicks on submit button and there is a BE error, there should display a toast element with the message error "There was an error"
As admin, I want to update the current users in my group so I can have the info updated
Acceptance Criteria:
When the admin click on "update user" button, then the app should display a modal with a form with the fields:
first name.
last name.
email.
role (admin or member).
And a submit button.
The fields should pre populate with the current user information
All the fields are required. Display the error message bellow the field as: "the [input name] is required".
The submit button is disabled until the form is valid
When the user is invited successfully, there should display a toast element with a success message
When the form is valid, the user clicks on submit button and there is a BE error, there should display a toast element with the message error "There was an error"
As admin, I want to disable an user access when is necessary, so I can manage properly my group
Acceptance Criteria:
When the admin click on "disable user access" button, then the app should display a confirmation dialog the text "Are you sure to disable user access?", a cancel and a confirm buttons
When the admin click on cancel or outside of the dialog, then the app should close the dialog without affectation
When the admin click on confirm button, then the user selected should appear as innactive status
When there is an innactive user, then there should be an "activate" user button.
When the admin clicks on "activate" button, then the app should show display a confirmation dialog with the text "Are you sure to activate this user?", a cancel and confirm buttons.
As a merchandise manager, I want to store new products as a way of
administrating my products.
Acceptance Criteria (AC):
There must be a create product form page.
The form must have the following fields: name, size, type (electronic,
furniture, clothing) and a submit button.
All the fields are required.
If the user leaves empty fields and clicks the submit button, the form page
must display required messages as the format: “The [field name] is
required” aside of the proper field.
If the user blurs a field that is empty, then the form must display the
required message for that field.
The form must send the data to a backend endpoint service.
The submit button should be disabbled while the form page is fetching the
data. After fetching, the submit button does not have to be disabled.
In the success path, the form page must display the success message
“Product stored” and clean the fields values.
In a server error, the form page must display the error message “Unexpected
error, please try again”.
In the invalid request path, the form page must display the error message
“The form is invalid, the fields [field1...fieldN] are required”.
In the not found service path, the form page must display the message
“Connection error, please try later”.
Aplicación de formulario de tienda
Almacenar producto
Como gerente de mercadería, quiero almacenar nuevos productos como una forma de
poder administrarlos.
** Criterios de aceptación (AC): **
Debe haber una página de formulario de creación de producto.
El formulario debe tener los siguientes campos: nombre, talla, tipo
(electrónico, mobiliario, ropa) y un botón de envío.
Todos los campos son obligatorios.
Si el usuario deja campos vacíos y hace clic en el botón enviar, la página
del formulario debe mostrar los mensajes obligatorios con el formato: _ “El
[nombre del campo] es obligatorio” _ al lado del campo correspondiente.
Si el usuario desenfoca un campo que está vacío, entonces el formulario debe
mostrar el mensaje requerido para ese campo.
El formulario debe enviar los datos a un servicio de punto final de backend.
El botón de envío debe estar desactivado mientras la página del formulario
está recuperando los datos. Después de la recuperación, no es necesario
deshabilitar el botón de envío.
En la ruta de éxito, la página del formulario debe mostrar el mensaje de
éxito _ "Producto almacenado" _ y limpiar los valores de los campos.
En un error del servidor, la página del formulario debe mostrar el mensaje
de error _ "Error inesperado, inténtelo de nuevo" _.
En la ruta de solicitud no válida, la página del formulario debe mostrar el
mensaje de error _ “El formulario no es válido, los campos [campo1 ...
campoN] son obligatorios” _.
En la ruta del servicio no encontrado, la página del formulario debe mostrar
el mensaje _ "Error de conexión, intente más tarde" _.
As a developer, I want to take a quick look at the github repositories as a way
of inspiring me to be better professional.
Acceptance Criteria:
There must be a github repositories list page.
The page should contain the next filters:
An input text with label "filter by" field in order to do the search.
The Search Button.
The results section should contain:
Before the first search, show the initial state message “Please provide a
search option and click in the search button”.
The search button should be disabled until the search is done.
The data should be displayed as a sticky table.
The header table should contain: Repository, stars, forks, open issues and
updated at
Each result should have: owner avatar image, name, stars, updated at, forks,
open issues. It should have a link that opens in a new tab the github
repository selected.
Total results number of the search and the current number of results.
Example: 1-10 of 100.
A results size per page select/combobox with the options: 30, 50, 100. The
default is 30.
Next and previous pagination when the context applies to them, example: on
the first page, the previous page should be disabled.
If there is no results, then show a empty state message “You search has no
results”
Handling filter:
If the developer types "ruby" in the filter by repository name input and
clicks on search, the app should return repositories with the "ruby" word
associated.
Size per page:
If the developer clicks on search button and then selects 50 per page value,
the app should show 50 repositories on the table
Pagination:
If the developer clicks on search and then on next page button, the app
should show the next repositories.
If the developer clicks on search and then on next page button and then
clicks on previous button, the app should show the previous repositories.
Handling errors:
If there is an unexpected error from the frontend app, the app should show a
message “There is an unexpected error” and a reload button.
If there is an unexpected error from the backend, the app should display an
alert message error with the message from the service if any, if not show
the generic “there is an unexpected error”.
US - Lista de repositorios de github
Como desarrollador, quiero echar un vistazo rápido a los repositorios de github
como una forma de inspirarme a ser mejor profesional contribuyendo a proyectos
open source.
Criterios de aceptación:
Debe haber una página de lista de repositorios de github.
La página debe contener los siguientes filtros:
Un input text para filtrar con label "filter by". Esta es un campo para
realizar la búsqueda.
La sección de resultados debe contener:
Antes de la primera búsqueda, muestre el mensaje de estado inicial
"Proporcione una opción de búsqueda y haga clic en el botón de búsqueda ”.
El botón de Search debe estar deshabilitado hasta que se termine la
búsqueda.
Los datos deben mostrarse como una tabla adhesiva.
La cabecera de la tabla debe contener: Repository, stars, forks, open issues
and updated at y open issues.
Cada resultado debe tener: imagen de avatar del propietario, nombre,
estrellas, actualizado en, bifurcaciones, problemas abiertos. Debería tener
un enlace que se abre en una nueva pestaña en github del repositorio
seleccionado.
Número total de resultados de la búsqueda y número actual de resultados.
Ejemplo: 1-10 de 100.
Un select/combobox para modificar el tamaño de resultados por selección de
página con las opciones: 30, 50, 100. El valor predeterminado es 30.
Paginación siguiente y anterior cuando el contexto aplica, ejemplo: en la
primera página, la página anterior debe estar desactivada.
Si no hay resultados, muestre un mensaje de estado vacío "Tu búsqueda no
tiene resultados "
Manejo de filtros:
Si el desarrollador escribe "ruby" en el filtro por la entrada del nombre
del repositorio y hace clic en la búsqueda, la aplicación debería devolver
repositorios con la palabra "ruby" asociado.
Tamaño por página
Si el desarrollador hace clic en el botón de búsqueda y luego selecciona 50
por valor de página, la aplicación debería mostrar 50 repositorios en la
tabla
Paginación:
Si el desarrollador hace clic en buscar y luego en el botón de la página
siguiente, la aplicación debería mostrar los próximos repositorios.
Si el desarrollador hace clic en buscar y luego en el botón de la página
siguiente y luego hace clic en el botón anterior, la aplicación debería
mostrar los repositorios anteriores.
Manejo de errores:
Si hay un error inesperado de la aplicación de frontend, la aplicación
debería mostrar un mensaje "Hay un error inesperado" y un botón de recarga.
Si hay un error inesperado del backend, la aplicación debería mostrar un
error de mensaje de alerta con el mensaje del servicio si lo hay, si no se
muestra el genérico "hay un error inesperado".
