-
-
Notifications
You must be signed in to change notification settings - Fork 498
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
3251 limit distribution date #3453
Conversation
…on date save issue fixed to confirm manually / with system tests
One issue we have is that at least one of the distributions has items that are not available at the indicated storage location. This is going to take a bit more thought -- or we reach out to them and say "can we delete this record"? But that has potential run-on effects too. Or -- I can just do an update_attribute rather than an update! That'll work. |
Distribution.unscoped.where("issued_at < ?","2000-01-01").find_each do |dist| | ||
# Using update_attribute, rather than update! because some of the distributions | ||
# will not validate for other reasons (storage locations missing items) | ||
dist.update_attribute(:issued_at, dist.created_at) |
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.
You can actually do this in a single SQL call which might be less error prone:
Distribution.unscoped.where("issued_at < ?","2000-01-01").
update_all('issued_at=created_at, updated_at=NOW()')
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.
Is the intent of updated at when the user last touched it, or when it was changed in the db? Because if the former, we shouldn't touch it. I know we've had some reports that have been based on the updated_at -- I think in error, but I am feeling a bit cautious about touching it here.
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.
I'm pretty sure from my inventory drift investigations that there are some occasions when we are not touching it in error also... (sigh) We should, perhaps, have someone dig into that.
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.
Yes, updated_at
should, by convention, always be when the record was updated for any normal reason even if not caused by a human interaction. So like a background job or something should update it. Probably a good best-practice to update it as part of this change.
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.
Yeah --That's what I would have assumed -- but I noticed that we aren't in some cases when I was working on the inventory drift problem. So I'm concerned that we may be depending on it not changing. I'm now also wondering how this will should interact with the historical inventory on the storage location. Enough that I'm going to throw a WIP onto this until I can check that out.
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.
I think I do need to noodle the historical inventory and distributions a bit more. In most cases, though, it's the created_at date that's going to be matching up to the inventory, not the updated_at. The exception will be any corrections -- which I presume would see the inventory nudged appropriately at the updated_at date.
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.
All of which is to say we likely won't be making any issues worse by setting the updated to now
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.
So this change should still happen then?
@@ -17,7 +17,7 @@ def date_range_picker_select_range(range_name) | |||
described_class.destroy_all | |||
end | |||
|
|||
let!(:very_old) { create(described_class.to_s.underscore.to_sym, date_field.to_sym => Time.zone.local(1919, 7, 31)) } | |||
let!(:very_old) { create(described_class.to_s.underscore.to_sym, date_field.to_sym => Time.zone.local(2000, 7, 31)) } # We are no longer allowing dates before 2000 |
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.
Not sure that comment is necessary? 2000 is still "very old" :)
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.
addressed
I think it's ready for another look, then. |
Distribution.unscoped.where("issued_at < ?","2000-01-01").find_each do |dist| | ||
# Using update_attribute, rather than update! because some of the distributions | ||
# will not validate for other reasons (storage locations missing items) | ||
dist.update_attribute(:issued_at, dist.created_at) |
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.
So this change should still happen then?
@@ -0,0 +1,5 @@ | |||
class UpdateBadDonationIssuedAts < ActiveRecord::Migration[7.0] | |||
Donation.unscoped.where("issued_at < ?","2000-01-01").find_each do |donation| | |||
donation.update_attribute(:issued_at, donation.created_at) |
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.
This is just the same migration twice?
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.
Nope - one's distribution, one's donation. We don't need one for purchases.
["All Time", test_time - 100.years, test_time] | ||
["This Year", test_time.beginning_of_year, test_time.end_of_year] | ||
# We now can't test the lower limit of All Time, because the earliest possible date is 2000-01-01 | ||
# ["All Time", test_time - 100.years, test_time] |
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.
Sorry - shouldn't we still have "All Time" be "since 2000"?
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.
Pretty sure the same thing is going to apply here -- that the tests will try to create things that can't be created in order to check that All Time excludes them.
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.
Yup. confirmed that.
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.
We don't have to check that All Time excludes something - at the very least we can test that it includes something that the other values don't.
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.
I've just been avoiding tinkering with the "do this for all the preset ranges" code, but we could do a single test for all time outside of that, I suppose.
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.
It turned out to be easier to remove testing one end of "All Time" than to add in the 5 or 6 extra tests that would have been needed. This spec could use some attention overall though, imo.
Mea culpa. I failed to actually push the updated migrations. I have now. |
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.
one last suggestion!
@cielf this looks good to me! There are some conflicts but otherwise I think we should be fine. It's still listed as [WIP] - is that good to be removed? |
Hey @cielf - Just letting you know this is in production now. Thanks! |
Resolves #3251
Description
This change will prevent people from entering issued at dates before the year 2000 for purchases, donations, distributions, and anywhere else that uses issued_at
Per the issue, we have several instances where people have entered dates that are before our "All Time" date window.
Still to be done:
NOTE: This (the migration) will require communication to the affected banks.
Type of change
How Has This Been Tested?
automated tests on the model
modified other tests regarding the "All Time" range
outstanding: manual confirmation (blocked)