# Pierre

## Team

### Roles

- Matteo Regge: referente + dev
- Paolo Marzolo: tech review
- Mattia Guazzaloca: tech lead
- Ossama ...: dev
- Valentina ...: dev

## Requirements
Pierre is an app that connects club owners/managers to end-users. It is designed to avoid the current middle-man, the PR.
Users can:
- view the catalogue of SERATE (entity name)
- for each SERATA, view TICKETS available for sale
- buy TICKETS
- every DISCO has address (and contact?) information associated with it
- view the TICKETS they have bought, and present PROOF OF SALE to entrance staff

### Possible Enhancements

- get notified when favourite place (so favourite places) has a new SERATA
- get directions/uber/sharenow to club
- get back together with other people feature @_@

Manager can:
- scan PROOF OF SALE to admit users
- add TICKETS for a SERATA (login)
- reserve table for x many people for their own SERATA (login required)
- for each SERATA, a manager can see the reserved tables and the ones left
- can see the list of pending requests for certain tables
- configure the SERATA (login required), meaning setting up the page of the SERATA the users see, info such as prices,music genre, food, guests....

## num estimates
conservative final version:
- ~20 DISCOS -> ~80 SERATE/week -> ~40 managers
- ~250 TICKETS available per SERATA -> 20'000 TICKETS/week
- ~250k USERS

minimum viable product:
- 1 DISCO -> ~3 SERATE/week -> ~2 managers
- 20 TICKETS available per SERATA -> 60 TICKETS/week
- users... we'll see what we can get.

## Data model

### TICKETS
Tickets are especially complex, as many variations are in commerce today. Let's start by rounding them up:

- Single entrance ticket: simplest ticket; gets a person (with a specific name?) into the club, once. Multiple versions of a single entrance ticket can be created, with different names, description and price.
- Table ticket: allows for a list of guests to be specified. Price is paid by a single USER.
- Multiple entrance ticket: not considered.
- Drinks/performances/food included: not considered.

so
TICKET:

id; // unique
id.SERATA; // associated SERATA
type; //single or table
title; // shows up in app
description; // shows up in app
id.CUSTOMER; // holder
id.proof of sale;

CUSTOMER:

id;
anagraphical info;
contact info;
preferences;
[purchase history]; //(?) tickets?

SERATA:

id;
date;
description;
people coming;
[ids.TICKET];

MANAGER:
...

## Code Management

Approach: multi-repo under a single org

### Mobile
Mobile app

### Web
Management webapp

### Server

## Tech Stack