LG-6204: Populate initial values based on IdV app enabled steps#6318
LG-6204: Populate initial values based on IdV app enabled steps#6318
Conversation
|
Reverting to draft to implement step-specific handling for |
solipet
left a comment
solipet
left a comment
There was a problem hiding this comment.
This looks fine, although once we finish the password step, we can simply remove the personal key from the initial values altogether. Or is this causing a problem in the current personal key step, having the bundle included?
I expect we'd have the inverse problem: that generating the personal key before the user has entered their password will produce an unexpected outcome. In general, I think we'll run into less conflicts if we try to prepare only what's needed to get the application started based on the feature flag setting. |
**Why**: Because initial values should be limited to whichever step is earliest in the enabled set of steps. changelog: Upcoming Features, Identity Verification, Add password confirmation step
So that we can assert specific steps in specs via URL helpers, e.g. `idv_app_path(step: 'personal_key')`
aduth
force-pushed
the
aduth-lg-6204-enabled-step-initial-values
branch
from
dd01364 to
2a25208
Compare
| expect(assigns[:app_data]).to include( | ||
| app_name: APP_NAME, | ||
| base_path: idv_app_path, | ||
| completion_url: idv_gpo_verify_url, |
There was a problem hiding this comment.
We might need to rethink how we handle "completion URL", since it can be dynamic based on how the user proceeds through the flow. For example, if they opt to confirm address by mailed letter, the completion URL would be different than if they had verified by phone number.
Couple thoughts:
- Move this handling into a controller whose route can be statically populated into the application, and whose action logic would determine where to redirect user
- Change Personal Key step to submit to an endpoint which would be expected to respond with the redirect URL
**Why**: So that root URL renders the app
Because it's not yet implemented as of this branch
STEP_NAMES duplicates same info we should expect from enabled_step_names config
So step name is always in the URL
2 participants
Why: Because initial values should be limited to whichever step is earliest in the enabled set of steps.
Related: #6282 (comment)