HackGT EventBriter Design Docs

attendee_order.md

Attendee Create Order

1. Attendee navigates to event page
2. TODO System checks for and removed expired ticket reservations
3. System shows event view with available tickets
4. Attendee selects ticket(s) from page
5. System warns/prevents selecting unavailable tickets
6. Attendee starts checkout process
7. TODO System marks selected tickets as reserved
8. System shows ticket information screen (collect attendee info)

• If authenticated, available attendee information is prepopulated
• TODO If not authenticated, login and register options are available
• Selecting login or register options brings the attendee through the respective workflows and then returns back to this step after completion

9. Attendee provides required information
10. System saves ticket information temporarily

• If order is abandoned, system purges ticket information and TODO (maybe) clears ticket reservation

11. System shows order information screen (collect payment info) from payment provider

• If authenticated with saved payment, information is prepopulated

12. Attendee provides payment information to payment provider
13. System receives success message with tokent from payment provider
14. System stores order record (with payment token) and ticket record

• If authenticated, system stores order id in attendee account

14. System shows receipt/success screen

• TODO System may send confirmation email with OTP to edit order

Attendee Edit Order

If authenticated, the attendee can view their orders and request refunds, edit information etc.

TODO Unauthenticated users must use OTP in email receipt to view/edit order.

schemas.md

Planned Schemas (as of 3/9/2016)

This is by ALL means a working document. There are big, unsolved design issues with event ownership, event-ticket-order relationship, and user-info properties and their connection with our third party identity provider Auth0. Also because the ordering/ticketing system has not been implemented, there are untold number of issues concerning their design.

NOTE: <..._id> types refer to Mongo Object ids.

Event

This mongo object represents individual events (pretty self explanatory).

{
    _id: <event_id>,
    name: <String>,
    location: <String>, // should be verified/parsed
    start: <Date>,
    end: <Date>,
    created: <Date>,
    tickets: [
        {
            id: <string>, // must be unique and non-null
            label: <string>, // must be non-null
            remaining: <int>, // calculated by client (never actually stored)
            total: <int>,
            max_per_person: <int>, // -1 if infinite, 0 if not available
            sold: {
                <ticket_id>: <ticket object>
            }, // list of all tickets sold of this type
            price: <float>,
        },
        ...
    ],
    orders: [<order_id>, ... ],
    owner: <user_id> // keeping this here so events can display their owner
}

The topic of event ownership warrants more discussion (especially as user permissions get more complex with different roles - owner, organizer, staff(?)). For now I think we can keep just an owner field in event and a list of events in user to a two way relationship.

Ticket

NOTE: tickets are not their own collection, this is a schema to be stored inside the Event object

{
    _id: <ticket_id>,
    type: <String>, // must correspond with <id> in Event.tickets
    event: <event_id>,
    order: <order_id>,
    attendee_info: {
        // arbitrary info collected from the purchaser
        // should be pre-populated when possible from user account
        // ex) name, phone, email
        // this is intentionally a copy (not a reference) of attendee info
        // possible to automatically update when user account info changes
    }
}

Order

{
    _id: <order_id>,
    payment: { // this is wishful thinking to try to keep the codebase decoupled
        provider: <"stripe" or "braintree" etc>,
        token: <payment provider token>
    },
    user_id: <user_id>,
    event_id: <event_id>,
    tickets: [
        {
            ticket_id: <ticket_id>,
            amount_paid: <float>
        }, ...
    ]
}

User

NOTE: this is/will be implemented with/on top of the Meteor accounts system which we have integrated with Auth0. Special consideration should be taken to keep Auth0 and our own Meteor accounts linked/in-sync/in agreement as well as keep application specific logic (ex. event ownership) separate from Auth0.

{
    _id: <user_id>,
    events: [<event_id>, ...], // events this user organizes
    orders: [<order_id>, ...], // orders that belong to this user
    services: {
        auth0: {
            ...
        }
    }
}

usecases.md

Before Event

Organizer

• creating new event
• editing event
• viewing attendee information
• contacting attendees
• issuing/approving refund

Attendee

• creating order (purchasing tickets for a single event)
• view their existing orders
• edit order (request refund)

Day-of Event

Staff (Organizer + Volunteers, incl. Bus Captains etc)

• check-in ticketed attendee
• contact (email/text/call) (all) attendee
• sell/issue walk-in tickets

Attendee

• text to check-in
• find staff contact information

After Event

Organizer

• charge non-refunded orders (#cashout)
• contact attendees