Split Item into Ticket and Asset

[jace]

This ticket extends #75, which should now be considered a dupe of this.

The Item model describes a "ticket", which provides access to one or more events or merchandise items. These underlying concepts can be described as "assets" (seats or t-shirts) that have a limited quantity available for sale. For events, an "asset" is the smallest indivisibe event that can be sold. For example, in a two day event, the first and second days are distinct assets, and a full conference ticket can be sold combining both assets.

By moving price and marketing management into the distinct concept of a "ticket", and inventory management into "asset", we achieve two things:

1. Inventory management, including planning for headcount per day or setting seat limits, becomes simpler as inventory is accounted for separately from tickets.
2. A partial cancellation can be performed on the basis of the underlying assets, and other tickets that offer the desired combination of assets.
3. The opposite of cancellations: a upsell can also be performed by replacing one ticket with another ticket, both prior to checkout (as a recommendation) and post-purchase in later communications.

Caveat: Asset management can be tricky for t-shirts. We currently sell a "t-shirt" ticket and let the participant choose size and design at the venue. With distinct assets, each design and size combination is a separate asset (as it should be). However, these choices are not made at the time the sale happens (if, say, sales are opened many months before the number of design options are finalised). We need an "abstract asset" or "asset category" concept, with actual assets defined later to match the sales of the abstraction/category.

[jace]

Let's use the term "abstract asset" or "abstraction" to avoid confusion with the term "category" which is currently used for display categorisation.

Abstractions present both an opportunity and an interesting problem.

Case 1: T-shirt abstraction. This allows the buyer to buy a "t-shirt" without providing any specifics, which can now be selected at the time the ticket is assigned. The assignee can choose any asset that matches the abstraction. The asset to abstraction mapping may be many-to-one (all specific sizes and designs of t-shirts map to a single abstraction named "T-shirt") or many-to-many (an "M-size t-shirt" with unspecified design is available as a distinct subset of the "All t-shirts" abstraction).

Case 2: Event abstraction. A "conference day" abstraction allows selling a season pass that includes 10 days worth of events that may be populated with any specific events on a per-day basis. For example, a user may choose to populate with one day of JSFoo and two days of Fifth Elephant. To make this work, we need a mapping where 1 unit of a "season pass" ticket (as sold to a customer) includes 10 units of "conference day" abstraction, which can then be populated with any ten conference day assets. A customer should not be able to acquire more than one unit of the same asset. It makes no sense for someone to attend day 1 of JSFoo twice. However, this stands in contrast with t-shirts where it's okay for one customer to acquire two units of the exact same asset. This means assets need a flag or counter to indicate exactly how many units can be simultaneously consumed by the same assignee.

We are assuming here that one ticket has one assignee. If there are multiple assignees, they need separate tickets.

This brings up an edge case with season tickets: what if the buyer wants to transfer the unused portion to someone else, or change some details (if say, the buyer is an individual who has changed jobs and wants to change the company name on the ticket)? Past details should be immutable, but attendees shouldn't need to enter details separately for every single day of every event they attend.

Solution: attendee details are entered once per ticket, but a copy is stored in a separate TicketAssetDetail model, and is immutable once it's marked as archived. This model forms the basis for Peopleflow's check-in management.

Case 3: Event brand abstraction. The abstraction model breaks down when the season pass is sold for, say, "any 5 events", where the event may be single or double day. As there is no asset for "two days" of an event, as that breaks inventory models (number of seats left to sell per day or cancellation of second day after consuming the first day), we need to define a "group asset", where the group fulfills the abstraction rather than the individual assets. A "group asset" is almost exactly the same thing as a "ticket", so we might as well use a ticket. This gets us an interesting recursive setup:

1. A "season pass" ticket buys you 5 units of a "conference" abstraction.
2. One unit of "conference" abstraction can be fulfilled by any specific conference's ticket.
3. The specific conference ticket in turn gets you one/two/three units of event day assets.
4. Attendee details are only collected once for the "season pass".
5. When a specific asset is added to the ticket, these details are copied over into a separate model.
6. Once the asset is marked as "frozen" (midnight of event day, or whenever badges are printed) or "archived" (midnight of post-event day), these copied details become immutable.
7. Attendee details can be edited at any time, but frozen/archived copies are not touched. Live copies are updated.

[jace]

Item needs to be renamed to Ticket and ItemCollection to TicketCollection (or preferably another term that's an independent noun).

Tickets always have the collection as a parent, which in turn has organisation/profile as parent. However, Asset and Abstraction are directly owned by the organisation.

It should not be possible for tickets to refer to assets owned by another organisation, as settlements across billing entities are not a supported feature in Boxoffice at the moment, especially since prices are defined on the ticket and not the asset.

[jace]

We still need a way to link asset variations. For example, a Fifthel 2017 t-shirt in S/M/L sizes shouldn't be shown as three entirely different assets in UI. It should be shown as one asset with three variations. There may be more than one facet for variations (size, colour, male/female cut, etc) and multiple values for each facet, making for a 2D matrix of choices with separate inventory counts for each.

Asset variations have been explored in the Dukaan project, and since that project has very little to add to Boxoffice, it may deprecated with the good ideas migrated here. Variations should be a separate ticket here.