LG-10091 FSM/SSN - Move Extra Analytic Properties to A Shared Concern

[gina-yamada]

🎫 Ticket

LG-10091 FSM/SSN - Move extra analytics properties to a shared concern

🛠 Summary of changes

• Move extra analytics properties to a shared concern (so that each of the steps in the non-FSM version can use it)
• Refactor app/controllers/idv/in_person/verify_info_controller.rb to use shared concern
• Added extra analytics properties to non-FSM ssn step so it would have same_address_as_id

📜 Testing Plan

1. Run through the steps👇 on main branch with in_person_ssn_info_controller_enabled set to false in application.yml. This shows the analytic property currently being added to the FSM version on the SSN step. (See Scenario 1 in screenshots)

2. Run through the steps👇 on main branch with in_person_ssn_info_controller_enabled set to true in application.yml. This shows the analytic property currently not being added to the non-FSM version on the SSN step. (See Scenario 2 in screenshots)

3. Run through the steps👇 on gyamada/LG-10091-extra-prop branch with in_person_ssn_info_controller_enabled set to true in application.yml. This shows the analytic property has been added to the non-FSM version on the SSN step. (See Scenario 3 in screenshots)

4. Run through the team Ada's flow on gyamada/LG-10091-extra-prop. This shows the analytic property has not been added to the SSN step for the doc auth flow. (See Scenario 4 in screenshots)

Steps:

1. Set in_person_ssn_info_controller_enabled to false in application.yml
2. Open file events.log inside log
3. Start server to run locally.
4. Create an account. Confirm email. Set up a password. Set up Authentication method. Change url to /verify to Get started verifying your identity. Upload photos to fail proofing and proceed to Try in person.
5. Fill out forms until you land on url /verify/in_person/verify_info
6. Open up events.log and search for ssn. View the properties for both IdV: doc auth ssn visited and Idv: doc auth ssn submitted. Both should have field same_address_as_id and the value should match what your selection was.

👀 Screenshots

Scenario 1:

Scenario 2:

Scenario 3:

Scenario 4:

[gina-yamada]

To whoever reviews this pull request- Please run rpec/features/idv/steps/in_person/ssn_spec.rb and report your findings. I can run this file 3 times and get different pass/fail results. In the flow you will eventually hit complete_location_step which has a pause for the location list to disappear and a rescue for Selenium (a stale element reference). It is inconsistent locally for me. Maybe slow internet but wouldn't mind a check to see if okay. Inconsistent failing tests are the worst. Wondering if this is a concern if other experience this locally too?

May need to add Webdrivers::Chromedriver.required_version = '114.0.5735.90' to railers_helper.rb on line 99, see Slack thread.

[svalexander]

do we not need tests for threatmetrix?

[gina-yamada]

@svalexander Good point! I can see threatmetric_session_id on flow_session on ssn step for both fsm and non-fsm so I put threatmetrix_session_id back onto flow_session (for test data) and added two tests.

See commit 073e2f2

[svalexander]

LGTM. Running the ssn spec passed for me (I ran 3 times).

[gina-yamada]

LGTM. Running the ssn spec passed for me (I ran 3 times).

Thanks for running them! My internet has been slow today and I think that may have caused these inconsistencies. I dug into them but never once observed failure when the pipeline ran them