There's so much information to keep track of when handling volunteer logistics, including information specific to admins and some that should be shared with volunteers. For example, admins may want to let their coworkers know if a recipient has reached out about the quality of food on a specific shift, requested a volunteer not be on a shift, or sharing todos. Admins also want volunteers to know to:
- leave food for afternoon shifts
- drop off food at specific times
- compost or not compost certain items
- add Rapid Response teams for each shift for volunteers or GPC to contact.
Currently, Rootable has admin/public notes for locations, but not for specific shifts. We actually used to have this information in the robot (our previous tool) and migrated it to rootable, but was neither shown nor editable.
Now, each shift occurrence now has editable public notes.
The shift occurrence form is weird in the way it accepts data. It passes two hashes to the Updater, one of which contains shift event params. This is opposed to the rails convention of having a single params hash that a form renders. Instead, the form is a mishmash of form fields, hidden fields modified in the controller, and a react form.
To get everything working, this just puts another field on the page under the shift_events scope for public_notes. It's passed along to Updater to become eventable_attributes; attributes directly on the "eventable" object which is the ShiftEvent.
A more difficult technical challenge was ensuring users are still assigned to a shift after updating the shift with notes.
Assigning users into the future is tricky, because we merge them with the existing users. I chose to set shift event attributes to save public notes. However, user_ids were also in that attribute hash.
What could happen was:
- merge users into future events
- assign attributes to future events
- this assigns things like public_notes, but...
- it also destroys merged users and just keeps new ones
The solution I came up with is to strip user_ids from the attributes hash after we're done assigning it to the events.
We also decided that having both site notes and shift notes was confusing when they're both called Public Notes or Instructions. We opted to name them: Shift Notes (one for the whole shift) and Site Notes (one for each task).
There's so much information to keep track of when handling volunteer logistics, including information specific to admins and some that should be shared with volunteers. For example, admins may want to let their coworkers know if a recipient has reached out about the quality of food on a specific shift, requested a volunteer not be on a shift, or sharing todos. Admins also want volunteers to know to:
* leave food for afternoon shifts
* drop off food at specific times
* compost or not compost certain items
* add Rapid Response teams for each shift for volunteers or GPC to contact.
Currently, Rootable has admin/public notes for locations, but not for specific shifts. We actually used to have this information in the robot (our previous tool) and migrated it to rootable, but was neither shown nor editable.
Now, each shift occurrence now has editable public notes.
The shift occurrence form is weird in the way it accepts data. It passes two hashes to the Updater, one of which contains shift event params. This is opposed to the rails convention of having a single params hash that a form renders. Instead, the form is a mishmash of form fields, hidden fields modified in the controller, and a react form.
To get everything working, this just puts another field on the page under the `shift_events` scope for `public_notes`. It's passed along to `Updater` to become `eventable_attributes`; attributes directly on the "eventable" object which is the `ShiftEvent`.
A more difficult technical challenge was ensuring users are still assigned to a shift after updating the shift with notes.
Assigning users into the future is tricky, because we merge them with the existing users. I chose to set shift event attributes to save public notes. However, user_ids were also in that attribute hash.
What could happen was:
* merge users into future events
* assign attributes to future events
* this assigns things like public_notes, but...
* it also destroys merged users and just keeps new ones
The solution I came up with is to strip `user_ids` from the attributes hash after we're done assigning it to the events.
We also decided that having both site notes and shift notes was confusing when they're both called Public Notes or Instructions. We opted to name them: Shift Notes (one for the whole shift) and Site Notes (one for each task).