Table Of Contents
1: Description of the system There are two databases for handling the event: 1) The registration database, with user registration details 2) The payment database, with filed payments 2: Administrating the system The database(s) can be accessed by several users, each with different permissions for accessing/viewing the database. Each user has a username and password and they are given some amount of access. One user may have access to just regs with shirt sales including any of the shirt information, whereas another user may have full access to the database even including editing registrations. 3: The Database Menu The database dump has a menu of choices across the top: Download: csv, tsv Download in spreadsheet format Door totals Checkin and at-door sales table (downloadable) Search: Show rows that match (uses regexp) [clear] Clear the search, show all rows Registration/Payments Switch databases (only if user has access) Full History Users can edit their registration, show each edit as a separate line. [Reg DB only] Furthermore, each of the headings to the data table is a link, clicking on the heading will sort the data according to that column. Not all users will see all menu items, depending on their access. 4: Checkin Page Some database users will be given 'checkin' access, which means instead of seeing the full database table, they'll have simple search (by name, comments and email) and limited information from the database, including the ability to mark a registrant as 'checked in' (i.e.: at the event and received their wristband, shirt, etc..). Shirts can be marked off separately for events that deal with shirts at different times/locations. Checkin also handles wristbands (if desired). This includes a clear note at all times as to which wristbands are currently allowed entry, as well as telling the checkin worker what wristbands to give when they checkin or collect money. The checkin options also include the ability to do at-the-door sales, also handling collecting money and wristbands and tracking sales. 5: The Registration Database Each user will see different details in the registration database according to their permissions. Some users will also see "payStatus" which will attempt to line up payments in the payment database with registrations so we can see who has paid, who owes money, and what payments haven't been linked to a registration yet. We'll also be able to see when the payment was received ("payWhen"). If this is more than a few days after the registration time ("RegTime") then the payWhen field will be highlighted. Some users will also have an "EDIT" column. This allows you to update someone's registration. You will also see all the payment/registration options so you can increase or decrease their price accordingly. You can also toggle whether the registration is ignored by clicking on the "+/-" column to the left of any registration (similar to how this is handled in the payment database). If a registration is turned off, then it shows up crossed off at the end of the database list on the web site, and does not show up on the downloadable files. 6: BUGS: Things That Aren't Perfect Registration is not automatically tied to payments for a number of reasons: 1) Paypal can't do registration for us because their shopping cart isn't complex enough. 2) Some people will pay through paypal directly instead of using the "Click Here To Pay" button (which helps us link things up). If they use a different email address and the don't put their registered email in the comment, we have to manually link these. 3) Some people will register multiple people using the same email address and different names, but other times people will just edit their names on the registration. The reg database has no way of knowing the difference. 4) Payment by check/cash must be manually entered, obviously. 5) Someone will register and get an early price (such as early registration or "first 100 people" prices, etc..) and then pay later. How much later their price is still honored is a case-by-case decision. We usually go through and 'clean' the unpaid regs after sending an email with fair warning to pay. 6) Someone will register and pay but then edit their registration later when a different price is in effect. Which price should be honored? (This is where the "Full History" button helps) 7) If we have a comp/guest registered for an email address and that person tries to register multiple people for that email address then they won't be asked to pay the full amount, because we don't know who to apply the comp to (because of #3 above). This is, however, noted in the payment database, where it will only use the comp/guest for one registration, so they *won't* be able to use this to get in for free. 8) Buying more than one shirt isn't perfect. Fortunately it's an uncommon request and can be handled either manually or by setting up a second registration with an obviously fake name like "extra shirt order" and comping the registration part (though this will artificially increase registration counts). Ideally the user will eventually have a shopping cart that they can add passes and shirts into. Updates might be tricky. 9) The website registration counter still counts regs that have been "ignored" as well as registrations for extra shirts. 10) Other reasons that haven't been considered yet. Because of this, some registrations will need to be handled manually, this can be done from the payments database. In most cases if they edit their reg and they don't choose any different passes then they'll still maintain the same price in their registration, so it's only the odd cases that need fixing. 7: The Payment Database The Payment DB contains two types of payments. Those received by paypal (which are automatically entered if Paypal IPN is set up) as well as manual payments (entered by organizers). 8: Adding Payments (For users with write access to the payment database) At the top of each payment table is a form for adding a new payment. You can use this for handling missed payments, checks, cash, guests, etc.. The fields are: for Must match the email address that the user used to register. amount Either a dollar amount, "guest", "comp
", or "comp reg" payer_email Optional, in case the payment was received through a different email first/last Name of the registrant note Use to explain payment, i.e. "chk 8066 recv 6/3/2009" After a payment has been added, it will show up in the normal list but with the item_name of "MANUAL". If the amount is "guest" then the user will be considered a guest with no money received. If you only want to guest or comp certain amounts, then you can use "comp " (such as "comp 23" to comp 23 dollars). The difference between a comp and an actual amount is that a comp only implies money off a registration, but not actual money received (such as listed in the total at the bottom). Finally, you can "comp reg" which will comp just the cost of the registration (which may vary depending on when the registration is processed), but not, for example, the cost of a shirt. 9: Editing The Payment Database (For users with write access to the payment database) We can add, remove and modify payments in the payment DB. Be warned that after succesfully editing a payment, if you try to reload the page you will submit the edit again (most browsers will warn you by asking if you want to resubmit the form). Generally you should say no - if you want to see the entire DB, then just hit the "[clear]" button next to "Search:" 10: Removing Payments (For users with write access to the payment database) Next to each active payment is a '-' button which will remove the payment. If the payment was manually entered, then (after a confirmation), the payment will be permanently removed from the database. If the payment was a paypal payment, it will be marked inactive. It will be moved to the bottom of the list, will be crossed off, and will not count towards the user's registration. Inactive payments can be re-activated by simply clicking on the '+' sign next to the payment. 11: Editing Paypal Payments (For users with write access to the payment database) The paypal specific information cannot be edited (the intent is that this should match the paypal account exactly), but you can put notes on paypal payments for documentation purposes. Furthermore, you will sometimes receive paypal payments from different email addresses than the user registered with. This is not a problem if the user uses the "Click To Pay" button after registering because the payment will be annotated with the user in the "item_name" field, which will look something like: Reg: email@example.com For paypal payments that don't link up properly, you can set the Note field to include a "Reg: " as above, and the payment will then apply towards that email address.
^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ | ^ |