Login & Register

[MurhafSousli]

@adrianq @ifoche @jordibc I was wondering how would the user login with his username while our register form doesn't have a username input!

I can think about 2 options:

1. Using his email

Replace login username with email in LoginPage

2. Using his username

Replace name and surname with one input full name or real name (to reduce the number of inputs)
and add the username input in RegisterPage

[ifoche]

Hi @MurhafSousli, in the original design, when you request a user you were actually doing that, a "user request". So it's the admin who was in charge of assigning you the username and providing it to you through the notification system.

In principle, when you request a user, the app won't let you access until the admin will assign you a user, and once the admin will assign you the user, next time the user opens the app, you will get a notification saying "The admin has approved your request and assigned you the following credentials: XXXX".

And you may now have the following question: ok, that explains it, but then we didn't provide in the mockup the way for the admin to explicitly write the username assigned to the user. In that sense, you're right, there's nothing showing that in the mockup. The supposed behavior was:

• If the admin clicks on "Accept", an automatic algorithm will assign it and send to the user
• If the admin clicks on the rest of the space of that element of the list, then a pop-up asking for the username and the answer ("Accept" or "Reject") would appear. Sorry, that's not in the mockup

I hope this clarifies the desired behavior.

[adrianq]

@ifoche I am currently discussing your answer with @MurhafSousli and we have two questions for you:

• We currently have password field. Should we keep it or password will be assigned by the admin as well?
• You said 'next time the user opens the app, you will get a notification...' How do we know who is the user? I mean we will be sending the IMEI of the mobile or sth like that? How does the server know this person already register for a new user?

[ifoche]

Hi @adrianq,

Good point. It may be useless to let the user choose his password not choosing his username. Maybe we can just remove it. As for the other question, I guess we will have to identify the request with some auto-generated ID and make the app ask for that request state on each app start. Would that work?

[adrianq]

@ifoche we can talk about this in our next FIRE meeting. We are not particularly sure about this workflow. Our main concern is that the user will receive a user and password next time he opens the application and... does he need to write it down? Why doesn't he receive an email? Otherwise, he will have to come back to the app once and again to double check if he finally has a user. Or even better why doesn't he choose the username/pw when he is creating the user? Anyway, not a high priority for now...

[MurhafSousli]

Currently on app launch:

• The app will look into the secure storage for the "login data", if it finds it, it should automatically log in, otherwise redirect to login page.

Now, with this approach we have another task on app launch

• The app will look into secure storage for the "request new user" data (a data that indicates that the user has requested a new account and he is waiting for approval), if true send a HTTP request to get the account status (accepted/rejected/pending), otherwise don't send a request!

this data will be stored in secure storage on user registration and will be removed when user gets the approval

I am not sure about the reliability of this approach, assume the app crashed for any reason, or the phone suddenly turned off while the user is writing down his generated username & password, how can I he get them back?

[MurhafSousli]

I just forgot to mention that the current mock server expects a username field in the register form

[ifoche]

@jordibc just mentioning you in this issue, as it's related to what you're probably working on in the near future :)

[ifoche]

Just to keep track of our conversation, @jordibc and I were discussing today about the possibility of implementing the register as in its original design, by creating a request UID on every new register, and checking that request UID against the WS from the app, to avoid the implementation of an alternative way to send the user/pass via SMS.