* Adds LIST_MINUTE_INTERVAL
* Creates a new generic function from list_min15() .. list_min() with one new arguement, the minute interval that 60 should divide by cleanly.
* May clean up the $elapsed_hours, but currently have LIST_MINUTE_INTERVAL set to 1, so we are happy!
* based on the SWEAT_EQUITY_LIMIT with discounts applied,
* based on 1 to 1 (1hr of volunteering === 1hr of free stand time) regardless of the SWEAT_EQUITY_LIMIT
* Allows transactions to provide volunter and/or membership benefits
* Volunteer benefits take precedent for patrons with both types of benefits if a tranaction offers both.
Only increasing max_name_length for the one known affected function. In the
future will need to explore this even further, since there are names a lot
longer than 20 characters.
1). In confs, update works well, delete has an issue with on delete cascade.
2). Saves state properly. Now just need to create a front-end to query for volunteer organizers.
1). Directions are in database_functions.
2). Initial population occurs on first submit.
3). Interests can be changed or deleted
4). It isn't a GUI interface, but it is useful for those without a MySQL understanding.
also ..
1). zip to Zip Code .. some day will need to make international
2) changed Fill-in Form to "Check them out!" for volunteer interest .. subject to real world testing.
Define a url for an email connector that will connect to an email list.
The url can be a server:port, program, etc.
Name (First, Last) email address, and connector password will be sent to the connector.
The purpose of email connectors is to provide autonomy in the choice
of email services and programs. E.g. mailman, googlegroups
See ./examples for an example connector
1). Adds configuration options to turn off waiver & email_list options
2). Puts waiver in Connections/waiver.txt
3). New MySQL waiver column added, receive_newsletter used for email_list.
1). This selector turned of edit when clicked, but because of the way it was construed it was hiding the label. Only became obvious when the validation tests were added.
1). Most collectives require only one shop at a time, but YBDB provides a way to handle 2 concurrent shops in the same location. The current shop will be shown, and users will have to remember the number of the previous shop to enter into the transaction. Note: Remote shops function independently via there IP identification.
Jonathan Rosenbaum