BCard - Documentation technique

Refuse l'opération si l'utilisateur n'est rattaché à aucune entreprise. Si le compte est déjà activé, la méthode sort en succès avec un message spécifique et sans écriture en base. Sinon l'indicateur activated passe à true et la modification est persistée. Aucun email n'est envoyé à l'utilisateur concerné.

Voir aussi UserApiController::activateBusiness(), qui expose une action équivalente sous un autre préfixe de route.

Route : /api/admin/users/{id}/activate-business (POST), nom api_admin_activate_business. Requiert ROLE_ADMIN.

Réponses : 200 compte activé, 200 compte déjà activé (message distinct), 400 utilisateur sans entreprise rattachée, 404 utilisateur inexistant, 403 appelant sans ROLE_ADMIN, 401 requête non authentifiée.

Exécute une série de comptages indépendants : nombre total d'utilisateurs, comptes disposant d'une entreprise (company IS NOT NULL), comptes activés, et inscriptions depuis le premier jour du mois courant. Côté commandes, les statuts « en attente », « terminée » et « annulée » sont comptés séparément. Le chiffre d'affaires est calculé comme la somme des montants des paiements aux statuts completed ou accepted, avec un COALESCE pour couvrir l'absence de résultat, puis formaté à deux décimales. Les paiements sont ventilés en total, complétés, en attente et rejetés ; le catalogue est ventilé en cartes visibles et masquées. Aucune période n'est appliquée hors du compteur mensuel.

Route : /api/admin/dashboard (GET), nom api_admin_dashboard. Requiert ROLE_ADMIN.

Réponses : 200 statistiques renvoyées, 403 appelant sans ROLE_ADMIN, 401 requête non authentifiée.

Positionne l'indicateur activated à false et persiste la modification, sans vérifier au préalable que l'utilisateur possède effectivement une entreprise ni qu'il était activé : l'opération est donc idempotente et applicable à tout compte. Aucun email n'est envoyé.

Route : /api/admin/users/{id}/deactivate-business (POST), nom api_admin_deactivate_business. Requiert ROLE_ADMIN.

Réponses : 200 compte désactivé, 404 utilisateur inexistant, 403 appelant sans ROLE_ADMIN, 401 requête non authentifiée.

page est ramené à 1 au minimum et limit est borné à l'intervalle [1, 100] (défaut 20) ; le filtre status n'est appliqué que s'il est fourni et non vide, sans validation de la valeur transmise. Les résultats sont triés par created_at décroissant. Le bloc user vaut null pour les commandes passées sans compte, et la charge utile inclut les informations de suivi (tracking_number, shipping_carrier, shipped_at, delivered_at) absentes du schéma OpenApi. Les lignes de commande ne sont pas incluses.

Route : /api/admin/orders (GET), nom api_admin_orders_list. Requiert ROLE_ADMIN.

Paramètres de requête : status (optionnel), page (optionnel, défaut 1), limit (optionnel, défaut 20, plafonné à 100).

Réponses : 200 liste renvoyée, 403 appelant sans ROLE_ADMIN, 401 requête non authentifiée.

Le statut transmis doit appartenir à la liste blanche des constantes de Order (« en attente », « en traitement », « terminée », « remboursée », « annulée »). Aucune transition d'état n'est contrôlée : n'importe quel statut valide peut succéder à n'importe quel autre, et les champs d'annulation ou d'expédition ne sont pas mis à jour. Après persistance, un email de notification est envoyé via MailerService::sendOrderStatusUpdate() ; un échec d'envoi est seulement journalisé par error_log() et ne modifie pas la réponse renvoyée.

Route : /api/admin/orders/{id}/status (PUT), nom api_admin_update_order_status. Requiert ROLE_ADMIN.

Corps attendu : {"status": "string — obligatoire, valeur parmi les statuts autorisés"}

Réponses : 200 statut mis à jour, 400 clé status absente, 400 statut hors liste autorisée, 404 commande inexistante, 403 appelant sans ROLE_ADMIN, 401 requête non authentifiée.

page est ramené à 1 au minimum et limit est borné à l'intervalle [1, 100] (défaut 20). Le drapeau business_only, lu comme booléen, ajoute un critère business = true sur le dépôt. Les résultats sont triés par created_at décroissant. Pour chaque utilisateur, le nombre de commandes et d'employés est obtenu en comptant les collections associées, ce qui provoque autant de chargements que d'utilisateurs retournés. La charge utile réelle renvoie name et email_verified là où le schéma OpenApi déclare firstname, lastname et created_at.

Route : /api/admin/users (GET), nom api_admin_users_list. Requiert ROLE_ADMIN.

Paramètres de requête : page (optionnel, défaut 1), limit (optionnel, défaut 20, plafonné à 100), business_only (optionnel, booléen).

Réponses : 200 liste renvoyée, 403 appelant sans ROLE_ADMIN, 401 requête non authentifiée.