Placing a form at the Login page

Use case: A CHV would initiate a request to get the SMS containing the Magic Link by submitting a form from their app. Since they are already logged out, is there a way for the form to reside at the Login page so that they can fill out the form with their details and then submit the form ?

Tagging @mrjones since this is Magic Links and he might have had some thoughts on this workflow…

@iesmail what usecase(s) did you have in mind for this functionality? E.g.:

  • User changing to a new device
  • User was accidentally logged out (so similar to a “Forgot password” flow)
  • Onboarding new users

I am also curious to hear your thoughts on what “details” would be collected by the form.

The usecase am referring to is the Forgot Password worfkflow. Details collected by the form are the name of the chv/supervisor and their phone number.

Thanks for reaching out @jkuester !

And thanks for the suggestion @iesmail . We have a pretty old issue that I’ve added your suggestion to and I’ll also add a link to our other forum post.

The problem with submitting a form is that you’re not logged in. This means the CHT would be open to accepting forms from anonymous users without a username or a password, which is not ideal.

@iesmail - Is it tenable to have do the communication outside the CHT, something like CHW → SMS → Supervisor → SMS → CHT Admin?

@jkuester - I wonder if a 3rd variant of “Create User for contacts” might be, instead of creating a user, a supervisor could just initiate sending the token login link for an existing contact. In our prior efforts (offline user replace & super CHW create) we thought they would be easier and were wrong - this one actually sounds like might be easy easy! Thoughts?

@iesmail - would supervisors being able send a token login link for any CHW under them be viable?

Ohh this seems like an interesting idea! So the workflow would be something like:

  • CHW accidentally logs out (or has to change to a new device)
  • CHW notifies their supervisor, asking for a new token login link
  • Supervisor submits a form referencing the CHW’s contact
  • That form triggers the server to generate and send a new token login link

How effective would something like that be at addressing your concerns @iesmail?

@mrjones, regarding implementation difficulty, this should basically be identical to the create_user_for_contact logic, but without actually creating a new user (just reset the password and send a new link).

Yay! I’m glad to hear it sounds like an interesting idea @jkuester ! The more we can get valid from-the-field requests like from @iesmail to empower Supervisors, the more helpful the CHT can be at getting CHWs returning to delivering care! \o/

@iesmail - let us know what you think of this idea!

Would you be open to redirecting this ‘forgot password’ form to a third-party endpoint? As you mentioned, it is problematic for CHT to store requests from unverified users. If we can redirect this special form to a third-party endpoint, we can explore options for simple phone verification and the generation of magic links for verified users.

The goal of this approach is to minimize intermediaries and allow each user to directly retrieve their password.

I’m curious to hear your thoughts on this.

@nKataraia - thanks for joining the discussion! It’s always nice to get more input on the viability of any given solution.

redirecting this ‘forgot password’ form to a third-party endpoint

We’re thinking of re-using the ability for a supervisor to submit a form which would send a magic link to the CHW’s phone number on file. the form you’re talking about would be submitted the the CHW’s supervisor or the CHW directly?

@mrjones - Since Supervisors also use CHT, relying on them as the main generators of magic links necessitates a higher-level to handle their own password request, reintroducing a centralised approach that proves inconvenient for all parties involved.

Supervisors meet with CHVs on monthly basis. From experience, for some supervisors, technical issues faced by CHVs, including password requests, tend to accumulate until the end of the month when they’ll meet, leading to unnecessary waiting time for CHVs. Bearing in mind also, that these Supervisors are workers at health facilities and already have a lot in their plates, removing this password retrieval workflow from them will greatly be appreciated.