🔬 Implement event ticketing feature

[Tirodem]

(this is a big one that'll need some slicing)

beBOP was approached by some prospect for event ticketing features.

Solutions like Pretix ( https://github.com/pretix/pretix ) or some libraries like UOW Event ( https://github.com/aaazureee/uow-event ) were previously used by those people.

Main features exposed were :
1/ Sale of differents kinds of tickets, with a limited numbers
2/ Paying the ticket
3/ Generation of an unique QR code as ticket for the customer
4/ Possibility for employee to check customer QR code from a phone
5/ Differents ticket management :

• a/ burn after scanning : once the ticket is scanned, it cannot be used anymore (to avoid ticket sharing, but exiting the event is definitive without wristband-like behavior)
• b/ in & out scanning : ticket allows one person go get in and get out as long as code is scanned on entry and on exit

What is done currently (I think) :

1/ Each type of ticket can be a product of "ticket" type, and each ticket product can have a limited stock
Plus, also, we can make ticket product "standalone product" by default to avoid ticket buy spamming, or limit the number of ticket that can be bought on each order.
So, for me, it's OK ✅
⚠️ Note that we have to manage stock for "Ticket" product, as stock management is not OK for every product (so far, only Resource products have it, so Ticket must be a Resource-like product type, or we have to use Resource with a ticket subtype to configure)

2/ If ticket is a product, beBOP can currently allow it's buy purchase with any payment mean beBOP actually provides.
So, also OK for me ✅

3/ For generation a QR code, we need :

• to generate a custom and secure (partially random) key once a ticket product is bought and the order is validated (fully paid)
• to generate a QR code from this key (that, we already do)
  ⚖️ So, partially done for QR code providing, but to avoid connexion issue on customer phone, we need to allow customer to download the QR code as a picture to use it online, or print the QR code as a plain printable ticket.
  🚧 And we also need something for 4th point.

4/ Usually, QR code scanning is made with a phone app.
In order to stay in beBOP, what we can imagine is :

⚠️ I still need to define a proto PDF version of the QR Code + customer info, order ID & co (in case of issue with QR Code reading)

• instead of a plain random key for customer QR code once an event ticket product is bought, the key is used to build an URL, and the QR Code is used to access an URL through a smartphone or a QR code reader from a computer
• the said URL linked to the QR Code should bring to a beBOP to a dedicated employee page, or, like order, a /ticket/{id} page where the customer can check and print his/her ticket, and employee with dedicated access has additional features to burn (definitive entry) / notify entry / notify exit for the ticket / re-enable ticket (for super-admin or special admin role)
  So, here, we need :
  
• the creation of a ticket object (related to order object, with a /order/{id}/ticket/{id} URL, or on a fully new /ticket/{id} URL)
• the possibility to print ticket with its QR code, or download it as a PDF, for the customer
  
  
• the possibility for specific employees to have special options on this ticket, kinda like POS seat with orders
  
• the possibility for super-admin or 2nd lvl admin to reset the ticket in case of technical issue
  Another thing, I think, would be highly appreciable :
• while consulting a ticket product page on admin, you can see
  • how many ticket were sold
  • how much are burnt (definitive entry) / entry scanned
  • how much are still available (no entry) / exit scanned
    
    

Aaaaaaaaaaaaand, finally :

• We can imagine some kind of wallet signing for event ticket but 1/ it's too time-wasting on door-keeping for those who will scan tickets QR Code 2/ feature is not implemented yet 3/ it puts aside non-wallet owner customers
• We can imagine to stock event tickets on blockchain on 2nd layer, but... it is really needed ? For a first step, I don't think.
• Currently, with my design, nothing forbid for the same people to buy X tickets on ore on Y orders (depending of the shop config, but still, by making many orders, we can). If one customer buy X tickets, each ticket will be either anonymous, or related to that one customer, in case of printed PDF. But, after all, we're a bit into privacy, so I'm not against selling tickets without collecting familly tree and DNA of each event spectator.
• We need to be sure that we have a QR code reading solution on smartphone that opens the URL on a "true" browser, and not on a preview / private session browser, because QR code checkers on entry will need to be logged as employee / POS seat / a new special role (Ticket checker) in order to have the validation CTAs. I'm not a big fan of predefined URL with auto-validation (because customer can scan his/her QR code too, so it could lead to dumb situations). It's not yummy in term of open source / creative common, but Google Lens do this, and if any other tool is used, it needs to be checked before. Otherwise, using a QR code reader with a laptop or a tablet can do the job, but it's less easy to do on event entry.

[coyotte508]

We can add the autovalidation for POS users only (and with an additional ?autovalidate parameter so it's not done by accident when a POS user checks an order / ticket)

We should add logging on when a ticket is burned/validated/...

[Tirodem]

@coyotte508 here's a slicing proposition :

1st phase (in order to allow sales on website, so, end of march / beginning of april)

• 🎫 Create "ticket" type product - burn after scanning type #1065
• 🎫 Generate event ticket QR Code for customer buying "Event ticket" product type #1066

2nd phase (tests & validation at beginning of june)

• 🎫 Valide a Event Ticket through QR Code for employee / POS Seat #1067
• 🎫 Display stats on Event ticket admin page #1068

For your anti-mistake error, it's a good idea, but as long as the super-admin can unburn a ticket, if we're short, we can do without it.