B2Bitcoin / beBOP

Marvelous p2p bitcoin-based online sales platform
https://be-bop.io
GNU Affero General Public License v3.0
16 stars 3 forks source link

šŸ”¬ Implement event ticketing feature #939

Open Tirodem opened 9 months ago

Tirodem commented 9 months ago

(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 :

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) image image image image image image image

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 :

4/ Usually, QR code scanning is made with a phone app. In order to stay in beBOP, what we can imagine is : image āš ļø 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)

Aaaaaaaaaaaaand, finally : image

coyotte508 commented 8 months ago

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 commented 8 months ago

@coyotte508 here's a slicing proposition :

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

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

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.