Davent - Dance Event Registration Documentation
Table Of Contents
- Description of the system
- Administrating the system
- The Database Menu
- Checkin Page
- The Registration Database
- BUGS: Things That Aren't Perfect
- The Payment Database
- Adding Payments
- Editing The Payment Database
- Removing Payments
- Editing Paypal Payments
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 protected]
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.
Created by make_faq from Marginal Hacks
