Périmètre

Data Hub

Ajout de l’option de compression GZIP pour les exports API

Les opérateurs back-office peuvent désormais sélectionner le mode de compression GZIP lors de la configuration d’un job d’export par API.

Dans certains cas, comme l’export de commandes contenant plusieurs centaines de lignes, la taille des données peut devenir conséquente. En activant le mode de compression GZIP, les données sont compressées avant d’être transmises via l’API, ce qui permet de réduire significativement la taille des appels API.

API

📘

NEW

Operations

• Suppression d’accounts d’une Opération (PRIVATE)

Contexte :

Les opérateurs et customer users habilités peuvent désormais retirer un ou plusieurs comptes associés à une opération de type PRIVATE.

Cette évolution permet de révoquer l’accès à une opération ciblée, par exemple lorsqu’un compte ne doit plus bénéficier d’une campagne.

• La suppression n’est possible que pour les opérations :
  • de type PRIVATE,
  • au statut DRAFT.
• L’action est protégée par le Feature Flag OPERATIONS.
  • Opérateur : peut supprimer des comptes de toute opération PRIVATE en DRAFT, sans contrainte de store.
  • Customer User : doit cumuler trois conditions pour supprimer des comptes :
    • droit OPERATIONS_UPDATE = true,
    • être owner de l’opération (ownerId = customerUserId),
    • être rattaché au store effectif (dj-store si fourni, sinon store par défaut du tenant).

Fonctionnement métier :

• Les IDs fournis doivent correspondre à des accounts déjà liés à l’opération.
• Les accounts inconnus ou non liés sont ignorés ; si aucun des accounts fournis n’est valide, une erreur est renvoyée.
• Une opération de type PUBLIC n’accepte jamais de suppression d’accounts (cas rejeté).

API correspondante :

🗑️ Suppression d’accounts d’une opération PRIVATE

ADM-OPERATION-351 - DELETE /operations/{operationId}/accounts

[
  "acc_123",
  "acc_456"
]

Buying Policies

• Validation forcée d’un blocage de commande

Contexte :

Les opérateurs de la plateforme peuvent désormais forcer manuellement la validation d’une commande bloquée par une ou plusieurs buying policies (encours, quotas).

Cette évolution permet de reprendre le traitement d’une commande bloquée lorsque les conditions initiales ne peuvent être satisfaites automatiquement, tout en conservant une traçabilité complète des actions opérateur.

Fonctionnement métier :

• Seules les commandes au statut BLOCKED_BY_POLICY peuvent être forcées. (Ceci exclut pour le moment les buying policies de validation manuelle historiques).
• Une commande bloquée par plusieurs policies n’est débloquée que si plus aucune ne s’applique.
• Le statut évolue de BLOCKED_BY_POLICY → WAITING_SUPPLIER_APPROVAL une fois la validation forcée acceptée.
• Chaque action de forçage est enregistrée avec la date, l’auteur et la policy concernée.
• Le processus reste auditables via un endpoint d’historique dédié.

Exemple : une commande bloquée par la policy de quota peut être validée manuellement si l’opérateur décide d’autoriser exceptionnellement son envoi au fournisseur.

API correspondante :

✅ Forcer la validation d’une ou plusieurs commandes bloquées

ADM-ORDER-150 - POST /v1/logistic-orders/unblock

{
  "orderIds": ["ORD-12345", "ORD-67890"]
}

🔍 Consulter l’historique des validations forcées

ADM-ORDER-550 - GET /v1/logistic-orders/{logisticOrderId}/unblock-history

{
  "actions": [
    {
      "forcedAt": "2025-06-19T15:32:00Z",
      "forcedBy": {
        "userId": "USR-456",
        "fullName": "Alice Martin"
      },
      "buyingPolicy": "CREDIT_CONTROL"
    },
    {
      "forcedAt": "2025-06-20T09:10:00Z",
      "forcedBy": {
        "userId": "USR-789",
        "fullName": "Marc Dubois"
      },
      "buyingPolicy": "QUOTA"
    }
  ]
}