LG-6160: Add personal key validation behavior

[aduth]

Why: As a user, I expect feedback if I have incorrectly entered the personal key, so that I can correct my mistakes and continue with the proofing flow.

Testing Instructions:

1. Set idv_api_enabled: "true" in local config/application.yml
2. Go to: http://localhost:3000/verify/v2/personal_key_confirm
3. Click "Submit"
4. Observe error "You've entered an incorrect personal key", and that focus is returned to the field
5. Enter some text
6. Observe that the error is removed after input, consistent with other IdP inputs
7. Enter a correctly-formatted, but incorrect personal key (e.g. "0000-0000-0000-0001")
8. Click "Submit"
9. Observe error "You've entered an incorrect personal key", and that focus is returned to the field
10. Enter the correct personal key "0000-0000-0000-0000"
11. Click "Submit"
12. Observe there is no error message

Screenshot:

Draft Progress:

• Improve test coverage

[aduth]

Future refactoring could see about eliminating this custom idea of isRequired and just use element.validityState.valueMissing in combination with <input required>.

[aduth]

This change is necessary because the personal key confirmation modal content is rendered outside the <form> element, due to the createPortal usage in <FullScreen />. While React does support event bubbling through portals, the submit event is never fired by the browser, since the button is technically not within a form.

Example: https://codepen.io/aduth/pen/KKZEPER

[aduth]

This change is necessary because the personal key confirmation modal content is rendered outside the <form> element, due to the createPortal usage in <FullScreen />. While React does support event bubbling through portals, the submit event is never fired by the browser, since the button is technically not within a form.

Example: https://codepen.io/aduth/pen/KKZEPER

An issue with this approach is that we also want to support implicit submission (i.e. pressing Enter from a field to submit), which relies on a submit button being present within the same form.

If the form has no submit button, then the implicit submission mechanism must do nothing if the form has more than one field [...] whose type attribute is in one of the following states: Text, Search, URL, Telephone, Email, Password, Date, Month, Week, Time, Local Date and Time, Number

I found an alternative solution to the portal form submission challenge in bea0810 by using an empty <form> tag , which tricks the browser into emitting the submit event. As mentioned in the previous comment, React will bubble this event across the portal boundary to be handled by FormSteps.

[aduth]

There's not really a rhyme or reason to why some values are in context and others are in props. I think it would make sense to pass all the same values, both as props, and as context.

const context = { toNextStep() {} /*, ... */ };
return (
  <FormStepsContext.Provider value={context}>
    <FormStep {...context} />
  </FormStepsContext.Provider>
);

[nprimak]

LGTM!

[aduth]

Kinda an edge case, but I spotted an issue with this revised logic. When a user uploads invalid documents on the document capture step and we need them to re-upload, we expect that they would not be able to submit until they replace both front and back. With the revised implementation here, they would have been allowed to submit after replacing any of the values.

I added a failing regression test case in d02093076 and am working to revise this a bit, hopefully returning more to the previous logic.

[zachmargolis]

Unsure if it's the same bug... but when I was testing doc auth in staging yesterday, I accidentally set the front image for both front and back, so the real fix was to only replace back image, but I had to replace both images in order for the form to let me go

[aduth]

Unsure if it's the same bug... but when I was testing doc auth in staging yesterday, I accidentally set the front image for both front and back, so the real fix was to only replace back image, but I had to replace both images in order for the form to let me go

I think in the majority of cases it's expected that the user will need to replace both, at least based on my recollection of how the back-end error logic is rarely able to pinpoint issues with a specific side.

[aduth]

Unsure if it's the same bug... but when I was testing doc auth in staging yesterday, I accidentally set the front image for both front and back, so the real fix was to only replace back image, but I had to replace both images in order for the form to let me go

Also, were you using real images which would normally pass, since staging would be running the actual vendor code?

[zachmargolis]

yup staging, real vendors, real images that would have passed if I put the right back image in the right field

[aduth]

I checked the logs and it looks like the back-end had reported an error on both sides of the image in that attempt.

properties.event_properties.errors.back.0 | Please add a new image
properties.event_properties.errors.front.0 | Please add a new image
properties.event_properties.errors.general.0 | We couldn’t verify your ID. Try taking new pictures.

A closer look at failed authentication tests shows that it failed "Document Classification", which isn't associated with a particular side.

identity-idp/app/services/doc_auth/error_generator.rb

Line 33 in d92c7af

'Document Classification': { type: ID, msg_key: Errors::ID_NOT_RECOGNIZED },