LG-14749 Cancel enrollments on profile encryption error

[shanechesnutt-ft]

🎫 Ticket

Link to the relevant ticket:
LG-14748

🛠 Summary of changes

Cancel in-person enrollments when a profile is deactivated with reason encryption_error.

📜 Testing Plan

Scenario: User has a pending in-person enrollment and resets their password

• Login through the oidc sinatra application selecting the Identity Verified level of service.
• Create a new account
• Complete the ID-IPP flow reaching the ready to verify page.
• Logout
• Reset the password of the user.
• Login through the oidc sinatra application selecting the Identity Verified level of service.
• Ensure user is navigated to the welcome page.
• Ensure the in-person enrollment is update to have a status of cancelled.
• Ensure the user is able to complete the ID-IPP flow reaching the ready to verify page.

[matthinz]

Would there be any harm in doing the canceling of the enrollment in the background job? Like when we go to check on the status of the enrollment, notice the profile is deactivated, and deactivate the enrollment. If the profile is out of sync with the enrollment in the time between when the profile is deactivated and we next check on the enrollment, is that bad?

[shanechesnutt-ft]

There is logic in place that handles cancelling enrollments with profiles that are deactivated in the background job. The issue with it is that users are able to attempt to schedule an enrollment before the pending enrollment is cancelled because of the 30 min / 1 hour window of the background job. If it doesn't make sense to cancel it at the point of encryption error, maybe it would be better to have a check during the ID-IPP workflow to cancel any existing pending enrollments like we do with existing establishing enrollments.

[shanechesnutt-ft]

The profile and in-person enrollment models are tightly coupled which is why I thought it is important that we try to keep them in sync. So when one becomes in a dead state the other should also be in a dead state.

[matthinz]

Gotcha, that makes sense to me

[gina-yamada]

Testing Notes

• Login through the oidc sinatra application selecting the Identity Verified level of service.
• Create a new account
• Complete the ID-IPP flow reaching the ready to verify page.
• Logout
• Reset the password of the user.
• Login through the oidc sinatra application selecting the Identity Verified level of service.
• Ensure user is navigated to the welcome page.
• Ensure the in-person enrollment is update to have a status of cancelled. I also checked the profile was not active and had a deactivation reason set to encryption error. (I checked on view /verify/welcome) (I did check before I signed in but no updates to profile and enrollments were made, this is as I'd expect.)
• Ensure the user is able to complete the ID-IPP flow reaching the ready to verify page.
• Additionally, I ran through the above steps but checked that I could successfully complete remote flow

[n1zyy]

I'm not sure what it means to approve a draft PR, but this all looks good to me!

[n1zyy]

Irrelevant mumblings: my brain always reads this as though it means be_somewhat, like be_kind_of(:confusing) or such. It obviously doesn't make any sense that that would be a matcher, though.

I was going to comment that I prefer be_a_kind_of which reads much better, but in searching the code, be_kind_of is much more common so we should stick with it. (It's kind_of(:a_bummer) though.)

[n1zyy]

👏 for adding tests for this class!

[n1zyy]

👏 for adding thorough tests to this class that previously had none. 😃

[n1zyy]

Suggested change

	context 'when the active profile was activated before the pending profile as created' do
	context 'when the active profile was activated before the pending profile was created' do

Is that how this is supposed to read?

[shanechesnutt-ft]

Nice catch! I will update that!

[matthinz]

Ok, we had a little back and forth about whether or not to clear in_person_proofing_verification_at when canceling. Where we ended up was to keep the timestamp in place so that we're consistent with what we do in other cases when we cancel profiles.

This all LGTM, with the caveat I haven't actually tested it--I'll leave the IPP portions to y'all.

[eileen-nava]

Hi, as I noted in slack here, I am not clear on the benefit of leaving the in_person_verification_pending_at timestamp populated. The main stated benefit seems to be that leaving the timestamp populated indicates what kind of profile it was before cancellation. However, that information is already available from the idv_level field.

I am still approving the PR. That being said, I’d appreciate clarity from Ada Engineering on the benefit of leaving the in_person_verification_pending_at timestamp populated. Thanks!

P.S. Shane, great work adding tests! 👏🏻