Process of registration:

The "Commerce" family of modules are used to process payments.

"Webform" is used for volunteer form and registrations.

"Commerce Webform" ties registration form submissions to Commerce lie items.

1.  The user fills out a "Webform" form with registration information and "add to cart"/submits the form.

2.  "Commerce Webform" adds a line item to the shopping cart related to the submission ID of the form.  The product for the line item is the member type chosen from the dropdown on the form.  The Webform submission's Product field shows as "unpaid" at this point.

3.  The user checks out and pays through PayPal. When PayPal returns the "paid" status, a number of things happen at once:

  An email is sent to the user confirming their purchase, including their form submission information.  That information includes the paid status of the form.

  The submitted webform(s) that are related to the line item(s) in that shopping cart get their status updated to "Paid".

 --THE ORDER IS OFTEN WRONG - THE EMAIL IS SENT BEFORE THE WEBFORM SUBMISSION UPDATES TO SHOW PAID-- This results in the user getting a confirmation email that says "unpaid", however, if they have the confirmation email then THEY HAVE PAID.  By the time anybody is aware of the incorrect email, all internal systems have been updated to show the submission has been paid.  TODO:  FIX THIS

Process of retrieving registration information:

Only users with a login that has permission to view registration data.  Currently that is covered by the site admin role, and the registration role.

The most assuredly accurate way of accessing the submissions feels janky, because this is two completely separate modules (Commerce and Webform) being kludged together with a third module, Commerce Webform.  All webform submissions are recorded - whether or not they are paid.  Orders won't show "unpaid" registrations, or any of the form submission information, and webforms don't care about orders in any way.  Full instructions for the janky but accurate way of extracting information is found in the file  Registration instructions.pdf .  Another category, 'staff', has been added since this document was written.

An easier method to extract registration has been cobbled together using the "Feeds" module.  Feeds runs a SQL query to extract all the scattered information and join it together.  It then creates new "Member" type nodes from those that have paid.  This query is run every 30 minutes, so it may lag a bit behind "live" data.  "Views" is used to create a basic member search of these nodes for public consumption (filtering out anybody who indicated they wanted to be kept private).  Another view is used for the admin side, with a lot more search options and the ability to export search results to a csv file.  You can export the entire (paid) registration database at once.  That can be found at http://38.orycon.org/admin/member-list

If there is ever a discrepancy between the two methods of extracting registration information, the first, janky method outlined Registration Instructions document is the authoritative source.