Merging Boxoffice models

[jace]

trafficstars

The Boxoffice repository and app is pending merger into this Funnel repository and app. These apps have overlapping models that need to be consolidated into a simpler product spec. This issue discusses the ones needing merger.

• [ ] boxoffice.User → funnel.Account[User]
• [ ] boxoffice.Organization → funnel.Account[Organization]
• [ ] boxoffice.DiscountPolicy → funnel.DiscountPolicy
• [ ] boxoffice.DiscountCoupon → funnel.DiscountCoupon
• [ ] boxoffice.Menu → ? (funnel.Menu or funnel.Project)
• [ ] boxoffice.Category → ?
• [ ] boxoffice.Ticket → funnel.Ticket
• [ ] boxoffice.Price → funnel.Price
• [ ] boxoffice.Order → funnel.Order
• [ ] boxoffice.OrderSession → ? (funnel.LoginSession or other)
• [ ] boxoffice.LineItem → funnel.OrderLineItem
• [ ] boxoffice.OnlinePayment → funnel.OnlinePayment
• [ ] boxoffice.PaymentTransaction → funnel.PaymentTransaction
• [ ] boxoffice.Assignee → funnel.TicketParticipant -> funnel.ProjectMembership
• [ ] boxoffice.Invoice → funnel.OrderInvoice
• [ ] funnel.TicketEvent → funnel.Project (this is a major data migration)
• [ ] funnel.TicketType → ?
• [ ] funnel.TicketEventParticipant → ?
• [ ] funnel.TicketClient → None
• [ ] funnel.SyncTicket → None

[jace]

A Menu in Boxoffice is almost always associated with a Project in Funnel, so the merger should arguably merge Menu into Project instead of keeping it as a separate model. However, there may be a case for two projects sharing the same menu:

In Funnel, projects have a notional 1:1 relationship with events, but this has often been violated:

1. [ ] We have instances of the same project being reused for multiple events, particularly for recurring events adding into a common archive. It may be prudent to redefine this so that the account hosts the archive and projects represent a single event.

2. [ ] The pre-pandemic annual events used a single project to represent an umbrella of events, with co-located workshops and separate tickets for day 1 and day 2. We have evolved two separate mechanisms to deal with this:

   • A project may be marked as a sub-project of another. It is then functionally independent, but is listed alongside the main project. This feature has long fallen into disuse.
   • The TicketEvent model represents a distinct event within the project for the purpose of ticketing alone. It is invisible to the user, and potentially a source of confusion on what the user has access to.

The proposal: merge TicketEvent into Project, creating new sub-projects as necessary. Let a project represent one distinct event with distinct participation. However, this bit is still unclear and needs a single choice:

1. [ ] Merge Menu into Project. A sub-project's menu is then listed as a Category under the main project's menu, thereby also deprecating the Category model. Or,
2. [ ] Keep Menu and Project separate. Multiple projects can refer to the same menu. The "parent project" option in a Project's settings may be removed as that becomes redundant classification (i.e., no more sub-projects).

Also unclear: a Ticket in Boxoffice is mapped to multiple events in Funnel, currently via TicketType, TicketEvent, TicketParticipant and TicketEventParticipant. The latter two models are to be merged into ProjectMembership, while TicketEvent is to be merged into Project. This leaves us with yet another linkage to resolve:

1. [ ] Assuming Menu is merged into Project, a Ticket is then parented by Project, and implicitly creates a participant in that project (via ProjectMembership). However, it cannot create a participant in a secondary project (such as a both days ticket). A secondary join model (replacing TicketType) is not viable in this case as it creates two mechanisms for association with a project. The solution may be a hierarchy like this, with the caveat that it allows sub-projects to inherit participants from the main project, but not the other way:

   • Main project
     • Ticket: all access
     • Day 1 sub-project
       • Ticket: day 1 only
     • Day 2 sub-project
       • Ticket: day 2 only
     • Workshop sub-project
       • Ticket: workshop only

2. [ ] Assuming Menu remains independent from Project, the current TicketType model can be replaced with a secondary join model between Ticket and Project. It will be possible for a project to list a menu that has tickets that do not grant participation in the project (these can be filtered out in the UI).

[jace]

If there is a Project <-> Ticket join model, it is unclear what value Menu continues to offer. The join model could be ordered to create a project-specific custom menu, and the same ticket can appear in multiple projects. Tickets (via the Menu) are currently hosted by a billing organization, which is different from the community hosting the project, so the same ticket can even appear in projects hosted by different communities.