-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add occurred at to incidents #292
base: main
Are you sure you want to change the base?
Changes from 3 commits
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 |
---|---|---|
|
@@ -29,9 +29,6 @@ | |
%p | ||
%strong= human_name :incident, :bus | ||
= report.bus | ||
%p | ||
%strong= human_name :incident_report, :occurred_at | ||
= report.occurred_at_readable | ||
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. Would people still expect to see this here? Do we want to still display occurred at for the incident the report is associated with or..? This is a business logic question, I really don't know. |
||
%p | ||
%strong= human_name :incident_report, :passengers_onboard | ||
= report.passengers_onboard | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,5 @@ | ||
{ | ||
"result": { | ||
"covered_percent": 87.86 | ||
"covered_percent": 87.58 | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
class AddOccurredAtToIncidents < ActiveRecord::Migration[5.2] | ||
def change | ||
add_column :incidents, :occurred_at, :datetime | ||
end | ||
end |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
namespace :incidents do | ||
desc 'move occurred_at to incidents' | ||
task move_occurred_at: :environment do | ||
Incident.all.each do |incident| | ||
if incident.driver_incident_report? | ||
occurred_at = incident.driver_incident_report.occurred_at | ||
incident.update(occurred_at: occurred_at) | ||
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. With a task that updates every object in the database like this, there's a (slight) concern for me that for some reason past incidents won't be valid for other reasons. This has happened before. So updating it won't work in that case. Do we want to skip validations here? |
||
end | ||
end | ||
end | ||
end |
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 feel uncomfortable creating an object in the params. If not for any reason other than the question: What if it doesn't work? There's no error handling here, that's done (as is the "Rails Way") in the create action.
There are a couple standard or at least more future-proof ways of handling the problem of "create a driver incident report also if the current user is a driver".
Since
Incident
accepts_nested_attributes_for
IncidentReport
, you could just handle this in the same way the supervisor incident report is, withincident_driver_incident_report_attributes
. See the waysup_report_attrs
is created and used.What you want to end up with is
data
that can be used to create an object, not some data and also an already-created object.