photobooth-qr/docs/modele-donnees.md

Modèle de données

Deux tables Supabase (Postgres). Pas de table users côté invité : les invités n'ont pas de compte. L'admin n'a pas de compte non plus en V1 — son accès repose sur un token secret (voir decisions.md).

Table events

Colonne	Type	Description
id	uuid (PK, défaut gen_random_uuid())	Identifiant unique de l'événement
slug	text, unique	Identifiant lisible utilisé dans l'URL publique d'upload (/e/<slug>)
nom	text	Nom de l'événement (ex : "Mariage Julie & Marc")
date_evenement	date	Date de l'événement, sert de référence pour l'expiration
created_at	timestamptz, défaut now()	Date de création de l'événement dans le système
expire_at	timestamptz	Date/heure d'expiration calculée (date_evenement + 7 jours)
statut	text	Statut de l'événement : actif, expire, archive (à affiner)
admin_token	text, unique	Token secret donnant accès à la galerie admin
client_nom	text, nullable	Nom du client (utile en V2/V3 quand le service est vendu)
facture_montant	numeric, nullable	Montant facturé au client (utile en V2/V3)

Table photos

Colonne	Type	Description
id	uuid (PK, défaut gen_random_uuid())	Identifiant unique de la photo
event_id	uuid (FK → events.id, on delete cascade)	Événement associé
url_storage	text	Chemin/URL du fichier dans Supabase Storage
nom_invite	text, nullable	Nom saisi par l'invité (optionnel)
message	text, nullable	Message laissé par l'invité (optionnel)
uploaded_at	timestamptz, défaut now()	Date d'upload

Row Level Security (RLS)

RLS activé sur les deux tables. Règles à valider avec Kévin avant implémentation définitive, principe retenu pour l'instant :

events

• Lecture publique : non autorisée directement (pas de SELECT public sur events). L'accès public à l'upload passe par une vérification côté fonction/API sur le slug et le statut = 'actif', sans exposer toute la ligne (notamment pas admin_token).
• Lecture admin : autorisée si la requête présente l'admin_token correspondant (comparaison côté fonction Postgres/Edge Function plutôt que policy RLS naïve, pour éviter d'exposer le token dans une clause WHERE côté client).
• Écriture : réservée à l'admin/back-office (pas de policy publique d'insertion/update sur events).

photos

• Insertion (upload) anonyme autorisée si et seulement si :
  • l'event_id correspond à un événement dont le statut = 'actif', et
  • la date courante est antérieure à expire_at.
• Lecture réservée à l'admin (accès via admin_token validé), jamais de lecture publique de la liste des photos d'un événement.
• Update / delete : pas d'update par les invités ; delete réservé au job d'expiration automatique (ou à l'admin, à confirmer).

⚠️ Le détail exact des policies RLS (SQL) sera écrit dans supabase/migrations/ au moment de l'implémentation, et validé avec Kévin avant application — cf. règle "décision structurante" dans CLAUDE.md.