Theater and Event Ticketing
I originally posted this over on Ryan's Blog, but figured I should repost it over here for a wider audience and posterity.
There are three theater scenarios that I can think of:
1. Theaters that are 100% general admission
2. Theaters that sell tickets by section, and are general admission within each section
3. Theaters that sell individual seats.
Scenario 1 and 2 seem like they may be easier to implement, as described in the comment above, you could set stock for the product variants (tickets by section).
Scenario 3 seems like the trickiest, and most specialized. Each theater would need to have a set of product variants, there could be literally thousands of variants (one for each seat), and when ordering, a customer would likely want to sort by section or price and then buy contiguous tickets.
I wonder if the Theater Ticket use case requires its own contributed module for managing seating arrangements and presenting a purchase interface that caters to the task, allowing a user to select by section, or by price and then pick contiguous tickets, perhaps even limiting results to only those where there are n# of contiguous tickets (where n# is the the number of tickets the customer has indicated they wish to buy).
The larger issue though is that the ubercart product infrastructure should be able to support this specialized use case.
Comments
Another event use case - Tables
I just wanted to mention another use case for event ticketing. Tables.
1 - Tables often have different levels, similar to sections for seating
2 - Tables also allow admission for more than one person. You buy a table and get tickets for 8-10 people. One of the primary tricks is getting the names(and hopefully email) of all the guests beyond the purchaser so we can have them on the guest-list, and maybe contact them is any last minute changes.
Tables! Good catch. I think
Tables! Good catch. I think that tables fall into a broader category of one person buying "tickets" for multiple people, which splits into two branches:
1. situations where you don't care about the other attendees
2. situations where you DO care about the other attendees: this includes the table scenario, as well as "will call" scenarios where tickets should be left under individual names, or other guest list scenarios.
...or training classes, or
...or training classes, or even just a company buying for their employees with a single transaction. Training could be where a trainer organises a class and the client is a company who sends three people on the course. Likewise, if you're running a business membership style site and one person purchases premium subscriptions for 5 people at the sametime. Don't get me started! How about any way in which you can represent a company and it's employees as customers - who gets billed, who can look at orders, can you queue orders for a client admin to authorise and purchase etc etc. Oh abstraction layers please.
I use ubercart for boat race registration
For classes or competitions, many operators need certificates to be uploaded and/or waivers to be "signed". This dovetails, I imagine, with folks who want to upload graphics with their order.
As noted by 4drian, covering the case where people buy entries for another person or people is important too. I do that for a first person with attributes and textfields.