Flap Status

150920-1-status.md

Estado actual del sistema

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.

Siguientes acciones

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.

1.- Login de usuarios previamente registrados en tcm

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.

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?

2.- Cerrar sesión

Hasta ahora no se puede salir de la sesión.

3.- Lidiar con token expirado

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.

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?

4.- Verificación de datos generales

DUDAS

• ¿Como sabemos cuando un record ya fue verificado?
• Hasta este momento nosotros no estamos validando los datos que enviamos a UserNode POST ni BankAccount POST pero 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?

5.- Recuperar contraseña

DUDAS

• De aqui al igual que en la "confirmación de correo" no tenemos aún el html y css del correo.

Estimado

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.

150920-2-tests.text

Accept contract
  stores that the user has accepted the contract

Complete general data
  has a text field for the business_name
  has a text field for the business_address
  has a text field for the business_phone_number
  has a text field for the mobile_phone_number
  has a text field for the rfc
  has a text field for the account_owner_name
  has a text field for the clabe
  has a select for the bank
  sends the information to tcm
    to update user_node with businessName
    to update user_node with address
    to update user_node with phone
    to update user_node with mobilePhone
    to update user_node with rfc
    to update bank_account with clabe
    to update bank_account with account
    to update bank_account with bankId
    saves when the general data was completed

Confirm email
  on success
    returns success
    changes the user status to 'confirmed'
  when the token is not right
    returns error
    does not change the onbording status

Login
  has a field for the email
  has a field for the password
  user login
    returns success
    does a login on tcm
    saves the user id on session
    stores the login token
    with bad params
      shows the error
      does not saves the user id on session
      does not stores the login token
      shows the previous data

Registration form
  has no errors when no error is given
  has field: first_name
    should eq nil
    should eq "--text--"
  has field: last_name
    should eq nil
    should eq "--text--"
  has field: email
    should eq nil
    should eq "--text--"
  has field: password
    should eq nil
    should eq "--text--"

Send registration
  on success
    returns success
    creates the user on TCM
    creates a user record with the email and confirmation token
    does login on tcm
    stores the login token
    stores the user id on the session)
    sends a confirmation email with a custom token
  on error
    returns the server errors
    returns the form with the received data
    does not sends the email
    does not create the record

Valid stage
  when there is no user in the session
  when the session has a user but the user has no tcm login token
  when the user is just created
  when the user is confirmed but has not accepted the contract
  when the user is confirmed, and has accepted contract
  when the user is confirmed, and has accepted contract, and has completed the general data

@bhserna mis comentarios en el fork: https://gist.github.com/ipoletti/2ba2499bd4c61864bfc5