Skip to content

LG-8948: Swap order of form steps "Location" and "Prepare"#8125

Closed
allthesignals wants to merge 33 commits intomainfrom
8948-move-search
Closed

LG-8948: Swap order of form steps "Location" and "Prepare"#8125
allthesignals wants to merge 33 commits intomainfrom
8948-move-search

Conversation

@allthesignals
Copy link
Contributor

@allthesignals allthesignals commented Apr 3, 2023

🎫 Ticket

🛠 Summary of changes

Before we showed the location selection step, then the "prepare" step.

This PR changes the order to show the "prepare" step first, then the location selection step.

📜 Testing Plan

  • Currently updating tests to reflect this new order

@allthesignals allthesignals marked this pull request as ready for review April 5, 2023 15:53
Comment on lines 142 to 146
expect(page).to have_css(
'.step-indicator__step',
text: t('step_indicator.flows.idv.find_a_post_office'),
wait: 10,
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we could move the wait somewhere a little more precise to the actual user interaction that requires an asynchronous delay. I notice we're also changing logic around click_spinner_button_and_wait. Ideally it'd be good if we could use that helper and avoid adding the wait to these other assertions, particularly on screens where we're not expecting a wait.

Copy link
Contributor

@eileen-nava eileen-nava left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is coming along well. It looks like you still need to complete some AC for changes to the "verify page" and the "find a participating post office" page. Also, I thought Andrew had a good point about the usage of wait in feature tests.

e.target.disabled = false;
e.target.click();

e.preventDefault();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it would be helpful to add some comments to this area of the code?

# Conflicts:
#	app/javascript/packages/document-capture/components/in-person-call-to-action.tsx
#	app/javascript/packages/document-capture/components/in-person-prepare-step.tsx
#	spec/features/idv/in_person_spec.rb
Comment on lines -89 to +92
'IdV: in person proofing location visited' => { flow_path: 'standard', in_person_cta_variant: 'in_person_variant_a' },
'IdV: in person proofing location submitted' => { flow_path: 'standard', selected_location: '606 E JUNEAU AVE, MILWAUKEE, WI, 53202-9998', in_person_cta_variant: 'in_person_variant_a' },
'IdV: in person proofing prepare visited' => { flow_path: 'standard' },
'IdV: in person proofing prepare submitted' => { flow_path: 'standard' },
'IdV: in person proofing location visited' => hash_including(flow_path: 'standard'),
'IdV: in person proofing location submitted' => { flow_path: 'standard', selected_location: '606 E JUNEAU AVE, MILWAUKEE, WI, 53202-9998', in_person_cta_variant: 'in_person_variant_a' },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After merging in origin/main, this test appears to fail by skipping the search page altogether.


expect(page).to have_content(
t('in_person_proofing.headings.prepare'), wait: 5
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test appears to be failing because there is a delay in switching to the address page.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NavaTim from what I can tell, this test is failing because capture_secondary_id_enabled is being set to true in the state_id_step, which is causing all of the additional fields that are normally hidden behind that flag to be displayed.

State ID step: capture secondary id enabled: true
DAV in the test: false -> this is a default value
Same address in the test: true -> this is a default value

It seems that setting the config value is toggling the value in the User enrollment. I'm not sure how or why this is happening.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The enrollment's value is determined when it's created based on the config value at that time. If you intend to test with DAV disabled, then you need to ensure it's disabled at the time that the location step is completed for that enrollment. This is by design.

That said, based on prior observations I expected that this test might be failing instead because the unload prevention dialog wasn't properly disabled before redirecting from the prepare page.


if (!isSubmitting) {
setIsSubmitting(true);
removeUnloadProtection();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may need to add this function call to the location step.

@JackRyan1989
Copy link
Contributor

Closing in favor of #8308

@tomas-nava tomas-nava deleted the 8948-move-search branch May 4, 2023 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants