LG-9515: Refactor capture_secondary_id_enabled#8344
Conversation
Because these classes all inherit from `DocAuthBaseStep` and define the method in the exact same way, we can DRY it up by removing the method from the descendant classes.
aduth
left a comment
There was a problem hiding this comment.
Will In-Person Proofing be moving away from FlowStateMachine (the "step" implementations) like what is currently happening with Unsupervised Proofing? If it were, maybe it'd be better to move the common behavior into a concern/mixin rather than the base step, which would be more portable to a controller once DocAuthBaseStep goes away.
|
@aduth that's a really good call out. We are planning on making that change in the future, though we have a ways to go. Since it's a single method, I'm not sure it makes sense to create a new mixin/concern to house it at this exact moment, but I don't have a strong opinion. |
We are planning to move these pages out of the FSM at the same time they're being consolidated into a single-page form, in LG-9443 and related tickets. That's a major refactor so I think it's fine to wait until then to worry about where this method lives. |
svalexander
left a comment
There was a problem hiding this comment.
LGTM. It's nice to be able to delete stuff!
🎫 Ticket
LG-9515
🛠 Summary of changes
Refactored the
capture_secondary_id_enabledmethod to be defined onceBecause these classes all inherit from
DocAuthBaseStepand define themethod in the exact same way, we can DRY it up by removing the method
from the descendant classes.
📜 Testing Plan
with
capture_secondary_id_enabledin_person_capture_secondary_id_enabledVerify your informationheading, you see subheadings ofState-issued ID,Residential address, andSocial Security Numberwithout
capture_secondary_id_enabledin_person_capture_secondary_id_enabledVerify your information