Djust 3.83.0 - Semaine du 15 Sept 2025

Périmètre

BackOffice Djust

Configuration de nouveaux rôles pour la configuration des Buying Policies

Deux nouveaux rôles ont été ajoutés pour gérer les configuration de Buying Policies de quotas et d'encours :

  • Rôle de gestion de quota minimum pour un fournisseur associé à un CF de type number
  • Rôle de gestion des limites de crédit et d'encours pour un compte client associé à des CF de type number.

API

📘

NEW

Operations

  • Création d'une Opération

Contexte :

Les utilisateurs peuvent désormais créer une nouvelle opération (campagne commerciale ou organisationnelle) directement via l’API.

Cette action permet d’initialiser une opération en statut DRAFT, sans produits ni comptes associés, en amont de toute configuration (variants, accounts, prix…).

  • La visibilité (PRIVATE ou PUBLIC) est définie à la création et n’est pas modifiable par la suite.
  • Le créateur de l’opération (ownerId) est automatiquement enregistré et sera le seul à pouvoir la modifier côté compte client (hors opérateur).
  • La création est protégée par le feature flag OPERATIONS.
  • L’internationalisation est supportée via les locales autorisées du store (IETF BCP 47). La locale par défaut du store (ou du tenant si le store n’en définit pas) doit obligatoirement être présente.

Fonctionnement métier :

  • Opérateur (dj-client: OPERATOR) : peut toujours créer une opération, quel que soit le store.
  • Customer User (dj-client: ACCOUNT) :
    • doit disposer du droit OPERATIONS_CREATE = true,
    • ne peut créer que sur un store auquel il est rattaché (ou le store par défaut du tenant).
  • À la création, le statut de l’opération est toujours DRAFT.

API correspondante :

➕ Créer une opération

ADM-OPERATION-100 - POST /operations

{
  "externalId": "SUMMER_OPE_0825",
  "type": "PRIVATE",
  "names": {
    "en-GB": "Summer Operation",
    "fr-FR": "Opération Été"
  },
  "descriptions": {
    "en-GB": "Summer Operation · Fine Food",
    "fr-FR": "Opération Été · Produits raffinés"
  },
  "startDate": "2025-11-21T00:00:00Z",
  "endDate": "2025-11-28T23:59:59Z"
}
{
  "id": "ope_1234"
}

  • Ajout et modification des variants d’une Opération

Contexte :

Il est désormais possible, pour les opérateurs et les customer users habilités, d’ajouter des variants à une opération et/ou de modifier les quantités associées (minQuantity, maxQuantity, recommendedQuantity).

Cette évolution permet d’ajuster les contraintes d’achat avant la publication d’une opération.

Fonctionnement métier :

  • Ajout : un variant ne peut être associé qu’une seule fois à une opération.
  • Mise à jour : possible en masse, chaque ligne correspondant à un variantId externe.
  • Validation des quantités :
    • minQuantity ≥ 0 (facultatif, permet de rendre l’achat obligatoire si > 0),
    • maxQuantity ≥ minQuantity (si défini),
    • recommendedQuantity ∈ [minQuantity, maxQuantity] si maxQuantity est défini, sinon ≥ minQuantity.

API correspondante :

✏️ Modification des variants d’une opération

ADM-OPERATION-250 - PUT /operations/{operationId}/lines

[
  {
    "variantId": "VAR-001",
    "minQuantity": 2,
    "maxQuantity": 12,
    "recommendedQuantity": 6
  },
  {
    "variantId": "VAR-002",
    "minQuantity": 0,
    "recommendedQuantity": 0
  }
]

  • Ajout d’accounts à une Opération (PRIVATE)

Contexte :

Il est désormais possible d’ajouter des comptes à une opération de type PRIVATE, afin de restreindre sa visibilité uniquement aux accounts explicitement autorisés.

  • Cette action est réservée aux opérations en statut DRAFT et de type PRIVATE.

API correspondante :

➕ Ajout d’accounts à une opération

ADM-OPERATION-251 - PUT /operations/{operationId}/accounts

[
  "ACC-001",
  "ACC-002",
  "ACC-XYZ"
]

  • Récupération des accounts d’une Opération (PRIVATE)

Contexte :

Les opérateurs et les customer users habilités peuvent désormais consulter la liste des comptes associés à une opération PRIVATE.

Cette évolution permet de contrôler qui a accès à une opération restreinte, afin de sécuriser la diffusion des campagnes commerciales ou organisationnelles.

Fonctionnement métier :

  • Les résultats peuvent être filtrés par accountIds (externalIds uniquement) et/ou accountName (recherche partielle, insensible à la casse).
  • Le tri par défaut est effectué sur accountName dans le sens ASC.
  • Autres tris possibles : accountName, accountId.

API correspondante :

🔍 Récupérer les accounts liés à une opération

ADM-OPERATION-552 - GET /operations/{operationId}/accounts

{
  "accounts": [
    {
      "accountId": "ACC-001",
      "accountName": "Store #1 Rennes"
    },
    {
      "accountId": "ACC-002",
      "accountName": "Store #2 Nantes"
    }
  ]
}

  • Récupération des variants d’une Opération

Contexte :

Les opérateurs et les customer users habilités peuvent désormais consulter la liste des variants associés à une opération, avec leurs quantités configurées (minQuantity, maxQuantity, recommendedQuantity).

  • Cette route permet de contrôler le contenu d’une opération et de préparer sa modification ou son utilisation.

Fonctionnement métier :

  • Filtres disponibles :
    • variantIds (externalIds uniquement, valeurs inconnues ignorées)
    • variantName (recherche exacte ou partielle, insensible à la casse, dans la locale effective)
    • minQuantity, maxQuantity, recommendedQuantity (recherche exacte)
  • Paramètre locale : permet de définir la langue de recherche et de tri pour variantName (fallback sur la locale par défaut du store si inconnue).
  • Tri :
    • Par défaut sur variantId:asc.
    • Champs supportés : variantId, variantName, minQuantity, maxQuantity, recommendedQuantity.

API correspondante :

🔍 Récupération des variants d’une opération

ADM-OPERATION-551 - GET /operations/{operationId}/lines

{
  "lines": [
    {
      "variantId": "VAR-001",
      "variantName": "Black shirt",
      "minQuantity": 2,
      "maxQuantity": 10,
      "recommendedQuantity": 4
    },
    {
      "variantId": "VAR-002",
      "variantName": "White shirt",
      "minQuantity": 0,
      "maxQuantity": 5,
      "recommendedQuantity": 1
    }
  ]
}

  • Récupération des Opérations existantes (liste)

Contexte :

Les équipes Opérations et Sales peuvent désormais consulter la liste des Opérations (campagnes) via une route d’administration unique.

L’accès est contrôlé (owner, droits, store) et filtrable (statut, nom, dates, type…), afin de retrouver rapidement une opération, vérifier son statut et l’ouvrir pour suivi/édition.

Fonctionnement métier :

  • Visibilité opérateur (dj-client: OPERATOR)
    • Voit toutes les opérations.
    • Si dj-store est fourni → résultats restreints à ce store.
    • Si dj-store est absent → résultats restreints au store par défaut du tenant.
  • Visibilité customer user (dj-client: ACCOUNT)
    • Ne voit que ses propres opérations (ownerId = customerUserId) et uniquement si le droit OPERATIONS_READ = true.
    • Doit être rattaché au store demandé :
      • Si dj-store est fourni → le caller doit être attaché à ce store.
      • Si dj-store est absent → fallback sur le store par défaut du tenant ; le caller doit y être attaché.
    • Locales
      • Le paramètre locale (optionnel) détermine la langue des champs localisés (name).
      • La locale doit faire partie des locales autorisées du store de l’opération ; sinon, fallback sur la locale par défaut du store.

API correspondante :

🔍 Lister les opérations

ADM-OPERATION-550 - GET /operations

{
  "operations": [
    {
      "id": "ope_001",
      "externalId": "SUMMER_OPE_0825",
      "name": "Summer Operation · Fine Food",
      "type": "PRIVATE",
      "status": "ACTIVE",
      "startDate": "2025-11-21T00:00:00Z",
      "endDate": "2025-11-28T23:59:59Z",
      "createdAt": "2025-08-04T12:34:56Z",
      "updatedAt": "2025-08-05T10:00:00Z",
      "ownerId": "usr_987",
      "ownerFirstName": "Alice",
      "ownerLastName": "Durand"
    }
  ]
}