LG-7943: Avoid showing in-person option for field validation errors

[aduth]

🎫 Ticket

LG-7943

🛠 Summary of changes

Updates display of document capture troubleshooting option to avoid rendering in-person call-to-action when field validation errors exist.

📜 Testing Plan

• yarn test passes
• Attempting to submit with field validation errors (e.g. empty fields, images with blur or glare) does not present in-person option

👀 Screenshots

Before:

After:

[allthesignals]

LGTM!

[allthesignals]

I wonder if hasErrors should be renamed to something more specific to IPP hasDocCaptureErrors or something

[aduth]

I wonder if hasErrors should be renamed to something more specific to IPP hasDocCaptureErrors or something

I was on the fence about making some further revisions to the props, because I also think there's some redundancy between showInPersonOption and hasErrors, at least in how they're both currently used exclusively in determining whether to show in-person troubleshooting options.

identity-idp/app/javascript/packages/document-capture/components/document-capture-troubleshooting-options.tsx

Lines 26 to 34 in c2a3697

	/**
	* Whether to include option to verify in person.
	*/
	showInPersonOption?: boolean;
	/**
	* If there are any errors (toggles whether or not to show in person proofing option)
	*/
	hasErrors?: boolean;

For example, we could collapse them to a single prop, and maybe name it in such a way that allows for future off-ramp alternative proofing options to use (e.g. showAlternativeProofingOptions), especially since we're also still considering inPersonURL to control whether the feature is available for the current service provider.

[aduth]

I wonder if hasErrors should be renamed to something more specific to IPP hasDocCaptureErrors or something

I was on the fence about making some further revisions to the props [...]

I gave this a shot in dfad071.

[allthesignals]

Love it! Way more semantic. Ty.

[allthesignals]

Test expanded to capture bug

[aduth]

Test expanded to capture bug

I'd contemplated not including any spec coverage here, since the way it had been implemented was as as additive feature of the documents step, and ideally I'd be removing whichever spec had asserted its presence, but one did not exist. But with all the different conditions involved in rendering troubleshooting options, I figured it wouldn't hurt to check that it's not visible when we're not expecting it to be.