search

opensrp / opensrp-client-eusm

OpenSRP client for EUSM
Other
0 stars 1 forks source link

User should still be able to log in to the app even if no active plan/mission assignment #69

Open cafootitt opened 3 years ago

cafootitt commented 3 years ago

We were trying to troubleshoot why users were suddenly unable to log in to the EUSM mobile app on Friday, March 5th. It turned out it was because the team assignment for that mission was revoked, because the plan/mission end date had been reached (https://github.com/OpenSRP/web/issues/538).

The error message the user got when trying to log in was unfriendly. It said something like Login failed, please try again later. So it was really hard to pinpoint why this was happening.

Shouldn't the user still be able to log in to the app even if they have no active plan/mission assignments? Perhaps a more user-friendly workflow would be to allow them to log in, but when they try to select a mission from the dropdown, it would be greyed out and if they try to tap on the dropdown, a toaster could appear saying no active mission assignment.

A less user-friendly alternative to the above, but better than the current situation, would be to allow the user to login and they would just see a blank dropdown list for missions.

@rowo Can you weigh in on this issue?

rowo commented 3 years ago

@cafootitt

  1. Sounds like a bug if a user isn't allowed to log in to the mobile app just because team assignment for one of their missions is revoked. Is it because they have zero mission assignments?
  2. More descriptive error messages would be great. I'm not sure how much information we have about errors at that stage.
  3. Yes, I think a user should be able to log in because they are still a user. They just have no active missions. Would this user even have any missions to select from in the case you are describing? I'm not sure how they would see missions exactly. What logic would drive what shows up in the mission list for a particular user if there are no assigned or active ones?
cafootitt commented 3 years ago
  1. Yes, I think it's because the user in question had zero mission assignments at the time
  2. I'm not sure what error states are possible at login, but if we're treating this as a bug and the fix will be to make sure the user can log in, this point is moot I think.
  3. In this situation, there would be no missions for the user to select from in the dropdown. Below is a screenshot of the mission dropdown in the side menu. Screenshot_20210309-075559_eusm
rowo commented 3 years ago

@cafootitt yeah, I guess I'm not really aware if this is a bug or an unavoidable glitch. I think from @bennsimon or someone else who works on Reveal it'll be good to understand what's on purpose and what's not.

cafootitt commented 3 years ago

@rowo We clarified on the standup this morning. This is actually not a bug, but how Reveal works currently.

The user has to be assigned to a team, that is assigned to an Active Mission/Plan, that has to have jurisdictions, to be able to log in. The error message shown is generic and not specific to this reason, making it a user-unfriendly failed login message.

mberg commented 3 years ago

Maybe we need to create a generic plan that is open that everyone is assigned too. Ideally we would just authenticate against he provider and not use the plan assignment as the basis for authentication. You should be able to login but just not have access to do anything.

rowo commented 3 years ago

@mberg If it's complex though (which creating a generic plan behind the scenes sounds like it could add some unforeseen problems), I don't think this issue is a big deal if at least we can provide a more informative error message for troubleshooting (so at least an admin could tell if someone were entering the wrong password or other user-error when not being able to log in).

The cost for a user isn't big (they don't gain much by logging in if they don't have access to anything anyways) and the situation shouldn't happen too often because the use cases are so guided, managed, and contained. This issue is more about helping the program/intervention manager and not about making things less confusing for the end user.

mberg commented 3 years ago

Agreed I think we can manage it right now. Eg make sure you are assigned to a mission or something like that. If there is an easy way that we just left yoh into the app and it says no missions that is ideal. We can get away with not having that right now if we want to limit new work

On Wed, Mar 10, 2021 at 5:22 PM Roger W. notifications@github.com wrote:

@mberg https://github.com/mberg If it's complex though (which creating a generic plan behind the scenes sounds like it could add some unforeseen problems), I don't think this issue is a big deal if at least we can provide a more informative error message for troubleshooting (so at least an admin could tell if someone were entering the wrong password or other user-error when not being able to log in).

The cost for a user isn't big and the situation shouldn't happen too often because the use cases are so guided, managed, and contained.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenSRP/opensrp-client-eusm/issues/69#issuecomment-796225643, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOEQK63JK45LNFOFMYZGDTC7PLBANCNFSM4YZRVWXA .

cafootitt commented 3 years ago

Ok, so what I'm hearing is as follows:

bennsimon commented 3 years ago

@cafootitt

Easiest option is to update the error message on login attempt to accurately reflect the reason the user is unable to login. We'll go with this approach if the LOE (see next point) for the next option comes back too high.

LOE 1 day

We'll also provide a LOE estimate for allowing the user to login but see that there are no missions assigned to her.

LOE 2 days plus 1 day of testing

rowo commented 3 years ago

Seems we should just do the 1 day, more informative error message approach. And it doesn't sound like it needs to be all errors — just "no missions so you can't log in" vs. a generic error ("login failed").

Other common login errors would be just nice to haves (i.e. not required): username is invalid or doesn't match, no account found,, password isn't right, no connection, too many attempts,

rowo commented 3 years ago

@cafootitt What I mean is, if those are the two choices, it would be the option. I agree with @mberg's earlier comment — this could be solved with information for admins and trainers and not necessarily an engineering fix e.g. I don't think it is high priority if we are trying to reduce work we have to do.

cafootitt commented 3 years ago

Low priority, we will not be picking this up right now.