LG-6927: Omit in-person troubleshooting option when already in flow#6687
LG-6927: Omit in-person troubleshooting option when already in flow#6687
Conversation
**Why**: So that the user doesn't get stuck in a loop of attempting to troubleshoot by verifying in-person. changelog: Upcoming Features, In-person proofing, Hide in-person troubleshooting option while already in flow
No longer using request path
|
Screenshots look good 👍 Is this also an issue with the remote proofing flow, and if so, does this or a different PR cover that? |
The way the ticket was phrased, my understanding is that we'd want it to continue to show as an option for the verify step in the remote unsupervised flow, and to only hide it in the in-person flow so that the user doesn't get stuck in a loop. If we want to hide it from all of these exception / "outage" cases, regardless of flow, I can make that revision (it would simplify things, actually). |
Actually, thinking on this more, I can see that we wouldn't want the option to ever show on this screen, since at least with the way it's set up currently, the location selection can only occur during document capture, and generally it seems like we want to limit entry to coming from document capture. Aside: I think there's another option implemented in the FSMv2 generic error page that we'd also probably want to remove? |
That's right... the IPP flow is only set up as a path for failing document capture/"Verify your ID". So we wouldn't want the option to appear in any scenario after the user fails "Verify your personal details". Would be great if we could clean that up in this or a follow-up PR, thanks! |
👍 Makes sense. I pushed 76dd34d, which removes the troubleshooting option from everywhere other than the document capture warning page. This includes:
|
| * URL to in-person proofing alternative flow, if enabled. | ||
| */ | ||
| inPersonURL: string | null; | ||
| inPersonURL?: string | null; |
There was a problem hiding this comment.
Will this do?
| inPersonURL?: string | null; | |
| inPersonURL?: string; |
There was a problem hiding this comment.
Based on usages, I expect not. inPersonURL?: string really means that the key should be absent - i.e. not null nor even set to undefined though that is often still safe.
There was a problem hiding this comment.
I'll check to see if we're setting it null anywhere currently, and if not, will try to simplify to inPersonURL?: string.
There was a problem hiding this comment.
Needed a couple updates, but simpler overall. Updated in b4493c9.
`null` and `undefined` are both used as "empty" values, prefer one. Also simplifies defaulting behavior in document-capture, since it would be assumed to be undefined when absent, previously coerced to null.
* Verify establishing enrollment for in-person flow **Why**: Since a user will need to select a location as part of establishing an enrollment before proceeding with the in-person flow. changelog: Upcoming Features, In-person proofing, Verify establishing enrollment for in-person flow * Invalidate applicant when assigning PII * Refactor verify step PII methods as abstract Avoid ambiguity between the two implementations * Avoid reinitializing IdV session when blank Seems to cause issues with replacing an existing session values, leading to session being empty at points-in-time where it's not expected to be, purely by referencing idv_session (e.g. in DocAuthController#redirect_if_session_applicant) * Update specs after rebase for #6687 * Rename before_action to describe intent, not implementation See: #6703 (comment)
4 participants
Why: So that the user doesn't get stuck in a loop of attempting to troubleshoot by verifying in-person.
Testing Instructions:
Screenshots: