-
Notifications
You must be signed in to change notification settings - Fork 166
LG-6708 Add additional columns to in_person_enrollments table #6556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
a85a680
29c14c5
02a0dc9
801c261
8593c09
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,11 +2,12 @@ class InPersonEnrollment < ApplicationRecord | |
| belongs_to :user | ||
| belongs_to :profile | ||
| enum status: { | ||
| pending: 0, | ||
| passed: 1, | ||
| failed: 2, | ||
| expired: 3, | ||
| canceled: 4, | ||
| establishing: 0, | ||
| pending: 1, | ||
| passed: 2, | ||
| failed: 3, | ||
| expired: 4, | ||
| canceled: 5, | ||
|
Comment on lines
+5
to
+10
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In general I think renumbering enums like this is dangerous.... since we haven't launched yet this is probably fine. I think it would preferable to do
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Due to it not being in production we won't break anything also establishing is the phase that comes before pending so logically that order makes sense |
||
| } | ||
|
|
||
| validate :profile_belongs_to_user | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| class AddAddressAndLocationToInPersonEnrollment < ActiveRecord::Migration[6.1] | ||
| def change | ||
| add_column :in_person_enrollments, :current_address_matches_id, :boolean, comment: "True if the user indicates that their current address matches the address on the ID they're bringing to the Post Office." | ||
| add_column :in_person_enrollments, :selected_location_details, :jsonb, comment: "The location details of the Post Office the user selected (including title, address, hours of operation)" | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does USPS give us any location identifier we could use instead of storing a blob of the full details? A concern I'd have is that we'd be storing a lot of duplicate data with this.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unforunately there's no API to look up locations by ID at this point
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we need to be able to do a look-up with this field data? I'd wonder if we could at least create our own identifier as e.g. a fingerprint/hash of the location data blob.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, we won't need to do a look-up with this field data, for now. |
||
| end | ||
| end | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| class ChangeUniqueStatusConstraintOnInPersonEnrollments < ActiveRecord::Migration[6.1] | ||
| disable_ddl_transaction! | ||
|
|
||
| def up | ||
| remove_index :in_person_enrollments, name: 'index_in_person_enrollments_on_user_id_and_status', algorithm: :concurrently if index_exists?(:in_person_enrollments, [:user_id, :status], name: "index_in_person_enrollments_on_user_id_and_status") | ||
| add_index :in_person_enrollments, [:user_id, :status], unique: true, where: '(status = 1)', algorithm: :concurrently | ||
| end | ||
|
|
||
| def down | ||
| remove_index :in_person_enrollments, name: 'index_in_person_enrollments_on_user_id_and_status', algorithm: :concurrently if index_exists?(:in_person_enrollments, [:user_id, :status], name: "index_in_person_enrollments_on_user_id_and_status") | ||
| add_index :in_person_enrollments, [:user_id, :status], unique: true, where: '(status = 0)', algorithm: :concurrently | ||
| end | ||
| end |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reading the associated ticket, if the new
establishingstatus is meant to allow us to create an enrollment record before we've called out to the USPS API, would it also be expected that the Enrollment'sprofilecould now also be optional? I guess I'm imagining a scenario where we create the enrollment early enough in the process that the profile hasn't been created yet, we'd need to save it without a profile, and update it later to assign the profile (when the profile is created at the password submission step).Am I understanding correctly, @x341x @tomas-nava ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following up on this; at the moment the enrollment is only in
establishingfor a few moments before it's set topending, and this all happens when the profile definitely exists. If we end up needing to create the enrollment earlier, we will think about whether the profile should be optional.