From 5cd8ada8282c8ad502a5bea51b4d71821a6e8876 Mon Sep 17 00:00:00 2001 From: Xor290 Date: Mon, 6 Jul 2026 21:22:30 +0200 Subject: [PATCH] chore: build --- .claude/skills/comprehension-metier/SKILL.md | 158 ++++++++++ .claude/skills/plan-fonctionnalite/SKILL.md | 64 ++++ .claude/skills/securite-projet/SKILL.md | 46 +++ .claude/skills/test-logique-metier/SKILL.md | 145 +++++++++ backend/gestion/db/db_cancel_command.go | 40 +++ backend/gestion/db/db_commands.go | 313 ++++++++++--------- backend/gestion/db/db_stat.go | 21 +- backend/gestion/handlers/crypto_payment.go | 5 +- backend/gestion/handlers/deleviry.go | 44 ++- backend/gestion/handlers/panier.go | 5 +- 10 files changed, 664 insertions(+), 177 deletions(-) create mode 100644 .claude/skills/comprehension-metier/SKILL.md create mode 100644 .claude/skills/plan-fonctionnalite/SKILL.md create mode 100644 .claude/skills/securite-projet/SKILL.md create mode 100644 .claude/skills/test-logique-metier/SKILL.md diff --git a/.claude/skills/comprehension-metier/SKILL.md b/.claude/skills/comprehension-metier/SKILL.md new file mode 100644 index 00000000..d8655beb --- /dev/null +++ b/.claude/skills/comprehension-metier/SKILL.md @@ -0,0 +1,158 @@ +--- +name: comprehension-metier +description: Charge le modèle métier complet de la plateforme de gestion de commandes/livraison (rôles, cycle de vie des commandes, stock, catalogue, points/récompenses, parrainage, pénalités, paiements, GPS/assignation, alertes, paramètres configurables). À invoquer avant toute analyse, debug ou modification qui touche à la logique métier — pas seulement au code — pour raisonner avec les vraies règles du business plutôt qu'avec des hypothèses. +--- + +# Compréhension métier — Plateforme de gestion de commandes/livraison + +Référence condensée mais complète du domaine, construite à partir du `README.md`, des modèles Go (`models/`) et du code des handlers/DB. Objectif : éviter de raisonner uniquement "à partir du code" sans connaître les règles métier réelles, ce qui est la source la plus fréquente de bugs silencieux dans ce projet (stock, remboursements, idempotence, paramètres codés en dur au lieu de suivre `AppSettings`). + +## Contexte général + +Plateforme de commande + livraison ("Milieu-Nantais", contact Telegram `MLN44LA`) avec catalogue produit par catégories (ex. pools de points nommés "Cannabis", "Accessoires" dans les settings par défaut), paiement cash ou crypto, livreurs géolocalisés avec assignation automatique, et un livreur dispose d'un bouton d'alerte police en cas de contrôle/danger pendant une livraison. Cette nature du produit (aucune auto-inscription client, alerte police, paiement crypto natif, pénalités dissuasives sur annulation tardive) doit rester présente à l'esprit : les règles de sécurité et de discrétion opérationnelle (VPN, filtrage des données sensibles pour les livreurs, pas de traces inutiles) sont volontaires, pas accidentelles. + +## Rôles et permissions + +| Rôle | Description | Peut faire | +|------|-------------|------------| +| **client** | Utilisateur final | Panier, checkout, suivi commande, approuver/annuler, parrainage, points/récompenses, profil, 2FA | +| **admin** | Gestion complète | Tout : produits, clients, commandes, livreurs, cabine, pénalités, paramètres globaux, reset stats | +| **livreur** | Livreur assigné | Voir ses livraisons (données client filtrées), changer statut, position GPS, queue, alerte police, notifications | +| **cabine** | Cuisine/préparation | Voir items commande, préparer/emballer, assigner livreur, confirmer réception, pénalités client, alertes | + +Règles clés (dont certaines issues du changelog sécurité v5.4.0) : +- **Aucune auto-inscription** — les comptes clients sont créés **uniquement par un admin** (`POST /api/v2/admin/protected/clients`). Un nouvel endpoint d'inscription libre serait une régression de sécurité majeure. +- **Création de comptes admin entièrement bloquée côté application** — un compte `admin` ne peut être créé qu'en base de données directement, jamais via l'API, quel que soit le rôle appelant (y compris un autre admin). +- **`cabine` n'a plus aucun droit de création d'utilisateurs ou de clients** (retiré côté backend en v5.4.0) — seul `admin` crée des comptes `livreur` ou `cabine`. +- JWT séparés par famille de rôle : secret client (`USER_JWT_SECRET`, expiration 5h) ≠ secret admin/livreur/cabine (`ADMIN_JWT_SECRET`, expiration 10h/2h selon contexte). +- Chaque action livreur doit vérifier que la commande lui est **assignée** (`livreur_assign == usernameStr`), pas seulement le rôle. +- **Filtrage des données sensibles** : les livreurs ne reçoivent jamais le téléphone du client dans `GET /livreur/deliveries` — uniquement nom/prénom. Tout nouvel endpoint livreur exposant des données client doit respecter ce filtrage. + +## Cycle de vie d'une commande + +``` +pending → assigned → en_route → arrived → livre → approved + ↓ ↓ ↓ ↓ +cancelled (depuis presque tous les états — jamais depuis approved, jamais deux fois de suite) +``` + +- `pending` : créée au checkout, en attente d'assignation livreur (auto-assign GPS au checkout, ou worker CRON toutes les 1 minute, ou assignation manuelle admin/cabine). +- `assigned` : livreur choisi, pas encore parti. Le livreur peut aussi être réassigné manuellement (admin/cabine). +- `en_route` : livreur en chemin (`start` puis mise à jour de statut). ETA calculée (TomTom, fallback Haversine) et stockée dans Redis (`command:eta:{id}`), utilisée pour les notifications Telegram avec ETA. +- `arrived` : livreur à destination — déclenché par le livreur (GPS), ou par admin/cabine via bouton "Le livreur est là" (`notify-client`). Notifie le client (Telegram). **Timer 5 minutes** démarre côté app livreur (`frontend-admin`, `DashboardScreen.tsx`, `ABSENT_TIMEOUT_SECS = 300`) → si le client ne descend pas, bouton **"Client absent"** apparaît. +- `livre` : livraison confirmée. Deux voies : validation GPS livreur (distance ≤ 100m de la destination, coordonnées obligatoires) via `PUT /livreur/deliveries/:id/status`, ou override admin/cabine (`force-validate`/statut direct). En attente d'approbation client pour finaliser. +- `approved` : finalisée. Déclenché par le client (`POST /commands/:id/approve` avec note + commentaire livreur), ou admin/cabine (`confirm-reception`/statut direct en override). Points de fidélité attribués **à ce moment précis**, jamais avant (`CalculateAndAddPointsForCommandTx`, même transaction que le passage en `approved`). **Terminal** — plus aucune modification de stock ou de statut après. +- `cancelled` : peut survenir depuis quasiment tous les états précédents. Jamais depuis `approved`, jamais une seconde fois depuis `cancelled` (idempotence obligatoire). +- `pending_payment` : statut intermédiaire spécifique au paiement crypto (voir section Paiements) — pas dans le cycle "normal", bascule vers `pending` (paiement confirmé) ou `cancelled` (paiement échoué/expiré). + +**Trois chemins de code différents pour l'annulation** : `CancelCommandAtomic` (client), `UpdateDeliveryStatus`/branche `cancelled` (livreur — inclut le flux "client absent"), `UpdateCommandStatusAdmin` (admin/cabine). Toute règle métier touchant l'annulation (remboursement stock, pénalité, notification) doit être répercutée dans les **trois**, plus `CancelCryptoCommand` pour le cas crypto. + +**Correction d'adresse** : si une adresse ne peut pas être géocodée ou est jugée invalide, un flux de proposition existe (`adresse_correction` table, `invalid_address` → `correct_address`) — le client peut répondre à une proposition (`POST /commands/:id/address/respond`), l'admin peut modifier l'adresse directement (`PUT /orders/:id/address`). + +## Produits, catalogue et tarification + +- Un produit (`products`) a un `stock` en **float** (pas un entier — permet des unités fractionnaires/dosages), une `unit`, une ou plusieurs catégories, un flag `coming_soon` (produit visible mais pas encore commandable), et des médias (images). +- **Prix par quantité** (`product_prices`) : chaque palier de quantité a son propre prix et un flag `active_price`. Un prix désactivé (`active_price = false`) n'est **pas supprimé** — juste masqué. Les endpoints publics/client ne renvoient que les prix actifs ; `admin` et `cabine` voient tous les prix (actifs et inactifs) pour la gestion complète. Le frontend filtre aussi côté client par sécurité (`filter(p => p.active_price !== false)`). +- Désactiver un prix dans l'UI admin (retirer un prix existant) doit désactiver, pas supprimer — cohérence avec l'historique des commandes passées qui référencent ce prix. + +## Panier et stock + +- Le panier (`baskets`) vérifie le stock disponible à l'ajout (`AddToBasket`, rejet si insuffisant) mais ne le réserve pas au sens strict (pas de verrou tant que l'article reste dans le panier) — le stock réel n'est **décrémenté qu'à la validation de la commande** (checkout), dans une transaction unique avec la création de la commande et le vidage du panier. +- Un modèle `StockInfo` distingue `Quantity` (stock brut), `Reserved` (quantité présente dans des paniers actifs, à titre indicatif) et `Available` (`Quantity - Reserved`) — utilisé pour l'affichage admin, pas comme mécanisme de réservation dur. +- **Articles récompense** (`is_reward = true`, obtenus via le système de points, prix affiché = 0€ mais valeur indicative dans `RewardItem.Price`) : ce sont des produits physiques réellement distribués. **Le stock doit être décrémenté pour eux comme pour un article payant**, et remboursé de la même façon en cas d'annulation. Ne jamais les exclure du décompte de stock — seule leur tarification (débit en points au lieu d'euros) diffère. +- **Symétrie obligatoire** : toute décrémentation de stock doit avoir un chemin de remboursement, et vice-versa, **pour tous les articles sans exception** (récompense ou non). Une asymétrie désynchronise durablement le stock affiché de la réalité physique — c'est la classe de bug la plus dangereuse et la plus difficile à détecter de ce projet (corruption silencieuse, cumulative, visible seulement des semaines plus tard). +- Toute commande annulée deux fois (retry réseau, double-tap, ou canaux différents pour la même commande) ne doit rembourser le stock **qu'une seule fois** → nécessite un statut "already cancelled" idempotent vérifié **dans** une transaction verrouillée (`FOR UPDATE`), pas une simple vérification préalable hors transaction. +- Créer la commande + insérer les items + décrémenter le stock + vider le panier doivent être **une seule transaction** — sinon une commande "fantôme" (créée mais jamais payée en stock) peut survivre à un échec de décrément, puis être annulée plus tard et rembourser un stock jamais consommé. + +## Paramètres globaux configurables (`AppSettings`) + +Presque toutes les règles business ci-dessous sont **pilotées par un objet de settings unique**, modifiable par l'admin (`GET/PUT /api/v2/admin/protected/settings`) — ne jamais coder en dur une valeur qui existe déjà comme champ de `AppSettings` : + +| Domaine | Champs | Notes | +|---|---|---| +| Pénalités | `PenaltiesEnabled`, `ShowAmendeScore`, `PenaltyTiers[]` | Tiers par défaut : 0→20€, 1→50€, 2→100€, 3→150€ (voir section Pénalités) | +| Points | `PointsEnabled`, `PointsPools[]`, `PointsReward` | Pools par défaut : "Pool 1"/"Pool 2" avec barèmes différents (voir section Points) | +| Parrainage | `ReferralEnabled`, `ReferralAmount` | Montant crédité par défaut = 0 (doit être configuré par l'admin) | +| Paiement crypto | `CryptoPaymentEnabled`, `CryptoOnly`, `NowPaymentsAPIKey`, `NowPaymentsIPNSecret`, `NowPaymentsCurrencies[]` | `CryptoOnly = true` désactive le cash | +| Livraison | `DeliverySchedule` (horaires par jour), `PostalZones[]` (nom, minimum de commande, codes postaux), `DeliveryMode` | Voir sections dédiées | +| Telegram | `TelegramBotToken`, `TelegramBotUsername`, `TelegramNotificationsEnabled`, `Telegram2FAEnabled` | | +| Vitrine | `ShopName` (def. "Milieu-Nantais"), `ContactTelegram` (def. "MLN44LA"), couleurs admin/client, dégradé titre | Purement cosmétique | + +Toute nouvelle règle configurable doit suivre ce même modèle (ajout d'un champ `AppSettings` + valeur par défaut dans `DefaultSettings()`) plutôt qu'une constante Go. + +## Système de points et récompenses (multi-pool) + +- **Plusieurs "pools" de points** peuvent coexister, chacun associé à un sous-ensemble de catégories de produits (`PointsPool.Categories`) et avec son propre barème (`Tiers` : palier de montant dépensé → points gagnés, ex. 30–50€ → 1 point, 401€+ → 10 points). Un même achat peut alimenter un pool différent selon la catégorie du produit acheté. +- Les points cumulés par pool sont stockés hors table `clients` classique (`points_extra`/`points_redeemed`, champs calculés `gorm:"-"`) — lus via `GetClientPointsAndRewards`. +- **Récompense globale par seuil** (`PointsReward`) : un seuil de points (`Threshold`) débloque une récompense, dont l'éligibilité est filtrée par catégorie/produits (`CategoryConfigs`) **par pool** (seules les catégories appartenant au pool comptent). Le nombre de récompenses disponibles = `points_du_pool / Threshold - déjà_réclamées`. +- **Réclamation** (`POST` claim, `ClaimMyReward`) : ajoute les `RewardItems` définis (produit + quantité) au panier avec `is_reward = true` et `reward_pool_key` renseigné — c'est le seul mécanisme qui produit des articles récompense. Consomme une unité de récompense disponible pour ce pool (`points_redeemed` incrémenté). +- L'admin peut réinitialiser les récompenses réclamées d'un client pour un pool donné (`AdminResetClientRedeemed`). + +## Parrainage (parrain/filleul) + +- Un client peut être parrainé par un autre (`clients.parrain`). Lier un parrain + créditer le crédit de parrainage (`referral_balance`, montant = `AppSettings.ReferralAmount`) doit être **atomique** (une seule transaction) — sinon un crédit peut être appliqué sans lien enregistré ou l'inverse. +- Le crédit de parrainage se débite au checkout (`DebitReferralBalance`) et doit respecter le minimum de la zone de livraison **après** déduction du crédit (le panier effectif payé doit rester ≥ minimum de la zone du code postal, `PostalZones`). +- Si le checkout échoue après débit du crédit (paiement crypto refusé, création de commande en échec), le crédit doit être **recrédité** (`CreditClientReferral`) — sinon perte sèche pour le client. +- Le système peut être entièrement désactivé (`ReferralEnabled = false`) — vérifier ce flag avant d'exposer une action de parrainage. + +## Pénalités clients (amendes) + +- Amendes **client uniquement**, jamais de pénalité livreur. Stockées dans `clients.amende`, avec compteur `cancellations_count` et `last_penalty_reason`. +- Barème progressif **configurable** (`AppSettings.PenaltyTiers`, fallback interne si settings illisibles) — défaut : 1ère annulation 20€, 2ème 50€, 3ème 100€, 4ème+ 150€. Le montant appliqué = `penaltyForCount(cancellations_count, PenaltyTiers)`. +- Le système entier peut être désactivé (`PenaltiesEnabled = false`) — dans ce cas le middleware `BlockClientIfPenalty` laisse passer sans vérification. +- **Blocage du checkout** : tant que `amende > 0`, le middleware `BlockClientIfPenalty` bloque toute tentative de checkout (403), avec un cache de la pénalité en session Redis (`PenaltyCache`) pour éviter une lecture DB à chaque requête. Message standard invite à contacter le shop via Telegram pour régulariser. +- **Sources d'amende** : + - Client annule sa propre commande (`ApplyCancellationPenalty`, incrémente `cancellations_count`). + - Livreur marque le client absent depuis le statut `arrived` (bouton "Client absent", `issue_type: client_absent`) → `ApplyCancellationPenalty` appliqué automatiquement au **client**, jamais au livreur. + - Admin peut appliquer une pénalité manuelle arbitraire (`POST /admin/protected/penalty`, montant et raison libres) — indépendante du barème progressif. +- "Annulation tardive" (règle spécifique au flux client `CancelCommandAtomic`, distincte du flux "client absent" livreur) = livreur déjà assigné ET (statut `en_route`/`arrived` OU ETA valide déjà définie en Redis). Sans livreur assigné ou sans ETA valide → annulation sans pénalité. + +## Mode d'assignation des livreurs + +- `DeliveryMode.Mode` : `"single"` (un seul pool de livreurs, toutes catégories confondues — mode par défaut) ou `"category_based"` (chaque livreur est routé uniquement vers les commandes contenant les catégories qui lui sont assignées, via `CategoryRoutes`). +- En mode `category_based`, l'auto-assignation GPS doit filtrer les livreurs éligibles par catégorie **avant** de calculer les distances — une commande mixte (catégories de livreurs différents) est un cas limite à traiter explicitement si cette fonctionnalité est étendue. + +## GPS, auto-assignation et ETA + +- **Géocodage** : Nominatim (OpenStreetMap), résultat caché 7 jours (`geocode:cache:{hash}`). +- **Distance à vol d'oiseau** : formule Haversine, calculée localement, aucun appel externe. +- **ETA avec trafic réel** : TomTom Routing API. **Rotation automatique jusqu'à 3 clés** (`TOMTOM_API_KEY_1/2/3`) — en cas de quota dépassé (403/429), bascule automatique sur la clé suivante sans interruption ; si toutes les clés sont épuisées, fallback sur estimation Haversine + vitesse moyenne 30 km/h (flag `fallback_used: true` dans la réponse). +- **Auto-assignation** : au checkout (immédiate si un livreur est disponible) et via un worker CRON toutes les 1 minute pour les commandes restées `pending`. Sélectionne le livreur disponible le plus proche avec de la capacité ; si tous sont à capacité maximale, le système peut forcer l'assignation. +- **Capacité de queue** : jusqu'à **10 commandes** par livreur. Un livreur `offline` ne reçoit aucune commande. +- Position GPS livreur stockée dans Redis (`delivery:location:{username}`, TTL 2h) et diffusée en temps réel via Redis Pub/Sub (`channel:position_updates`) pour la carte client/admin. +- Liens de navigation générés vers Google Maps / Waze / Apple Maps / OSM / Bing / Here, pour le livreur comme pour l'admin (supervision). + +## Paiements + +- **Cash** (par défaut, sauf si `CryptoOnly = true`) : le livreur encaisse à la livraison, aucun flux électronique. +- **Crypto** (NowPayments) : commande passe en `pending_payment` en attendant confirmation. Le webhook IPN (`POST /webhooks/nowpayments`) est **public** mais signé HMAC-SHA512 (`x-nowpayments-sig`) — vérifier la signature avant tout traitement, jamais faire confiance au contenu brut. Statuts `finished`/`confirmed` → activent la commande (repasse en `pending`, entre dans le cycle normal) ; `failed`/`expired` → annulent et remboursent stock + crédit parrainage. +- Le stock est décrémenté **dès la création de la commande crypto** (avant confirmation du paiement) — une commande crypto non payée réserve quand même le stock pendant la fenêtre de paiement, et le libère si elle expire/échoue. +- `CryptoPaymentEnabled = false` désactive complètement l'option crypto au checkout ; `CryptoOnly = true` la rend obligatoire. + +## Alertes police (sécurité opérationnelle livreur) + +- Un livreur peut déclencher une **alerte police** à tout moment (`POST /livreur/alert`, message optionnel) — notifie immédiatement tous les admins et cabine (`NotifyAllAdminCabineAlert`). C'est un bouton de sécurité personnelle, pas lié à une commande précise. +- Les alertes peuvent être supprimées par le livreur qui les a créées ou par un admin. + +## Notifications et 2FA + +- **Telegram uniquement** — les push Expo sont abandonnées (v5.4.0). Clients, livreurs, admins lient leur compte via un token à usage unique (TTL court, ex. 5 min). +- Types de notifications : `assigned`, `en_route` (avec ETA), `arrived`, `livre`, `ready_pickup` (cabine), `address_proposal`. +- 2FA (client) : nécessite Telegram lié + activation admin globale (`Telegram2FAEnabled`) + toggle personnel du client. Code 6 chiffres, `session_token` TTL 5 min, rate-limité (429 après trop de tentatives). +- Le système de notifications peut être désactivé globalement (`TelegramNotificationsEnabled = false`). + +## Infrastructure (contexte pour évaluer l'impact d'un changement) + +- Serveurs séparés reliés par VPN WireGuard privé (`10.0.0.0/24`) : `vpn-uber` (jump host), `monitoring-uber` (Wazuh/Dozzle/Beszel), `backup-mln` (MinIO S3 + ClamAV), `bdd-redis-prod` (PostgreSQL + Redis, **jamais exposé publiquement**), `prod-uber` (backend + WAF, seul serveur public sur 80/443). +- PostgreSQL et Redis accessibles uniquement via IP VPN (`10.0.0.5`) depuis `prod-uber` — **latence réseau non négligeable**, d'où l'importance de grouper les requêtes (batch inserts, requêtes `IN`, parallélisation des stats déjà faites dans ce projet). +- WAF nginx + ModSecurity (OWASP CRS) devant l'API en prod ; logs nginx/ModSecurity montés sur l'hôte pour collecte Wazuh. +- Déploiement : push sur `pre-prod` → CI build image Docker (`xor1234/backend-mln:pre-prod`) → déploiement SSH. +- Workers automatiques : auto-assignation (1 min), nettoyage queues (5 min), mise à jour ETA (30 s), nettoyage stock (5 min). + +## Erreurs passées à ne pas reproduire (mémoire vive du projet) + +- Vider le panier **avant** de décrémenter le stock (au lieu d'une seule transaction) → stock jamais décrémenté en pratique. +- Restaurer le stock sans vérifier le statut précédent dans une transaction verrouillée → double remboursement sur double-annulation (le livreur avait ce bug, l'admin ne l'avait pas — incohérence entre chemins de code équivalents). +- Créer la commande + insérer les items **avant** la transaction de décrément de stock → commande fantôme si le décrément échoue (stock insuffisant détecté trop tard), qui peut ensuite être annulée et rembourser un stock jamais consommé. +- Exclure les articles récompense du décompte de stock sans les exclure aussi du remboursement (ou l'inverse) → asymétrie, stock qui dérive. Règle définitive validée par l'équipe : **les récompenses décrémentent et remboursent le stock exactement comme un article payant**. +- Coder en dur une valeur métier (barème de pénalité, montant de parrainage, seuil de points) qui existe déjà comme champ configurable dans `AppSettings` — toujours lire les settings, ne jamais dupliquer une constante. diff --git a/.claude/skills/plan-fonctionnalite/SKILL.md b/.claude/skills/plan-fonctionnalite/SKILL.md new file mode 100644 index 00000000..84b8245f --- /dev/null +++ b/.claude/skills/plan-fonctionnalite/SKILL.md @@ -0,0 +1,64 @@ +--- +name: plan-fonctionnalite +description: À invoquer avant d'implémenter toute nouvelle fonctionnalité ou modification significative de logique métier sur ce projet. Produit un plan détaillé (compréhension métier, sécurité, impact données, concurrence, tests) à valider avec l'utilisateur avant d'écrire du code — n'implémente rien tant que le plan n'est pas approuvé. +--- + +# Plan de développement de fonctionnalité + +Ce skill encadre le développement de toute fonctionnalité non triviale sur ce projet. Règle centrale : **pas de code avant un plan validé par l'utilisateur**, sauf si la demande est un pur bug fix local déjà bien compris (dans ce cas, ce skill ne s'applique pas — voir "Quand ne pas utiliser ce skill"). + +## Étape 0 — Charger le contexte + +Avant de rédiger le plan : +1. Invoquer/relire le skill `comprehension-metier` pour ancrer le raisonnement dans les vraies règles du domaine (rôles, cycle de vie commande, stock, parrainage, pénalités, paiements). +2. Repérer le(s) rôle(s) concerné(s) par la fonctionnalité (client / admin / livreur / cabine) et les fichiers existants correspondants (`handlers/`, `db/`) pour ne pas dupliquer un mécanisme déjà présent. +3. Si la demande est ambiguë sur une règle métier (ex: "qui peut faire X", "est-ce que ça affecte le stock"), poser la question plutôt que de supposer. + +## Étape 1 — Rédiger le plan + +Utiliser `EnterPlanMode` si l'outil est disponible pour ce tour ; sinon présenter le plan en texte structuré et attendre confirmation explicite avant de coder. Le plan doit couvrir, dans cet ordre : + +### 1. Résumé fonctionnel +Quoi, pour qui, pourquoi — en une ou deux phrases orientées métier (pas techniques). + +### 2. Rôles et permissions +- Qui déclenche l'action, qui peut la voir, qui peut l'annuler/modifier. +- Nouveau endpoint ? → préciser le middleware d'auth (client vs admin/livreur/cabine) et la vérification de propriété de ressource. + +### 3. Impact sur les données +- Nouvelles colonnes/tables ? Migration nécessaire (`ALTER TABLE ... IF NOT EXISTS` dans `db_init.go`, cohérent avec le style existant du projet). +- Tables existantes affectées, et sens des colonnes touchées (stock, solde, statut, compteur). + +### 4. Flux détaillé +- Étapes séquencées, y compris les statuts intermédiaires si la fonctionnalité touche au cycle de vie d'une commande. +- Effets de bord obligatoires à tracer explicitement : stock (décrément/remboursement symétriques, y compris articles récompense), points de fidélité, solde de parrainage, pénalités, notifications Telegram. + +### 5. Sécurité (voir skill `securite-projet` pour le détail) +- Validation d'entrée (bornes, whitelist de statuts, longueur). +- Requêtes paramétrées uniquement. +- Si paiement ou webhook externe impliqué : vérification de signature avant traitement. +- Pas de nouveau chemin d'auto-inscription ou de contournement d'autorisation. + +### 6. Concurrence et atomicité +- Cette action peut-elle être rejouée (double-tap, retry réseau, webhook dupliqué) ? Si oui : mécanisme d'idempotence explicite (vérifier l'état courant avant d'agir, retourner un succès idempotent plutôt qu'une erreur ou un double effet). +- Lecture-puis-décision-puis-écriture sur une valeur partagée (stock, solde) ? → transaction unique avec `FOR UPDATE`, jamais une suite d'appels séparés. +- Toute création d'enregistrement (commande, paiement) doit être dans la **même transaction** que ses effets de bord critiques (décrément stock, débit solde) — pas de risque d'enregistrement "fantôme" si une étape suivante échoue. + +### 7. Plan de test +- Cas nominal. +- Cas limite métier (stock insuffisant, solde insuffisant, commande déjà dans l'état cible, ressource appartenant à un autre utilisateur). +- Cas de concurrence si pertinent (double-tap simulé, deux requêtes quasi simultanées). +- Comment vérifier après implémentation (`go build`, `go vet`, test manuel via `/verify` ou l'app si UI concernée). + +### 8. Points ouverts +Toute question métier ou technique non tranchée, à soumettre explicitement à l'utilisateur plutôt que de trancher seul par défaut. + +## Étape 2 — Validation puis implémentation + +Ne commencer l'implémentation qu'après retour explicite de l'utilisateur sur le plan. Si l'utilisateur ne modifie rien, considérer le plan tel quel comme approuvé. Implémenter ensuite en suivant fidèlement les sections Sécurité et Concurrence du plan — elles ne sont pas optionnelles une fois validées. + +## Quand ne pas utiliser ce skill + +- Bug fix ponctuel et bien circonscrit (ex: correction d'une requête, d'un typo, d'une regression déjà diagnostiquée) où un plan formel ajouterait de la friction sans valeur — corriger directement. +- Modification purement cosmétique (style, renommage local, commentaire). +- Le skill s'applique dès qu'une action touche : un nouveau statut ou transition de commande, un flux d'argent ou de points, une nouvelle route API, ou un changement de permission. diff --git a/.claude/skills/securite-projet/SKILL.md b/.claude/skills/securite-projet/SKILL.md new file mode 100644 index 00000000..58c59a0c --- /dev/null +++ b/.claude/skills/securite-projet/SKILL.md @@ -0,0 +1,46 @@ +--- +name: securite-projet +description: Checklist de sécurité spécifique à ce projet (JWT multi-rôles, 2FA Telegram, webhook crypto NowPayments, VPN, WAF, création de comptes admin-only). À invoquer avant de merger tout code touchant à l'authentification, aux paiements, aux endpoints admin/livreur/cabine, ou à l'infrastructure serveur — en complément du skill générique security-review, pas à sa place. +--- + +# Sécurité — spécifique à ce projet + +Cette checklist complète (ne remplace pas) le skill générique `security-review`. Elle encode les règles de sécurité **propres à cette plateforme**, qui ne sont pas détectables par une revue générique OWASP. + +## Authentification et autorisation + +- **Deux familles de JWT strictement séparées** : `USER_JWT_SECRET` (client) et `ADMIN_JWT_SECRET` (admin/livreur/cabine). Ne jamais faire valider un token d'une famille par le middleware de l'autre. +- Sessions actives trackées dans Redis (`session:{token}`, TTL 5h client / 2h admin) — la révocation d'un token doit supprimer la clé Redis correspondante, pas seulement compter sur l'expiration JWT. +- **Aucun endpoint d'auto-inscription client** ne doit exister. Si une tâche demande d'ajouter un moyen de créer un compte client hors du panel admin, c'est un signal d'alerte à soulever explicitement avant d'implémenter. +- Pour tout nouvel endpoint livreur/cabine : vérifier le rôle **et** la propriété de la ressource (`livreur_assign == username`), jamais le rôle seul. C'est l'erreur la plus fréquente dans ce code : un livreur authentifié valide ne doit agir que sur ses propres commandes. +- 2FA : le `session_token` de vérification (TTL 5 min) et le code à 6 chiffres doivent rester **rate-limités** (429 après trop de tentatives) — ne jamais retirer ce rate limiting pour "simplifier" un flux. + +## Paiements crypto (NowPayments) + +- Le webhook `POST /api/v1/webhooks/nowpayments` est un endpoint **public** par nécessité (appelé par NowPayments, pas par un utilisateur authentifié). Sa seule protection est la vérification **HMAC-SHA512** de l'en-tête `x-nowpayments-sig` — ne jamais traiter un payload dont la signature ne vérifie pas, quel que soit le contenu. +- Ne jamais faire confiance à un statut de paiement transmis par le client (ex: un champ `payment_status` dans une requête utilisateur) — seul le webhook signé ou un appel serveur-à-serveur à l'API NowPayments (`GetPaymentStatus`) fait foi. +- Toute transition `pending_payment → cancelled` doit être gardée par une vérification du statut courant (`WHERE status = 'pending_payment'`) pour éviter un double remboursement de stock si le webhook est reçu plusieurs fois (NowPayments peut renvoyer le même événement). + +## Requêtes base de données + +- Toutes les requêtes utilisent des paramètres liés GORM (`?` binding) — **jamais** de concaténation de chaînes dans une requête `Raw`/`Exec`, y compris pour des valeurs qui semblent "internes" (statuts, IDs). Une seule exception acceptable : les noms de colonnes/tables provenant d'une liste blanche fixe dans le code, jamais d'une entrée utilisateur. +- Toute opération qui lit puis modifie un compteur/solde partagé (stock, solde de parrainage, compteur d'annulations) doit se faire dans une transaction avec `FOR UPDATE` si une décision (ex: "stock suffisant ?") dépend de la valeur lue — sinon condition de course exploitable (survente, sur-crédit). + +## Infrastructure + +- PostgreSQL et Redis ne sont **jamais** exposés publiquement — accessibles uniquement via le VPN WireGuard (`10.0.0.0/24`) depuis `prod-uber`. Ne jamais suggérer d'ouvrir ces ports sur l'IP publique, même temporairement pour du debug. +- Les secrets (`.env`, clés JWT, `NOWPAYMENTS_IPN_SECRET`, `TELEGRAM_WEBHOOK_SECRET`) ne doivent jamais apparaître dans un commit, un log applicatif, ou une réponse API d'erreur. +- Le WAF (nginx + ModSecurity OWASP CRS) est le point d'entrée public — toute modification de routes ou de headers doit rester compatible avec ses règles (CSP, HSTS, TLS 1.2/1.3). +- SSH restreint au VPN sur les serveurs sensibles (`monitoring-uber`, `backup-mln`, `bdd-redis-prod`) — jump host via `vpn-uber`. Ne jamais recommander de désactiver cette restriction. + +## Checklist rapide avant de merger un changement sensible + +Pour tout endpoint touchant argent, stock, statut de commande, ou compte utilisateur : + +- [ ] Rôle **et** propriété de la ressource vérifiés (pas l'un sans l'autre) +- [ ] Entrées validées (bornes numériques, longueur de chaîne, whitelist de statuts) +- [ ] Requêtes paramétrées, aucune concaténation SQL +- [ ] Opération idempotente si l'action peut être rejouée (retry réseau, double-tap, webhook dupliqué) +- [ ] Transaction + verrou (`FOR UPDATE`) si lecture-puis-décision-puis-écriture sur une valeur partagée +- [ ] Pas de nouveau secret ou donnée sensible loggé en clair +- [ ] Si paiement crypto impliqué : signature webhook vérifiée avant tout traitement diff --git a/.claude/skills/test-logique-metier/SKILL.md b/.claude/skills/test-logique-metier/SKILL.md new file mode 100644 index 00000000..1abce50e --- /dev/null +++ b/.claude/skills/test-logique-metier/SKILL.md @@ -0,0 +1,145 @@ +--- +name: test-logique-metier +description: À lancer systématiquement à la fin de l'implémentation de toute fonctionnalité touchant à la logique métier (stock, commandes, paiements, points, parrainage, pénalités). Démarre l'API en local, exécute une série de scénarios réels via curl contre l'API, et vérifie en base que les invariants métier tiennent (stock décrémenté puis remboursé exactement, idempotence, autorisations par rôle). Ne se contente pas de lire le code — observe le comportement réel. +--- + +# Test de logique métier — vérification comportementale locale + +Ce skill exécute des tests **de bout en bout contre une instance locale de l'API**, pas une relecture de code. Objectif : détecter les bugs de la classe "le code compile et semble correct, mais le comportement observé diverge" — exactement le type de bugs trouvés et corrigés dans ce projet (stock jamais décrémenté, double remboursement, commande fantôme). S'appuie sur les règles métier du skill `comprehension-metier` : le lire d'abord si ce n'est pas déjà fait. + +**Ne jamais exécuter ces tests contre la base pre-prod ou prod.** Uniquement contre un environnement local jetable. + +## Quand l'utiliser + +- À la fin de l'implémentation de toute fonctionnalité qui touche : stock, cycle de vie d'une commande, paiement (cash/crypto), points/récompenses, parrainage, pénalités, permissions par rôle. +- Après toute correction de bug dans ces domaines (pour confirmer la correction ET l'absence de régression sur les cas adjacents). +- Complément du skill `plan-fonctionnalite` (étape "plan de test" de ce skill) — celui-ci l'exécute réellement au lieu de rester une liste sur papier. +- Ne pas l'utiliser pour un changement purement cosmétique ou un fix qui ne touche aucune règle métier. + +## Étape 0 — Préparer l'environnement local + +```bash +# 1. Postgres + Redis locaux (depuis backend/gestion/) +cd backend/gestion +docker compose up -d +docker compose ps # attendre "healthy" sur les deux services + +# 2. Variables d'environnement minimales (adapter aux valeurs du .env local) +export DB_HOST=localhost DB_PORT=5432 DB_USER=postgres DB_PASSWORD=postgres DB_NAME= +export REDIS_HOST=localhost REDIS_PORT=6379 REDIS_PASSWORD= +export USER_JWT_SECRET=$(openssl rand -hex 32) +export ADMIN_JWT_SECRET=$(openssl rand -hex 32) + +# 3. Lancer l'API (dans un terminal séparé ou en arrière-plan) +go run main.go # écoute sur :8080, crée les tables au démarrage (createTables) +``` + +Vérifier que l'API répond avant de continuer : +```bash +curl -sf http://localhost:8080/api/v1/app-settings > /dev/null && echo "API up" +``` + +## Étape 1 — Obtenir un compte admin de test + +**La création d'un compte admin est volontairement bloquée via l'API** (voir `comprehension-metier`) — impossible d'obtenir un token admin par un simple appel HTTP. Il faut l'insérer directement en base locale (jetable, jamais en pre-prod/prod) : + +```bash +# Générer un hash bcrypt pour le mot de passe de test +HASH=$(go run -exec "" - <<'EOF' 2>/dev/null || python3 -c "import bcrypt; print(bcrypt.hashpw(b'TestPass123!', bcrypt.gensalt()).decode())" +package main +import ("fmt"; "golang.org/x/crypto/bcrypt") +func main() { + h, _ := bcrypt.GenerateFromPassword([]byte("TestPass123!"), bcrypt.DefaultCost) + fmt.Println(string(h)) +} +EOF +) + +docker exec -i gestion_postgres psql -U postgres -d -c \ + "INSERT INTO users (username, password, role) VALUES ('test_admin', '$HASH', 'admin') ON CONFLICT (username) DO NOTHING;" +``` + +Puis se connecter normalement : +```bash +ADMIN_TOKEN=$(curl -s -X POST http://localhost:8080/api/v2/admin/auth/login \ + -H "Content-Type: application/json" \ + -d '{"username":"test_admin","password":"TestPass123!"}' | jq -r .access_token) +``` + +À partir de ce token admin, créer les comptes de test nécessaires **via l'API** (c'est le chemin normal) : client de test, livreur de test, cabine de test — jamais par insertion SQL directe pour ceux-là, afin de tester le vrai chemin de création. + +## Étape 2 — Méthode générale + +Pour chaque scénario : **agir via l'API (curl)**, puis **vérifier l'état réel en base** (`docker exec gestion_postgres psql ...`) plutôt que de se fier uniquement à la réponse HTTP — une réponse 200 ne prouve pas que l'effet de bord a eu lieu correctement. + +Gabarit de vérification stock : +```bash +docker exec -i gestion_postgres psql -U postgres -d -t -c \ + "SELECT stock FROM products WHERE id = $PRODUCT_ID;" +``` + +Toujours noter le stock **avant** l'action, exécuter l'action, relire le stock **après**, et comparer à la valeur attendue calculée manuellement (pas juste "différent de avant"). + +## Étape 3 — Scénarios à exécuter + +### Stock — commande normale +1. Créer un produit avec stock connu (ex. 10). +2. Client ajoute 3 unités au panier, checkout. +3. Vérifier : stock produit = 7 exactement. +4. Client annule la commande. +5. Vérifier : stock produit = 10 exactement (retour à la valeur initiale). + +### Stock — articles récompense +1. Configurer un pool de points avec un seuil bas et un `RewardItem` pointant vers un produit à stock connu. +2. Faire gagner assez de points au client de test (achats successifs), puis réclamer la récompense (`ClaimMyReward`). +3. Checkout incluant l'article récompense. +4. Vérifier : stock décrémenté de la quantité offerte, **comme un article payant**. +5. Annuler la commande → vérifier stock restauré exactement. + +### Stock — idempotence de l'annulation +1. Créer une commande, la faire annuler une première fois (client, livreur, ou admin — tester les trois chemins séparément). +2. Rejouer le même appel d'annulation une seconde fois sur la même commande. +3. Vérifier : le second appel ne modifie **pas** le stock une seconde fois (comparer stock après 1er appel et après 2e appel — doivent être identiques), et renvoie une réponse cohérente (pas une erreur qui laisserait croire à un échec silencieux). + +### Stock — commande fantôme / double-submit +1. Vider le panier d'un client, y ajouter un article dont le stock est juste suffisant pour une seule commande (ex. stock = 2, quantité demandée = 2). +2. Envoyer **deux requêtes de checkout quasi simultanées** pour ce même client (deux processus curl en parallèle, `&` en shell). +3. Vérifier : une seule commande a réellement décrémenté le stock, l'autre échoue proprement (panier vide ou stock insuffisant) — **aucune commande "pending" orpheline** ne doit rester en base avec des `command_items` mais un stock jamais décrémenté pour elle. + +### Paiement crypto +1. Checkout avec `payment_method: crypto` → vérifier statut `pending_payment` et stock déjà décrémenté à ce stade. +2. Simuler le webhook IPN avec statut `failed` (signature HMAC valide requise — générer avec le secret de test) → vérifier commande `cancelled` et stock restauré. +3. Répéter avec statut `finished` sur une nouvelle commande → vérifier commande repasse en `pending` (cycle normal), stock reste décrémenté. +4. Renvoyer deux fois le même webhook `failed` → vérifier pas de double remboursement. + +### Parrainage +1. Lier un parrain à un client, vérifier `referral_balance` du parrain crédité du montant configuré (`ReferralAmount`). +2. Checkout du filleul avec crédit parrainage utilisé, panier tout juste au-dessus du minimum de zone + crédit → vérifier acceptation ; en dessous → vérifier rejet avec message explicite. +3. Faire échouer le checkout après débit du crédit (ex. stock insuffisant découvert tardivement) → vérifier que `referral_balance` est recrédité, pas perdu. + +### Points et récompenses +1. Vérifier que les points s'accumulent dans le bon pool selon la catégorie du produit acheté (pas dans tous les pools). +2. Réclamer une récompense au-delà du nombre disponible → vérifier rejet. +3. Reset admin des récompenses réclamées d'un client → vérifier que le compteur repart à zéro et que de nouvelles réclamations redeviennent possibles. + +### Pénalités +1. Simuler 4 annulations successives du même client (avec livreur assigné + statut `en_route`/`arrived` pour déclencher la pénalité) → vérifier progression exacte du barème (20€, 50€, 100€, 150€ ou barème configuré). +2. Avec `amende > 0`, tenter un checkout → vérifier blocage 403 avec message contact. +3. Simuler le flux "client absent" (livreur annule depuis `arrived`) → vérifier pénalité appliquée au **client**, jamais au livreur. +4. Annulation sans livreur assigné → vérifier absence de pénalité. + +### Permissions par rôle +1. Token livreur A tente d'agir sur une commande assignée à livreur B → vérifier 403 (pas seulement vérification du rôle, vérification de la propriété). +2. Token client tente d'accéder à une route admin → 403. +3. Vérifier qu'aucun endpoint ne permet de créer un compte `admin` via l'API (tenter et confirmer le rejet/l'absence de route). +4. Vérifier que le livreur ne reçoit jamais le téléphone du client dans `GET /livreur/deliveries`. + +## Étape 4 — Rapport et suite + +Pour chaque scénario : **PASS** ou **FAIL** avec la preuve chiffrée (valeurs avant/après). En cas de FAIL, ce n'est pas la fin du skill — revenir au code, corriger, puis **relancer uniquement les scénarios concernés** (pas besoin de tout rejouer) jusqu'à ce que tout passe. Ne jamais considérer une fonctionnalité "terminée" avec un scénario en FAIL non expliqué. + +## Nettoyage + +```bash +docker compose down -v # supprime aussi les volumes (base de test jetable) +``` diff --git a/backend/gestion/db/db_cancel_command.go b/backend/gestion/db/db_cancel_command.go index 9b608313..317788af 100644 --- a/backend/gestion/db/db_cancel_command.go +++ b/backend/gestion/db/db_cancel_command.go @@ -325,3 +325,43 @@ func (d *Database) RestoreCommandStock(commandID int) error { WHERE ci.command_id = ? AND ci.product_id = p.id`, commandID).Error }) } + +// CancelDeliveryByLivreurAtomic annule une commande côté livreur et restaure le stock +// de manière atomique (verrou FOR UPDATE + transition conditionnée à l'ancien statut). +// Idempotent : si la commande est déjà annulée, ne touche pas au stock et renvoie +// alreadyCancelled=true — évite un remboursement en double en cas de double appel +// (double-tap, retry réseau, ou commande déjà annulée par un autre canal). +func (d *Database) CancelDeliveryByLivreurAtomic(commandID int) (alreadyCancelled bool, prevStatus string, err error) { + err = d.GDB.Transaction(func(tx *gorm.DB) error { + if e := tx.Raw(`SELECT status FROM commandes WHERE id = ? FOR UPDATE`, commandID).Scan(&prevStatus).Error; e != nil { + return e + } + if prevStatus == "" { + return fmt.Errorf("commande non trouvée") + } + if prevStatus == "cancelled" { + alreadyCancelled = true + return nil + } + + result := tx.Exec(` + UPDATE commandes SET status = 'cancelled', updated_at = CURRENT_TIMESTAMP + WHERE id = ? AND status = ?`, commandID, prevStatus) + if result.Error != nil { + return result.Error + } + if result.RowsAffected == 0 { + return fmt.Errorf("commande déjà modifiée par une autre requête") + } + + if e := tx.Exec(` + UPDATE products p + SET stock = stock + ci.quantite, updated_at = CURRENT_TIMESTAMP + FROM command_items ci + WHERE ci.command_id = ? AND ci.product_id = p.id`, commandID).Error; e != nil { + return fmt.Errorf("erreur remboursement stock: %w", e) + } + return nil + }) + return +} diff --git a/backend/gestion/db/db_commands.go b/backend/gestion/db/db_commands.go index dba5f664..3da933cd 100644 --- a/backend/gestion/db/db_commands.go +++ b/backend/gestion/db/db_commands.go @@ -96,64 +96,66 @@ func (d *Database) CreateCommand(username string) (*models.Command, error) { adresse = clientCheck.Username } - basketItems, totalPrix, err := d.fetchBasketItems(username) - if err != nil { - return nil, err - } - - if len(basketItems) == 0 { - return nil, fmt.Errorf("le panier est vide") - } - - var cmdResult struct { - ID int `gorm:"column:id"` - ClientOrderID int `gorm:"column:client_order_id"` - CreatedAt time.Time `gorm:"column:created_at"` - UpdatedAt time.Time `gorm:"column:updated_at"` - } - err = d.GDB.Raw(` - INSERT INTO commandes (username, status, adresse, total_prix, client_order_id, created_at, updated_at) - VALUES (?, ?, ?, ?, (SELECT COALESCE(MAX(client_order_id), 0) + 1 FROM commandes WHERE username = ?), CURRENT_TIMESTAMP, CURRENT_TIMESTAMP) - RETURNING id, client_order_id, created_at, updated_at`, - username, "pending", adresse, totalPrix, username).Scan(&cmdResult).Error - if err != nil { - return nil, fmt.Errorf("erreur lors de la création de la commande: %w", err) - } - - commandID := cmdResult.ID - - productIDs := make([]int, 0, len(basketItems)) - for _, item := range basketItems { - productIDs = append(productIDs, item.ProductID) - } - productNames, _ := d.GetProductNamesByIDs(productIDs) - - cmdItems := make([]models.CommandItem, 0, len(basketItems)) - for _, item := range basketItems { - productName := productNames[item.ProductID] - if productName == "" { - productName = "Produit inconnu" + var command *models.Command + err := d.GDB.Transaction(func(tx *gorm.DB) error { + // Verrou sur le panier : un double-submit concurrent du même client se + // bloque ici puis échoue proprement ("panier vide") une fois le premier + // passage terminé, au lieu de créer une commande fantôme. + var basketItems []basketItem + if err := tx.Raw(`SELECT product_id, quantity, price, is_reward, reward_pool_key FROM baskets WHERE username = ? FOR UPDATE`, username).Scan(&basketItems).Error; err != nil { + return fmt.Errorf("erreur récupération panier: %w", err) } - cmdItems = append(cmdItems, models.CommandItem{ - CommandID: commandID, - Produit: productName, - ProductID: item.ProductID, - Quantity: item.Quantity, - Price: item.Price, - IsReward: item.IsReward, - RewardPoolKey: item.RewardPoolKey, - }) - } - if err := d.GDB.Create(&cmdItems).Error; err != nil { - return nil, fmt.Errorf("erreur lors de l'insertion des items: %w", err) - } - - // Décrémenter le stock et vider le panier de manière atomique. - if err := d.GDB.Transaction(func(tx *gorm.DB) error { + if len(basketItems) == 0 { + return fmt.Errorf("le panier est vide") + } + totalPrix := 0.0 for _, item := range basketItems { - if item.IsReward { - continue + totalPrix += item.Price + } + + var cmdResult struct { + ID int `gorm:"column:id"` + ClientOrderID int `gorm:"column:client_order_id"` + } + if err := tx.Raw(` + INSERT INTO commandes (username, status, adresse, total_prix, client_order_id, created_at, updated_at) + VALUES (?, ?, ?, ?, (SELECT COALESCE(MAX(client_order_id), 0) + 1 FROM commandes WHERE username = ?), CURRENT_TIMESTAMP, CURRENT_TIMESTAMP) + RETURNING id, client_order_id`, + username, "pending", adresse, totalPrix, username).Scan(&cmdResult).Error; err != nil { + return fmt.Errorf("erreur lors de la création de la commande: %w", err) + } + commandID := cmdResult.ID + + productIDs := make([]int, 0, len(basketItems)) + for _, item := range basketItems { + productIDs = append(productIDs, item.ProductID) + } + productNames, _ := d.GetProductNamesByIDs(productIDs) + + cmdItems := make([]models.CommandItem, 0, len(basketItems)) + for _, item := range basketItems { + productName := productNames[item.ProductID] + if productName == "" { + productName = "Produit inconnu" } + cmdItems = append(cmdItems, models.CommandItem{ + CommandID: commandID, + Produit: productName, + ProductID: item.ProductID, + Quantity: item.Quantity, + Price: item.Price, + IsReward: item.IsReward, + RewardPoolKey: item.RewardPoolKey, + }) + } + if err := tx.Create(&cmdItems).Error; err != nil { + return fmt.Errorf("erreur lors de l'insertion des items: %w", err) + } + + // Les articles récompense (payés en points) restent des produits physiques + // réellement distribués : le stock doit être décrémenté comme pour un + // article payant. + for _, item := range basketItems { var currentStock float64 if err := tx.Raw(`SELECT stock FROM products WHERE id = ? FOR UPDATE`, item.ProductID).Scan(¤tStock).Error; err != nil { return fmt.Errorf("erreur lecture stock produit %d: %w", item.ProductID, err) @@ -165,16 +167,20 @@ func (d *Database) CreateCommand(username string) (*models.Command, error) { return fmt.Errorf("erreur décrémentation stock produit %d: %w", item.ProductID, err) } } - return tx.Exec(`DELETE FROM baskets WHERE username = ?`, username).Error - }); err != nil { - return nil, err - } + if err := tx.Exec(`DELETE FROM baskets WHERE username = ?`, username).Error; err != nil { + return err + } - command := &models.Command{ - ID: commandID, - ClientOrderID: cmdResult.ClientOrderID, - Status: "pending", - Total: totalPrix, + command = &models.Command{ + ID: commandID, + ClientOrderID: cmdResult.ClientOrderID, + Status: "pending", + Total: totalPrix, + } + return nil + }) + if err != nil { + return nil, err } return command, nil @@ -203,83 +209,84 @@ func (d *Database) CreateCommandWithAddress(username, deliveryAddress string) (* clientTelephone = sanitizeString(client.Telephone) } - basketItems, totalPrix, err := d.fetchBasketItems(username) - if err != nil { - log.Printf("❌ Erreur query basket: %v", err) - return nil, err - } - - if len(basketItems) == 0 { - return nil, fmt.Errorf("le panier est vide") - } - - for _, item := range basketItems { - if item.ProductID <= 0 || item.Quantity <= 0 || item.Price < 0 { - return nil, fmt.Errorf("données panier invalides") + var ( + command *models.Command + totalPrix float64 + ) + err = d.GDB.Transaction(func(tx *gorm.DB) error { + // Verrou sur le panier : un double-submit concurrent du même client se + // bloque ici puis échoue proprement ("panier vide") une fois le premier + // passage terminé, au lieu de créer une commande fantôme. + var basketItems []basketItem + if err := tx.Raw(`SELECT product_id, quantity, price, is_reward, reward_pool_key FROM baskets WHERE username = ? FOR UPDATE`, username).Scan(&basketItems).Error; err != nil { + return fmt.Errorf("erreur récupération panier: %w", err) } - } - - if totalPrix <= 0 || totalPrix > 100000 { - return nil, fmt.Errorf("montant de commande invalide: %.2f€", totalPrix) - } - - var cmdResult struct { - ID int `gorm:"column:id"` - ClientOrderID int `gorm:"column:client_order_id"` - CreatedAt time.Time `gorm:"column:created_at"` - UpdatedAt time.Time `gorm:"column:updated_at"` - } - err = d.GDB.Raw(` - INSERT INTO commandes (username, status, adresse, total_prix, client_order_id, created_at, updated_at) - VALUES (?, ?, ?, ?, (SELECT COALESCE(MAX(client_order_id), 0) + 1 FROM commandes WHERE username = ?), CURRENT_TIMESTAMP, CURRENT_TIMESTAMP) - RETURNING id, client_order_id, created_at, updated_at`, - username, "pending", deliveryAddress, totalPrix, username).Scan(&cmdResult).Error - if err != nil { - return nil, fmt.Errorf("erreur création commande: %w", err) - } - - commandID := cmdResult.ID - - productIDs2 := make([]int, 0, len(basketItems)) - for _, item := range basketItems { - productIDs2 = append(productIDs2, item.ProductID) - } - productNames2, _ := d.GetProductNamesByIDs(productIDs2) - - batchItems := make([]commandItemFull, 0, len(basketItems)) - for _, item := range basketItems { - productName := productNames2[item.ProductID] - if productName == "" { - productName = fmt.Sprintf("Produit #%d", item.ProductID) + if len(basketItems) == 0 { + return fmt.Errorf("le panier est vide") } - batchItems = append(batchItems, commandItemFull{ - CommandID: commandID, - Produit: productName, - ProductID: item.ProductID, - Quantite: item.Quantity, - Prix: item.Price, - IsReward: item.IsReward, - RewardPoolKey: item.RewardPoolKey, - ClientUsername: username, - ClientNom: clientNom, - ClientPrenom: clientPrenom, - ClientTelephone: clientTelephone, - DeliveryAddress: deliveryAddress, - Status: "pending", - }) - // Stock déjà déduit à l'ajout au panier — ne pas déduire une seconde fois ici. - } - if err := d.InsertCommandItemsBatch(batchItems); err != nil { - log.Printf("❌ Erreur INSERT command_items batch: %v", err) - return nil, fmt.Errorf("erreur insertion items: %w", err) - } - // Décrémenter le stock et vider le panier de manière atomique. - if err := d.GDB.Transaction(func(tx *gorm.DB) error { for _, item := range basketItems { - if item.IsReward { - continue + if item.ProductID <= 0 || item.Quantity <= 0 || item.Price < 0 { + return fmt.Errorf("données panier invalides") } + totalPrix += item.Price + } + + if totalPrix <= 0 || totalPrix > 100000 { + return fmt.Errorf("montant de commande invalide: %.2f€", totalPrix) + } + + var cmdResult struct { + ID int `gorm:"column:id"` + ClientOrderID int `gorm:"column:client_order_id"` + CreatedAt time.Time `gorm:"column:created_at"` + UpdatedAt time.Time `gorm:"column:updated_at"` + } + if err := tx.Raw(` + INSERT INTO commandes (username, status, adresse, total_prix, client_order_id, created_at, updated_at) + VALUES (?, ?, ?, ?, (SELECT COALESCE(MAX(client_order_id), 0) + 1 FROM commandes WHERE username = ?), CURRENT_TIMESTAMP, CURRENT_TIMESTAMP) + RETURNING id, client_order_id, created_at, updated_at`, + username, "pending", deliveryAddress, totalPrix, username).Scan(&cmdResult).Error; err != nil { + return fmt.Errorf("erreur création commande: %w", err) + } + commandID := cmdResult.ID + + productIDs2 := make([]int, 0, len(basketItems)) + for _, item := range basketItems { + productIDs2 = append(productIDs2, item.ProductID) + } + productNames2, _ := d.GetProductNamesByIDs(productIDs2) + + batchItems := make([]commandItemFull, 0, len(basketItems)) + for _, item := range basketItems { + productName := productNames2[item.ProductID] + if productName == "" { + productName = fmt.Sprintf("Produit #%d", item.ProductID) + } + batchItems = append(batchItems, commandItemFull{ + CommandID: commandID, + Produit: productName, + ProductID: item.ProductID, + Quantite: item.Quantity, + Prix: item.Price, + IsReward: item.IsReward, + RewardPoolKey: item.RewardPoolKey, + ClientUsername: username, + ClientNom: clientNom, + ClientPrenom: clientPrenom, + ClientTelephone: clientTelephone, + DeliveryAddress: deliveryAddress, + Status: "pending", + }) + } + if err := tx.Create(&batchItems).Error; err != nil { + return fmt.Errorf("erreur insertion items: %w", err) + } + + // Les articles récompense (payés en points) restent des produits physiques + // réellement distribués : le stock doit être décrémenté comme pour un + // article payant. + for _, item := range basketItems { var currentStock float64 if err := tx.Raw(`SELECT stock FROM products WHERE id = ? FOR UPDATE`, item.ProductID).Scan(¤tStock).Error; err != nil { return fmt.Errorf("erreur lecture stock produit %d: %w", item.ProductID, err) @@ -291,29 +298,33 @@ func (d *Database) CreateCommandWithAddress(username, deliveryAddress string) (* return fmt.Errorf("erreur décrémentation stock produit %d: %w", item.ProductID, err) } } - return tx.Exec(`DELETE FROM baskets WHERE username = ?`, username).Error - }); err != nil { - log.Printf("❌ Erreur décrément stock / vidage panier: %v", err) + if err := tx.Exec(`DELETE FROM baskets WHERE username = ?`, username).Error; err != nil { + return err + } + + command = &models.Command{ + ID: commandID, + ClientOrderID: cmdResult.ClientOrderID, + Username: username, + Status: "pending", + Total: totalPrix, + DeliveryAddress: deliveryAddress, + CreatedAt: cmdResult.CreatedAt, + UpdatedAt: cmdResult.UpdatedAt, + } + return nil + }) + if err != nil { + log.Printf("❌ Erreur création commande: %v", err) return nil, err } sanitizedAddress := sanitizeLogMessage(deliveryAddress) - d.AddCommandLog(commandID, "created", + d.AddCommandLog(command.ID, "created", fmt.Sprintf("Commande créée - Adresse: %s - Total: %.2f€ - Client: %s %s", sanitizedAddress, totalPrix, sanitizeLogMessage(clientNom), sanitizeLogMessage(clientPrenom)), username) - command := &models.Command{ - ID: commandID, - ClientOrderID: cmdResult.ClientOrderID, - Username: username, - Status: "pending", - Total: totalPrix, - DeliveryAddress: deliveryAddress, - CreatedAt: cmdResult.CreatedAt, - UpdatedAt: cmdResult.UpdatedAt, - } - return command, nil } diff --git a/backend/gestion/db/db_stat.go b/backend/gestion/db/db_stat.go index b0c9a9f4..8813e3e9 100644 --- a/backend/gestion/db/db_stat.go +++ b/backend/gestion/db/db_stat.go @@ -190,13 +190,17 @@ func (d *Database) StatsByDayForMonth(rows *[]DailyMonthStatRow, monthStart time return d.GDB.Raw(query, args...).Scan(rows).Error } +// OrdersAndRevenueByHour renvoie, par heure, le nombre de commandes non annulées +// (volume d'activité) et le revenu confirmé (commandes approuvées uniquement — +// cohérent avec TotalRevenue/RevenueByDayLast30, pour ne pas compter comme +// "revenu" une commande encore en cours qui pourrait être annulée). func (d *Database) OrdersAndRevenueByHour(hourRows *[]models.HourRow, resetAt time.Time) error { where, args := statusFilterClause("status != 'cancelled'", resetAt) query := ` SELECT EXTRACT(HOUR FROM created_at)::int AS hour, COUNT(*) AS count, - COALESCE(SUM(total_prix - COALESCE(referral_used, 0)), 0) AS revenue + COALESCE(SUM(CASE WHEN status = 'approved' THEN total_prix - COALESCE(referral_used, 0) ELSE 0 END), 0) AS revenue FROM commandes WHERE ` + where + ` GROUP BY hour @@ -207,6 +211,9 @@ func (d *Database) OrdersAndRevenueByHour(hourRows *[]models.HourRow, resetAt ti // ── Top produits (quantité vendue) ─────────────────────────────────────────── +// TopProducts renvoie les produits les plus commandés. La quantité/le nombre de +// commandes reflètent l'activité (non annulées), le revenu ne compte que les +// commandes approuvées (revenu confirmé, cohérent avec le résumé global). func (d *Database) TopProducts(prodRows *[]models.ProductRow, resetAt time.Time, limit int) error { where, args := statusFilterClause("c.status != 'cancelled'", resetAt) args = append(args, limit) @@ -216,7 +223,7 @@ func (d *Database) TopProducts(prodRows *[]models.ProductRow, resetAt time.Time, ci.produit AS name, SUM(ci.quantite) AS total_quantity, COUNT(DISTINCT ci.command_id) AS order_count, - SUM(ci.prix) AS revenue, + SUM(CASE WHEN c.status = 'approved' THEN ci.prix ELSE 0 END) AS revenue, COALESCE(p.category, '') AS category, COALESCE(cat.color, '#7c3aed') AS category_color FROM command_items ci @@ -233,6 +240,8 @@ func (d *Database) TopProducts(prodRows *[]models.ProductRow, resetAt time.Time, // ── Répartition des doses/quantités par produit ────────────────────────────── +// QuantityBreakdown : quantité/nombre de commandes reflètent l'activité (non +// annulées), le revenu ne compte que les commandes approuvées (revenu confirmé). func (d *Database) QuantityBreakdown(qtyRows *[]models.QuantityBreakdownRow, resetAt time.Time) error { where, args := statusFilterClause("c.status != 'cancelled'", resetAt) query := ` @@ -242,7 +251,7 @@ func (d *Database) QuantityBreakdown(qtyRows *[]models.QuantityBreakdownRow, res ci.quantite AS quantity, COUNT(DISTINCT ci.command_id) AS order_count, SUM(ci.quantite) AS total_sold, - SUM(ci.prix) AS revenue, + SUM(CASE WHEN c.status = 'approved' THEN ci.prix ELSE 0 END) AS revenue, COALESCE(cat.color, '#7c3aed') AS category_color FROM command_items ci JOIN commandes c ON c.id = ci.command_id @@ -257,6 +266,8 @@ func (d *Database) QuantityBreakdown(qtyRows *[]models.QuantityBreakdownRow, res // ── Détail du jour (catégorie → produits) ──────────────────────────────────── +// DailyProductDetail : quantité/nombre de commandes reflètent l'activité (non +// annulées), le revenu ne compte que les commandes approuvées (revenu confirmé). func (d *Database) DailyProductDetail(dailyRows *[]models.DailyProductRow) error { query := ` SELECT @@ -266,7 +277,7 @@ func (d *Database) DailyProductDetail(dailyRows *[]models.DailyProductRow) error COALESCE(cat.color, '#7c3aed') AS category_color, SUM(ci.quantite) AS total_quantity, COUNT(DISTINCT ci.command_id) AS order_count, - SUM(ci.prix) AS revenue + SUM(CASE WHEN c.status = 'approved' THEN ci.prix ELSE 0 END) AS revenue FROM command_items ci JOIN commandes c ON c.id = ci.command_id LEFT JOIN products p ON p.id = ci.product_id @@ -291,7 +302,7 @@ func (d *Database) DailyProductDetailForDate(dailyRows *[]models.DailyProductRow COALESCE(cat.color, '#7c3aed') AS category_color, SUM(ci.quantite) AS total_quantity, COUNT(DISTINCT ci.command_id) AS order_count, - SUM(ci.prix) AS revenue + SUM(CASE WHEN c.status = 'approved' THEN ci.prix ELSE 0 END) AS revenue FROM command_items ci JOIN commandes c ON c.id = ci.command_id LEFT JOIN products p ON p.id = ci.product_id diff --git a/backend/gestion/handlers/crypto_payment.go b/backend/gestion/handlers/crypto_payment.go index 765cfeea..9a4ab89e 100644 --- a/backend/gestion/handlers/crypto_payment.go +++ b/backend/gestion/handlers/crypto_payment.go @@ -15,8 +15,9 @@ import ( // IPNWebhook - POST /api/v1/webhooks/nowpayments func IPNWebhook(c *gin.Context) { database := c.MustGet("database").(*db.Database) - np, ok := c.MustGet("nowpayments").(*services.NowPaymentsClient) - if !ok || np == nil { + npRaw, npExists := c.Get("nowpayments") + np, ok := npRaw.(*services.NowPaymentsClient) + if !npExists || !ok || np == nil { c.JSON(http.StatusServiceUnavailable, gin.H{"error": "paiement crypto non configuré"}) return } diff --git a/backend/gestion/handlers/deleviry.go b/backend/gestion/handlers/deleviry.go index dcf75f78..3e6a74e5 100644 --- a/backend/gestion/handlers/deleviry.go +++ b/backend/gestion/handlers/deleviry.go @@ -272,22 +272,34 @@ func UpdateDeliveryStatus(c *gin.Context) { } } - // Mettre à jour le statut - if err := database.UpdateCommandStatus(commandID, req.Status); err != nil { - c.JSON(http.StatusInternalServerError, gin.H{ - "error": "Erreur mise à jour", - }) - return - } - + // Mettre à jour le statut. + // Le cas "cancelled" passe par une transaction atomique dédiée (transition + + // remboursement stock), pour empêcher tout double remboursement en cas de + // double appel (double-tap, retry réseau, commande déjà annulée ailleurs). if req.Status == "cancelled" { + alreadyCancelled, prevStatus, cancelErr := database.CancelDeliveryByLivreurAtomic(commandID) + if cancelErr != nil { + c.JSON(http.StatusInternalServerError, gin.H{ + "error": "Erreur mise à jour", + }) + return + } + if alreadyCancelled { + c.JSON(http.StatusOK, gin.H{ + "success": true, + "message": "Commande déjà annulée", + "command_id": commandID, + "status": "cancelled", + }) + return + } + cancelMsg := req.Notes if cancelMsg == "" { cancelMsg = "Annulé par le livreur" } database.SetCommandCancelReason(commandID, fmt.Sprintf("[Livreur: %s] %s", usernameStr, cancelMsg)) - prevStatus, _ := command["status"].(string) if prevStatus == "arrived" || prevStatus == "livre" { clientUsername, _ := command["username"].(string) if clientUsername != "" { @@ -298,6 +310,11 @@ func UpdateDeliveryStatus(c *gin.Context) { } } } + } else if err := database.UpdateCommandStatus(commandID, req.Status); err != nil { + c.JSON(http.StatusInternalServerError, gin.H{ + "error": "Erreur mise à jour", + }) + return } // ✅ SI PASSAGE EN "EN_ROUTE" → CALCULER ET DÉFINIR L'ETA @@ -454,15 +471,8 @@ func UpdateDeliveryStatus(c *gin.Context) { database.CompleteDeliveryAndProcessNext(usernameStr, commandID) case "cancelled": + // Transition + remboursement stock déjà effectués atomiquement plus haut. log.Printf("🚫 Livraison annulée par livreur - Nettoyage queue cmd %d", commandID) - prevStatus, _ := command["status"].(string) - if prevStatus == "cancelled" { - log.Printf("⏭️ [STATUS_LIVREUR] Stock NON restitué - commande déjà annulée (cmd %d)", commandID) - } else if err := database.RestoreCommandStock(commandID); err != nil { - log.Printf("⚠️ [STATUS_LIVREUR] Erreur restauration stock cmd %d: %v", commandID, err) - } else { - log.Printf("✅ [STATUS_LIVREUR] Stock restauré pour cmd %d", commandID) - } database.CompleteDeliveryAndProcessNext(usernameStr, commandID) case "arrived": diff --git a/backend/gestion/handlers/panier.go b/backend/gestion/handlers/panier.go index c6119f8c..c8a636ad 100644 --- a/backend/gestion/handlers/panier.go +++ b/backend/gestion/handlers/panier.go @@ -417,8 +417,9 @@ func ValidateBasket(c *gin.Context) { // Vérification option crypto isCrypto := req.PaymentMethod == "crypto" if isCrypto { - np, npOk := c.MustGet("nowpayments").(*services.NowPaymentsClient) - if !npOk || np == nil { + npRaw, npExists := c.Get("nowpayments") + np, npOk := npRaw.(*services.NowPaymentsClient) + if !npExists || !npOk || np == nil { c.JSON(http.StatusServiceUnavailable, gin.H{"error": "Paiement crypto non disponible"}) return }