Périmètre

🖥️ Back-Office

Gestion des groupes et des rôles — module ouvert aux clients

Contexte

La gestion des groupes et des permissions était réservée aux équipes DJUST : page sans point d'entrée, matrice des droits illisible et aucune trace des modifications.

Fonctionnement

La page « Groupes & rôles » est disponible sur tous les tenants, depuis les paramètres du Back-Office, pour les utilisateurs ayant la permission de consultation des groupes et rôles.

• Matrice lisible : permissions regroupées par entité métier en sections repliables, intitulés fonctionnels sans code technique, confirmation avant tout enregistrement.
• Consulter ou modifier : la modification relève d'un rôle dédié, distinct de la consultation. Sans ce rôle, la page et le champ groupe des fiches utilisateur sont en lecture seule.
• Groupes Opérateur, Compte et Fournisseur gérés au même endroit, avec renommage et un sélecteur d'ajout unique qui affiche le fournisseur ou le compte de rattachement de chaque utilisateur.
• Jamais sans groupe : le retrait d'un membre demande confirmation et impose un groupe de destination si c'était son seul groupe.
• Historique : onglet listant qui a ajouté ou retiré quelle permission ou quel utilisateur, et quel groupe a été créé, renommé ou supprimé, avec filtres par groupe, auteur, période et action.

À l'activation : seuls les membres du groupe d'administration Operator_Admin de chaque tenant, existant ou nouveau, détiennent le rôle de modification. Les autres utilisateurs ayant la permission de consultation voient la page en lecture seule. L'administrateur délègue ensuite ce rôle aux groupes de son choix depuis la page elle-même.

📄 Documentation : Rôle Utilisateur

👉 Côté métier : un administrateur client gère lui-même les groupes, les membres et les permissions de ses utilisateurs, avec une traçabilité complète.

👉 Côté technique : module basé sur les routes documentées de gestion des groupes, des rôles et de leur historique ; le contrôle des deux niveaux de droits est appliqué côté API.

🛠️ API

Matrice de frais de livraison — frais par défaut pour les fournisseurs non configurés

🚧 API uniquement pour le moment. L'interface Back-Office associée arrivera dans une prochaine version.

Contexte

En contexte marketplace, chaque ligne de la matrice de frais de livraison cible un fournisseur précis. Un fournisseur sans ligne pour la combinaison famille logistique / zone / type de livraison demandée n'a pas de prix, et le checkout du client est bloqué. Il fallait donc créer une ligne par fournisseur et recommencer à chaque nouvel entrant sur la marketplace.

Fonctionnement

Une ligne de la matrice peut désormais porter des frais de livraison par défaut (« Default shipping fee »), sans fournisseur :

• Elle s'applique à tout fournisseur qui n'a pas sa propre ligne pour la même combinaison famille logistique / zone / type de livraison, y compris un fournisseur créé après coup, sans retoucher la matrice.
• La ligne propre d'un fournisseur reste toujours prioritaire : les frais par défaut n'interviennent que là où aucun prix n'existait.
• Une ligne cible soit un fournisseur, soit tous les autres : une ligne portant à la fois un fournisseur et le caractère par défaut est refusée, de même qu'une ligne sans l'un ni l'autre.
• Une seule ligne par défaut est admise par combinaison, à la création comme à la modification, y compris en chargement en masse.
• Prix, franco, découpage du panier et calcul des frais se comportent comme pour une ligne classique.

Le filet se pose combinaison par combinaison : une combinaison sans ligne fournisseur ni ligne par défaut reste bloquante, comme avant. Les lignes existantes conservent leur comportement.

Impact API

• POST /v1/shipping-prices (operationId : ADM-SHIPPING-PRICE-150) et PUT /v1/shipping-prices (operationId : ADM-SHIPPING-PRICE-250) : le caractère « Default shipping fee » se renseigne à la création et à la modification, sans supplierId.
• GET /v1/shipping-prices (operationId : ADM-SHIPPING-PRICE-550) et GET /v1/shipping-prices/{id} (operationId : ADM-SHIPPING-PRICE-500) : une ligne par défaut se distingue sans ambiguïté d'une ligne fournisseur.
• Les refus (ligne à la fois fournisseur et par défaut, ligne sans cible, doublon de ligne par défaut sur une combinaison) renvoient une erreur fonctionnelle identifiable.

📄 Documentation : Shipping Rates configuration

👉 Côté métier : une ligne de frais par défaut, à 0 ou au prix de votre choix, garantit qu'aucun fournisseur non configuré ne bloque plus un checkout sur les combinaisons couvertes.

👉 Côté technique : les routes de gestion des frais de livraison acceptent et exposent une ligne sans fournisseur marquée par défaut, résolue au calcul des frais après la ligne propre du fournisseur.

Incidents — modification du statut d'un incident et de ses lignes

🚧 API uniquement pour le moment. L'interface Back-Office associée arrivera dans une prochaine version.

Contexte

Le statut d'un incident n'était modifiable par aucune API : fixé à « ouvert » lors de la déclaration par le client sur le site marchand, il n'évoluait que par un import Data Hub depuis l'ERP. Un opérateur qui traitait un incident ne pouvait pas le faire avancer, et sur un tenant sans retour ERP tous les incidents restaient ouverts indéfiniment.

Fonctionnement

Un opérateur ou un utilisateur fournisseur peut désormais modifier :

• le statut de l'incident : ouvert, en cours ou clos ;
• le statut de chacune des lignes concernées, lorsque l'incident porte sur des lignes de commande.

Règles :

• Les deux statuts sont indépendants : clore un incident ne clôt pas ses lignes, et inversement.
• Toutes les transitions sont autorisées dans les deux sens ; un incident ou une ligne clos peut être rouvert.
• Le statut est purement informatif : aucun fil de discussion n'est fermé, aucune notification n'est envoyée, aucune quantité n'est libérée et la commande logistique n'est pas modifiée.
• Un utilisateur fournisseur n'agit que sur les incidents de ses propres commandes.
• Une valeur de statut inconnue est refusée avec une erreur fonctionnelle listant les valeurs acceptées.
• L'auteur et la date de chaque changement sont conservés.

L'import Data Hub continue de mettre à jour les deux statuts comme aujourd'hui.

Impact API

Nouvelle route d'administration de mise à jour du statut d'un incident et de ses lignes, ouverte aux typologies OPERATOR et SUPPLIER avec le droit de modification des commandes (ORDER_UPDATE), comme la mise à jour d'une commande logistique (ADM-ORDER-201). Le contrat détaillé est publié dans la référence Admin API.

📄 Documentation : Order Incident Management (Order & Order Line)

👉 Côté métier : le traitement d'un incident peut être suivi jusqu'à sa clôture depuis vos outils, sans dépendre d'un retour ERP.

👉 Côté technique : nouvelle route de mise à jour des statuts d'incident et de lignes d'incident, sans automate d'état ni effet de bord, traçable par auteur et date.

Liste des commandes logistiques — filtre par statut d'incident

🚧 API uniquement pour le moment. L'interface Back-Office associée arrivera dans une prochaine version.

Contexte

La liste des commandes logistiques ne permettait de filtrer que sur « avec incident » / « sans incident ». Impossible de savoir où en était le traitement, et donc de retrouver les commandes dont un incident est encore ouvert.

Fonctionnement

La recherche des commandes logistiques accepte un filtre sur le statut des incidents : ouvert, en cours, clos, à choix multiple.

• Une commande remonte dès qu'un seul de ses incidents porte l'un des statuts demandés. Une commande portant un incident clos et un incident ouvert remonte donc sur « clos » comme sur « ouvert ».
• Seul le statut de l'incident est évalué, jamais celui de ses lignes.
• Les incidents sur commande entière et sur lignes sont traités de la même façon.
• Le filtre se combine avec tous les filtres existants. Un utilisateur fournisseur ne voit remonter que ses propres commandes.

Le filtre « avec / sans incident » existant est conservé. Il repose sur l'indicateur d'alerte de la commande, qui s'allume aussi lors d'une simple discussion client : il remonte donc plus de commandes que la somme des statuts d'incident.

Impact API

POST /v1/logistic-orders (operationId : ADM-ORDER-551) : nouveau critère de filtre sur les statuts d'incident dans le corps de la recherche. Les critères existants sont inchangés.

📄 Documentation : Search, Filter & Sort Logistic Orders

👉 Côté métier : retrouvez en une requête les commandes dont un incident est encore ouvert ou en cours de traitement.

👉 Côté technique : critère de filtre multi-valeurs sur le statut d'incident, ajouté au corps de la recherche des commandes logistiques, combinable avec les critères existants.

Incidents — consultation ouverte aux utilisateurs fournisseurs, limitée à leurs commandes

🚧 API uniquement pour le moment. L'interface Back-Office associée arrivera dans une prochaine version.

Contexte

Un utilisateur fournisseur voyait le pictogramme « Incident déclaré » sur ses commandes sans pouvoir consulter l'incident : la liste et le détail des incidents étaient réservés aux opérateurs. Il pouvait pourtant déjà lire et répondre au fil de discussion d'un incident, sans moyen d'en récupérer l'identifiant.

Fonctionnement

• Un utilisateur fournisseur peut lister et consulter les incidents portant sur les commandes dont il est le fournisseur.
• Le périmètre est imposé par le serveur à partir du fournisseur rattaché à l'utilisateur connecté : les incidents des autres fournisseurs sont invisibles en liste, et un accès direct est refusé, même en filtrant explicitement sur un autre fournisseur.
• Le contenu renvoyé est identique à celui reçu par un opérateur pour le même incident.

Rien ne change pour les opérateurs : ils continuent de voir tous les incidents du tenant, avec les mêmes filtres, tris et pagination.

Impact API

• GET /v1/incidents (operationId : ADM-INCIDENT-550) et GET /v1/incidents/{incidentId} (operationId : ADM-INCIDENT-500) acceptent désormais dj-client: SUPPLIER, avec restriction automatique aux commandes du fournisseur de l'utilisateur.
• Aucun changement de contrat de réponse.

📄 Documentation : Order Incident Management (Order & Order Line)

👉 Côté métier : un fournisseur dispose d'un parcours complet sur les incidents de ses commandes : les retrouver, les consulter, échanger avec le client et faire évoluer leur statut.

👉 Côté technique : les routes de lecture des incidents sont ouvertes à la typologie SUPPLIER avec un périmètre déduit côté serveur, non paramétrable par l'appelant.

Liste des commandes logistiques — tri par nom de fournisseur et recherche par numéro insensible à la casse

Contexte

Sur la liste des commandes logistiques, seul un filtre par fournisseur existait : impossible de trier une liste paginée par nom de fournisseur sans charger toutes les commandes côté navigateur. Par ailleurs, la recherche par numéro de commande était sensible à la casse : test-224 ne remontait pas la commande TEST-224, alors que les filtres sur custom field ignoraient déjà la casse.

Fonctionnement

• Tri par nom de fournisseur : nouvelle clé de tri supplierName, insensible à la casse et aux accents. Les commandes sans fournisseur sont placées en fin de liste dans les deux sens. La clé se combine avec les autres clés de tri dans l'ordre reçu, y compris une clé cf.<identifier>.
• Recherche par numéro : le critère orderIdentifier ignore désormais la casse sur la référence, l'identifiant externe et l'identifiant métier. La recherche partielle est conservée.

Les deux évolutions s'appliquent à la liste storefront comme à la liste d'administration. Elles ne peuvent qu'élargir les résultats : aucun appel existant n'est cassé.

Impact API

• POST /v1/shop/logistic-orders (operationId : ORDER-550) et POST /v1/logistic-orders (operationId : ADM-ORDER-551).
• Paramètre sort : nouvelle valeur acceptée supplierName (alias supplier_name), par exemple sort=supplierName,asc. Ajout non-breaking.
• Champ orderIdentifier du corps de la recherche : comparaison insensible à la casse, aucun changement de contrat.

📄 Documentation : Search, Filter & Sort Logistic Orders

👉 Côté métier : un acheteur regroupe ses commandes par fournisseur sur une liste paginée et retrouve une commande par son numéro quelle que soit la casse saisie.

👉 Côté technique : nouvelle clé de tri supplierName sur les listes storefront et administration, et critère orderIdentifier insensible à la casse, sans changement de contrat.

Liste des groupes d'utilisateurs — suppression du champ numberOfUsers

Contexte

Le champ numberOfUsers renvoyé pour chaque groupe par la liste complète des groupes d'utilisateurs exigeait un comptage des membres de chaque groupe à chaque appel. Ce calcul représentait l'essentiel du temps de réponse de la route et ralentissait la page « Rôles & groupes » du Back-Office.

Fonctionnement

Le champ numberOfUsers n'est plus renvoyé par la liste des groupes. Le nombre d'utilisateurs d'un groupe reste disponible via le total de la liste des utilisateurs de ce groupe.

Impact API

• GET /v2/user-groups (operationId : ADM-USER-GROUP-552) : le champ numberOfUsers est supprimé de chaque élément de la réponse. Action requise : les intégrations qui lisent ce champ doivent cesser de s'y appuyer.
• Pour obtenir le nombre d'utilisateurs d'un groupe : GET /v2/user-groups/{groupId}/users (operationId : ADM-USER-GROUP-554), total de la réponse paginée.

📄 Documentation : Rôle Utilisateur

👉 Côté métier : la liste des groupes répond nettement plus vite, quel que soit le nombre de groupes du tenant.

👉 Côté technique : suppression du champ numberOfUsers de GET /v2/user-groups ; le comptage par groupe passe par la liste paginée des utilisateurs du groupe.