LG-13763: Stop writing to the proofing_components table#11564
Conversation
Just stop. These values are now generated dynamically as we need them, then serialized to the Profile. [skip changelog]
I moved idv_session to be public on the controller (matching the behavior of other controllers that use IdvSessionConcern). Then updated tests to use dynamically-generated proofing components. This requires reloading the user object. I created https://cm-jira.usa.gov/browse/LG-15167 to address computing the proofing component value without using the User object
We don't have access to idv_session here so we have to wait until the proofing component has been written to the database so we can access it.
We were clearing out the _user's_ proofing component here, but not doing anything with the profile.
n1zyy
left a comment
There was a problem hiding this comment.
I certainly like the idea of this. The tests made me realize I might not understand the whole picture here as well as I thought I did. That's likely on me. I wouldn't mind syncing up next time we're both online, unless someone beats me to approving this.
| user:, | ||
| ) | ||
|
|
||
| expect(proofing_components.document_check).to be_nil |
There was a problem hiding this comment.
I feel like I'm missing some context here. Is an equivalent to Idv::ProofingComponents.new happening in the controller?
There was a problem hiding this comment.
Idv::ProofingComponents reads info from sessions (Rails, user, and Idv::) to derive the current components. Previously the controller was updating the proofing_component attached to the user. Here we're just taking the various sessions the controller is interacting with and essentially checking that it made the changes we are expecting. You could make an argument that this test might be duplicative now (we should be testing that the controller is updating Idv::Session appropriately elsewhere)
|
This was previously blocked by #11527, which is now in prod. Sooooo.... |
We missed this when we got rid of the ProofingComponent model in #11564 [skip changelog]
We missed this when we got rid of the ProofingComponent model in #11564 [skip changelog]
We missed this when we got rid of the ProofingComponent model in #11564 [skip changelog]
Since #11564 we've stopped writing to this table, so now is the time to drop it. This table was previously used as a temporary datastore for proofing component values as a user moves through IdV. We now dynamically derive those values from the Idv::Session, so this table is not needed any longer. [skip changelog]
* Drop proofing_components table Since #11564 we've stopped writing to this table, so now is the time to drop it. This table was previously used as a temporary datastore for proofing component values as a user moves through IdV. We now dynamically derive those values from the Idv::Session, so this table is not needed any longer. [skip changelog] * Update db/primary_migrate/20250106232958_drop_proofing_components_table.rb Co-authored-by: Zach Margolis <zachmargolis@users.noreply.github.com> --------- Co-authored-by: Zach Margolis <zachmargolis@users.noreply.github.com>
🎫 Ticket
Link to the relevant ticket:
LG-13763
🛠 Summary of changes
ProofingComponentis a model that tracks, in general terms, how a user has verified their identity. It exists in a 1:1 relationship withUser, which gets kind of sticky / tricky for users with multiple Profiles.Proofing components are useful for logging purposes, so we want to keep them. But instead of storing them attached to
Userin this way, we are now dynamically deriving them from the user'sIdV::Session.So then, now that we are doing that, we can stop writing to the old user-bound
proofing_componentsstuff. That's what this PR does. We'll be dropping the table itself in a future PR.