eads
commented
13 years ago I've started working on this and there's an interesting problem that was discussed and then forgotten by me. Our current way of storing volunteer hours is as a date range in a "volunteer session" node. But our spreadsheet only includes day and duration. We'll need to tweak our volunteer session data structure to account for this situation.
One option would be to simply fake the hours by creating fake data range that start at 11am. No modification of the data structure is necessary, but this is not a satisfactory solution.
Another option would be to add an additional field to volunteer session with a duration computed from the duration or simply filled in. There's a huge computational / analytical benefit to this approach: By 'caching' the duration with can do simple, cheap summations and sorts, rather than having to calculate a difference of dates at query time to determine duration. However, there's also curveball here: we'll need a special boolean flag (another field) on each volunteer session which indicates that the duration is overridden and should not be computed from the to / from dates when saving a volunteer session.
jimglover
We need a script of some variety to suck in data from the current volunteer hour spreadsheet. The script will need to create new users for each volunteer in the database, create new event nodes if they don't exist, then create volunteer sessions for each cell in the spreadsheet. I've proposed that all users have their real names converted to usernames of the form
firstname_lastnamefor now.There's also a rather scary logistical question hanging around here: What to do to give volunteers access to the site if they have an account created? There could be some annoying gruntwork for administrators here. For now, we can avoid that by simply not giving volunteers access.
This is the key blocker for the alpha-1 release -- we really can't proceed using two systems for very long, and we desperately need to get the spreadsheet deprecated.