Pueden visitar un ambiente de prueba de la aplicación en https://flap-staging.herokuapp.com/.
Hasta ahora se ha realizado la integración con el diseño y la plataforma tcm, en las siguientes acciónes.
- Pantalla de inicio
- Registro de usuario
- Estado de espera de confirmación de correo
- Confirmación de correo (sin diseño)
- Aceptar contrato
- Envío de forma de datos generales y bancarios (no hay validación).
- Login de un usuario
Algo que tambíen se esta considerando es el validar que un usuario solo pueda tener acceso a la sección que le corresponde según el caso el estado que se encuentra en el "onboarding". (Los estados que estamos considerando hasta ahora son los que vienen en la sección de "Valid stage" en el archivo de pruebas)
El diseño en este momento son los de la versión compartida por Mario Aceves el 11 de septiembre. Hay una nueva y al parecer ultima versión el día 18 de septiembre de la cual aún no se raliza la actualización.
Nota: En el archivo "150920-2-tests.text" se muestra el resultado de las pruebas que contienen la funcionalidad desarrollada hasta ahora.
Aunque falta más funcionalidad de la que especifico a continuación, pongo justo lo siguiente a implementar y las dudas que tenemos para realizarlo.
Cuando un usuario estaba registrado en tcm y no en flap, necesitamos tratarlo de una manera diferente para identificar en que parte del proceso de onboarding debería estar.
NP: No se contemplaran los usuarios previamente registrados. (ahora en TCM no hay usuarios con el mismo formato)
DUDAS
- ¿Cuales son los estados que podría tener un usuario en TCM?
- ¿Según cada uno de estos estados, en que parte del "Onboarding" debería de estar? ¿Podrían darme esta relación?
Hasta ahora no se puede salir de la sesión.
NP: solo se debe borrar el token (de memoria) y regresar a la pantalla de login
TCM nos da un token para hacer cada una de las llamadas internas. Este token tengo entendido que expira despues de un tiempo. Hasta ahora no existe la capacidad en flap de lidiar con un token expirado.
NP: Los servicios regresan un error en caso de token expirado, esa es la forma de identificarlo. En caso de ocurrir se debe regresar a la pantalla de login.
{ "status": { "code": "612", "message": "612: Token expirado" } }::
DUDAS
- ¿Cuando el token expira, flap debería pedir un nuevo token a TCM sin que el usuario sepa o deberíamos llevar al usuario a hacer login?
DUDAS
- ¿Como sabemos cuando un record ya fue verificado?
NP: En el USerNOde GET se devuelve status, los posibles con N_VAL (Validacion) y A_ACT (Activo)
{ "address": "Emilio Mitre 322", "businessName": "PRUEBA NACHO..", "country": "MEXICO", "countryId": "100", "mail": "[email protected]", "mobilePhone": "46586335", "name": "Test mPOS", "percentageComplete": "50", "phone": "1168031388", "plan": "Plan mPOS Básico", "rfc": "20289084488", "status": "N_VAL" }::
- Hasta este momento nosotros no estamos validando los datos que enviamos a
UserNode POSTniBankAccount POSTpero al parecer tcm tampoco, por lo que no estamos esperando un error en esta llamada. La pregunta es ¿TCM va a regresar algún error en estas llamadas? ¿Tenemos que validar algo del lado de flap?
DUDAS
- De aqui al igual que en la "confirmación de correo" no tenemos aún el html y css del correo.
Han mencionado una entrega el 25 de septiembre, pero lo más seguro es que no se pueda lograr entregar para esta fecha.
Creo que lo mejor que podemos hacer por ahora, es:
- Que vean lo que hay hasta ahora y nos retroalimenten para poder corregir lo antes posible.
- Ayudarnos a contestar las dudas.
- Continuar con el Mapa que relaciona los servicios con la aplicación, de preferencia agregando los posibles errores que el servicio maneja.
- Conseguir el html y css para los correos.
- Nosotros trataremos de integrar más gente, aunque sinceramente esto talvez tendría efecto hasta llegar a las secciones de transacciones y vendedores, que son las dos secciones que se pueden trabajar paralelamente, antes de eso la mayoría de las acciones son mejor trabajarlas en serie.