Apply to attend

[shreyas-satish]

This feature will allow event managers curate their audience.

User workflow:

- The prospective attendee fills an application form on the widget.
- The admin reviews the applications, and invites prospects individually by clicking a button.
- An access link is sent to the selected attendees.
- The access link ensures that the widget shows the available tickets for purchase.

Engineering workflow:

- `ItemCollection` will need a `restrict_entry` flag.
- `ItemCollection` will need to be associated with multiple `applications`. Each application has a status, responses to custom fields (decided by the event manager) and an access code.
- When rendering the widget, the item collection is checked if it's restricted.
- If it's restricted, and if a valid access token is supplied, the ticket listing is rendered.
- If no access token is supplied, an application form is displayed.
- This access token is checked for other end points too.

[jace]

Steps 1-3 in user workflow are outside the scope for Boxoffice.

[jace]

Only 1, 3 and 4 are relevant in the engineering workflow. The rest can be removed from the spec.

[shreyas-satish]

Revised spec:

User workflow:

- The prospective attendee fills an application form outside Boxoffice, eg: Google Form.
- The admin reviews the applications outside Boxoffice.
- The admin generates one or multiple access links for an item collection _in_ Boxoffice.
- The admin uses these access links and shares it with the selected list of applicants, _outside_ of Boxoffice.

Engineering workflow:

- `ItemCollection` will need a `restrict_entry` flag.
- Access tokens can be generated like how discount coupons are generated. They are signed codes, which are not stored in the database.
- When rendering the widget, the item collection is checked if it's restricted.
- If it's restricted, and if a valid access token is supplied, the ticket listing is rendered.

[jace]

Restrictions should be per item, not item collection. Some items may be public, some may require a token. Accesss can be zero value discount tokens, so a new model is not necessary. Sometimes an access token will include a discount as well, so it helps to use the regular discount token model.

[shreyas-satish]

Restrictions should be per item, not item collection.

Sure.

Accesss can be zero value discount tokens, so a new model is not necessary.

I wasn't planning to add a new model. Simply to generate and verify tokens at runtime. There's a database constraint that ensures the percentage is greater than 0. Should this be changed?

[jace]

I wasn't planning to add a new model. Simply to generate and verify tokens at runtime. There's a database constraint that ensures the percentage is greater than 0. Should this be changed?

Yes, let this be an app constraint that prevents 0% discounts if the item is not restricted.

[shreyas-satish]

There's a problem with using 0% discount coupons. The discounting logic does not apply a zero value discount coupon to a line item, since there's no discount to be accounted for.

I'd prefer to not change the discounting logic at this moment, and instead, I propose we introduce a simple AccessCoupon model, that shares a many-to-one relationship with Item. This also helps segregate the discounting and access control logic.

Kiran, your thoughts?