Revisit products and price tiers

[marksteward]

The product/price tier thing is still fiddly.

One aim was to make it easier to carve out allocations, but we need to duplicate all the products that are affected within an allocation (e.g. to limit admissions, we need to clone full, full-s and full-sg, and then keep their prices in sync).

We have to have full, full-s and full-sg as separate products despite price being the only difference, because we also need to identify the active tier within a product, and retain previous ones because that's what purchases are tied to. This makes it hard to identify when a tier was on sale, because we don't version price_tier, which is annoying for reporting.

The only admission tickets that are for adults but are a different product are the vendor ones (which don't typically include a badge). We want to be able to rebuild products and tiers as fixtures, but this means duplication in those files.

Also, tokens are currently for ProductViews, which are tied to products. It might be easier to tie them to PriceTiers, which can be underneath the normal products.

[marksteward]

Prices being immutable is also a bit annoying. It might be better to have the current price and version it. We shouldn't need historic prices when rebuilding from a fixture.

[russss]

I think there are two issues here, and they are relatively small adjustment to the existing design rather than any significant problems. I think these two need to be separate issues really:

Supporter pricing is still not ideal

Supporter tickets should really be separate PriceTiers for the same Product. I think this was kind of the intention in the previous refactor but we didn't quite make it work in time. We should be able to have multiple active PriceTiers for the same product, with the user able to choose between them. I think this is mostly some tweaks to the ProductView logic.

This is a change for 2020 I think. Don't want to be reshuffling the live data for this.

Individual tokens

This wasn't part of the spec for the refactor. We clearly want to be able to generate individual tokens for people which will entitle them to buy a certain number of tickets, like pretix does.

• We need to be able to have tickets on sale without them appearing on the main tickets page (I'm not sure how we do this at the moment)
• We need some model (TokenSet?) for a set of tokens which has some properties.
• This TokenSet could still control access to a ProductView, but we would need some way of to model the maximum number of tickets a user can buy.
• The only reason I can think of why a token would need to dictate price paid would be for stuff like speaker tickets. I think these should still be separate Products, as they are separate top-line items in the budget.
• Hence, speaker tickets could be handled as a different ProductView which only speakers with an accepted talk get access to - no tokens needed.

---

A few other miscellaneous reckons:

I think the allocation logic is still a sound approach to keeping track of the total number of tickets sold. Any token stuff should be orthogonal to that.

The admin interface needs work, really. The easiest way to set stuff up should be through the admin interface (with some way of exporting/importing the price structure as a fixture). Our tests and dev should be using an entirely fake fixture with less of the complications of the live one.

I'm still of the opinion that having these short internal ticket names is annoying and we should try and get rid of them, somehow.

About the Prices-being-immutable - we still need to be able to trace orders back to the price paid, and I'd rather not obfuscate that too much (especially with versioning...). I think immutable Prices are a good solution but the code could be improved to make it less fiddly.

[marksteward]

Didn't intend for this to sound like another massive refactor, just somewhere to dump the problems encountered so we don't forget.

I'm still of the opinion that having these short internal ticket names is annoying and we should try and get rid of them, somehow.

This is currently held back by:

• having to duplicate products - I need to be able to check that tiers match across the products, and without this I'd need to check the actual price and creation time of tickets to confirm I've got the right tier. If we can stop duplicating products, this disappears.
• not having import/export. We'd need to import the production sales structure by id instead, and have a way of testing that in dev/test.
• the purchase tests are built around being able to pull out particular products and work with them. If we use fixtures, it'll be easier to pull them out in order, and know which ones they are. I don't want to do this by id.

Hence, speaker tickets could be handled as a different ProductView which only speakers with an accepted talk get access to - no tokens needed.

Also, now I've pulled out basket functionality, we can add a table for it (we already touch the DB to reserve purchases so this doesn't add much). This would let us allocate a set of tickets for individuals without requiring an account, and recharge failed payments without having to cancel and reserve again. This was another thing we worked around with tokens last time.

Supporter tickets should really be separate PriceTiers for the same Product.

I'd really like to do this, because people can then upgrade the price tier after successfully reserving (you shouldn't be able to upgrade between products). However, we need to be able to say:

• which tiers within the product are currently available
• what order to show them in, for the basket and the invoice
• how many of each tier can be bought if they're limited
• how the lines are different if the user has reserved tickets from a previous release (or by us reserving them manually)
• how they're different if the user is using a token and therefore seeing additional ticket tiers (or types?)

We've never set a capacity_max on a price_tier. If we did, we'd probably want to show the next-to-be-available tier as well if only a couple of tickets were left. But then we risk confusing users by making them make a choice they're not prepared for. I'm tempted to remove CapacityMixin from PriceTier, but then do we need a way to carve up allocations in price tiers for particular groups (e.g. volunteers/orga)?

We currently set the order by ProductView.order, then by either price or id. We should use price everywhere.

I'd also like to pin down what the sales state really means, and whether the (currently complex) implementation is correct. Unavailable means the front ticket page is read-only, but people with reserved tickets in the main ProductView can still complete their purchase, and the other views are never unavailable. If completing a purchase means adding other tickets from the main view we currently allow that, assuming there's capacity. We also allow people with tokens to bypass the unavailable state, and admins (although that can now be removed).

[russss]

We've never set a capacity_max on a price_tier. Is there likely to be a situation where we would?

Superficially, it makes a lot of sense to do this, in order to limit the number of tickets we sell at each tier. I think this was part of my original plan.

However, we've got the additional problem here that we don't want to keep selling supporter tickets if the basic tier has sold out. So you've got this kind of distinction of a "primary" price tier which also controls the availability of other price tiers. That's where it gets fiddly, and it's certainly tempting to avoid that by changing the capacity on the product instead.

Being able to fetch the remaining capacity is surely useful to have, though. The CapacityMixin handles that for you automatically, so I'm not sure there's a compelling reason to remove it if it's causing no harm.

I'd also like to pin down what the sales state really means

I think this is deserving of a new issue in itself and I'm still not sure if I have any idea what it means either. It's certainly something we still need.

[marksteward]

See also #1214

[marksteward]

This (particularly subtypes of products) would be good to revisit after July 2026.