Périmètre

🖥️ Back-Office

Emails dédiés aux utilisateurs du Back-Office

Contexte

Les emails adressés aux opérateurs et aux fournisseurs du Back-Office réutilisaient les templates prévus pour les clients du storefront. Un opérateur nouvellement créé recevait ainsi un contenu destiné à un client, avec un lien d'activation inopérant, et la configuration de ces envois n'était pas pilotable depuis le Back-Office.

Fonctionnement

Deux templates dédiés aux utilisateurs du Back-Office sont ajoutés :

• Création d'un opérateur — contenu adapté à un opérateur, sans lien d'activation.
• Réinitialisation du mot de passe (Back Office) — servi aux opérateurs et aux fournisseurs, activé par défaut.

Chacun s'active, se désactive et se personnalise depuis le templater d'emails, comme n'importe quel autre email de la plateforme.

Les templates storefront correspondants restent inchangés : un utilisateur client qui reçoit ses accès ou réinitialise son mot de passe obtient toujours le même email, dans la locale de son store view.

Rétrocompatibilité assurée sur les tenants existants : l'état d'activation et les contenus personnalisés sont repris sur les nouveaux templates, aucun email ne se met à partir ni ne cesse de partir.

📄 Documentation : Email templater

👉 Côté métier : le contenu reçu par un opérateur ou un fournisseur se règle indépendamment de celui envoyé aux clients, et chaque email du Back-Office s'active ou se coupe sans effet de bord sur le storefront.

👉 Côté technique : deux nouveaux templates de portée back-office, new-operator-user-creation et reset-password-bo, exposés par l'API des templates d'email au même titre que les templates existants.

Configuration par store view de la confirmation de commande logistique

Contexte

L'email de confirmation de commande logistique part sur le store view de la commande, mais sa configuration n'était proposée qu'au niveau global : le réglage affiché dans le Back-Office ne pilotait aucun envoi.

Fonctionnement

Cet email se configure désormais par store view et par locale, comme les autres emails adressés aux clients : activation, sujet et contenu se règlent pour chaque store view.

Aucun changement d'envoi sur les tenants existants : les réglages par store view, qui gouvernaient déjà les envois, restent ceux qui décident.

📄 Documentation : Email templater

👉 Côté métier : l'activation et le contenu de la confirmation de commande logistique se pilotent réellement, store view par store view et langue par langue.

👉 Côté technique : le template passe en portée storefront ; sa configuration globale, sans effet sur les envois, est retirée.

Filtres sur les champs personnalisés des comptes

Contexte

Les listes de produits et d'offres se filtrent déjà sur les champs personnalisés. Ce n'était pas le cas de la liste des comptes : un champ personnalisé créé sur le compte — pour marquer les comptes actifs sur la plateforme, par exemple — ne pouvait pas servir de critère de recherche.

Fonctionnement

La liste des comptes se filtre désormais sur les champs personnalisés définis sur l'entité compte, au même titre que sur les produits et les offres. Les filtres existants restent disponibles et se combinent avec les nouveaux.

👉 Côté métier : les comptes se segmentent sur les informations propres à chaque client — statut d'usage, appartenance à un réseau, typologie — sans export ni retraitement.

👉 Côté technique : les champs personnalisés configurés sur l'entité compte deviennent des critères de filtrage de la liste des comptes.

🛠️ API

Import contextuel depuis les pages liste

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

Contexte

Charger un fichier sur une entité déjà cartographiée imposait de repasser par la configuration complète d'un import Data Hub. Les API nécessaires au lancement d'un import depuis la page liste d'une entité sont désormais disponibles.

Fonctionnement

Deux parcours sont couverts :

• Nouveau mapping — un import de type fichier est créé avec le mapping défini, puis exécuté avec le fichier déposé.
• Mapping existant — l'import correspondant est mis à jour avec le mapping ajusté, puis exécuté. Aucun import n'est dupliqué et son nom reste inchangé.

Le nom d'un import est unique sur le tenant, quelle que soit l'entité importée ou la source qui l'alimente : un nom déjà pris est refusé.

Un import ne porte qu'une exécution à la fois. Tant qu'une exécution est en cours, son lancement est refusé, et ni le mapping ni le fichier attaché ne sont modifiés. Des imports distincts s'exécutent en parallèle, y compris sur une même entité.

Les imports créés apparaissent dans la liste des imports Data Hub et bénéficient du monitoring et de l'historique standard.

Impact API

GET /v2/mapper/jobs (operationId : ADM-JOB-552) — recherche paginée des jobs d'import, filtrable par entité (genericJobType) et par type de connecteur (clientConfigurationType).

PATCH /v2/mapper/jobs/{jobId} (operationId : ADM-JOB-200) — accepte readerConfiguration, qui remplace le mapping du job dans son ensemble (colonnes, délimiteur et en-tête ensemble). Retourne 200 avec le job mis à jour, 409 lorsque le nom est déjà porté par un autre job ou que la source d'un job en cours d'exécution serait modifiée.

POST /v2/mapper/jobs (operationId : ADM-JOB-101) — 409 lorsque le nom est déjà utilisé, aucun job n'est alors créé.

GET /v1/mapper/jobs/start/{jobId} (operationId : ADM-JOB-501) — démarrage de l'exécution avec le fichier attaché.

📄 Documentation : Job Configuration - Import - File

👉 Côté métier : le socle est en place pour lancer un import de fichier depuis la page de l'entité concernée, en réutilisant et en ajustant un mapping déjà défini plutôt qu'en le reconfigurant à chaque fois.

👉 Côté technique : nouvelle route de recherche des jobs d'import, remplacement du mapping par readerConfiguration, et conflits explicites en 409 sur l'unicité du nom et sur la modification de la source d'un job en cours d'exécution.

Frais de transaction par capture

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

Contexte

Sur une marketplace, les frais de transaction prélevés à chaque capture n'étaient consultables que dans les rapports du prestataire de paiement, sans rattachement aux événements de transaction de la plateforme.

Fonctionnement

Les frais de transaction de chaque capture sont désormais prélevés sur le balance account de la marketplace et restitués sur l'événement de transaction correspondant.

La commission de la marketplace reste exprimée en brut : aucun montant net n'est calculé à partir de ces frais. Le montant reste vide tant que le prestataire ne l'a pas arrêté.

Impact API

GET /v1/transactions/events/{eventId} (operationId : ADM-TRANSACTION-552)

Nouveau champ transactionFees dans les montants de l'événement : frais de transaction imputés au balance account de la marketplace pour cette capture. Champ nullable, restitué aux appelants dj-client: OPERATOR uniquement.

📄 Documentation : Event details

👉 Côté métier : le coût réel de chaque capture est connu capture par capture, sans passer par les rapports du prestataire de paiement.

👉 Côté technique : nouveau champ transactionFees sur le détail d'un événement de transaction, nullable tant que les frais ne sont pas arrêtés, et réservé aux opérateurs.