LG-7167: Verify establishing enrollment for in-person flow#6703
Conversation
**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
Avoid ambiguity between the two implementations
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)
sheldon-b
left a comment
sheldon-b
left a comment
There was a problem hiding this comment.
This all makes sense to me!
Not blocking for this PR but I think that the base steps (verify base and doc auth base) and the idv session files are pretty challenging to grok as a newcomer. They have layers of checks and redirects and tweaks to the session that are hard to follow or understand without tracking down why they were added. I don't have any particular suggestions right now (other than to stop inheriting from doc auth base classes in the in-person flow) but it'd be nice to try and improve them after the pilot
tomas-nava
left a comment
tomas-nava
left a comment
There was a problem hiding this comment.
approve!
I'll echo Sheldon's comments on the opacity of the logic here, but definitely something to be addressed in future PRs.
|
Yeah, I agree. Some of that also comes back to the desired goals of FSMv2, which included the ability to implement steps as simple controllers, rather than extending step classes, or mixing in FSM concerns. |
3 participants
Why: Since a user will need to select a location as part of establishing an enrollment before proceeding with the in-person flow.