Périmètre

🖥️ Back-Office

📘
NEW

Templates d'email par défaut et templates Back-Office dans l'éditeur d'emails

Contexte

Jusqu'ici, l'envoi des emails reposait exclusivement sur des templates custom hébergés sur S3 : sans upload manuel, aucun email n'était envoyé. Par ailleurs, les emails Back-Office (notifications d'export, échec de job, confirmation de commande logistique, etc.) n'étaient ni visibles ni configurables depuis le Back Office.

Fonctionnement

Chaque store dispose désormais de templates d'email par défaut. Un feature flag global contrôle l'activation des emails par défaut (désactivé = comportement actuel) ; l'activation en production fera l'objet d'une release ultérieure.
Chaque template peut être activé ou désactivé depuis le Back Office.
Les 7 templates Back-Office apparaissent désormais dans l'éditeur de templates d'email (product-export-download, offer-export-download, order-export-success, pay-export-download, new_job_execution_failed, logistic-order-confirmation, update-supplier-quote).
Ces templates Back-Office sont globaux à la plateforme : l'édition du contenu s'appliquent globalement (pas de segmentation store / locale). L'édition réutilise l'éditeur visuel existant.
Les 18 templates Front-Office existants conservent leur comportement actuel, contextualisé par store et locale.

Impact API

GET /v1/mail-templates, GET /v1/mail-templates/{templateId} et GET/PATCH/POST /v1/mail-templates/{templateId}/content — ajout du champ scope (STOREFRONT / BACK_OFFICE) sur le contexte du template. Champ additionnel, rétro-compatible : en l'absence de scope, le comportement actuel (Front-Office) est conservé.

📄 Documentation :

👉 Côté métier : si actif les emails partent toujours même sans template custom, et les opérateurs peuvent activer / désactiver et éditer chaque template, y compris les emails Back-Office, désormais gérés dans le même éditeur.

👉 Côté technique : emails par défaut derrière un feature flag global, configuration enabled/disabled par template / store / locale, champ scope additif sur /v1/mail-templates, templates BACK_OFFICE globaux (sélecteurs store / locale masqués).

Historique des modifications sur les rôles & groupes — nouvelle vue dans le Back-Office

Contexte

L'API d'historique des modifications de droits a été livrée dans la version précédente ; sans interface, un admin ne pouvait toujours pas retracer une dérive de droits ou investiguer un incident (« qui a retiré tel droit à tel groupe et quand ? ») directement depuis le Back-Office.

Fonctionnement

Nouvel onglet « Historique » dans la page Groupes & Rôles, au niveau du client (au même niveau que la liste des groupes). L'onglet est visible uniquement avec le rôle ALL_USER_GROUPS_READ.
Sélecteur obligatoire de type de client (Opérateur / Compte / Fournisseur) en haut de la vue.
Filtres combinables : groupe, auteur (nom ou email de l'opérateur), période (du / au) et type d'action parmi 7 options (ajout / retrait de permission, ajout / retrait d'utilisateur, renommage, création et suppression de groupe).
Tableau à 6 colonnes : Quand (date/heure relative), Auteur, Action, Permission, Groupe (avec « ancien nom → nouveau nom » pour les renommages) et User cible.
Les valeurs affichées sont des snapshots figés au moment de l'événement : un utilisateur ou un groupe supprimé / renommé après coup reste consultable avec ses valeurs d'origine.

📄 Documentation : Rôle Utilisateur

👉 Côté métier : les admins retracent qui a fait quoi et quand sur les droits (permissions, membres, groupes), pour l'investigation, la sécurité et la conformité.

👉 Côté technique : nouvelle vue consommant l'API admin GET /v1/group-roles/history (pagination, tri et filtres gérés côté back) ; export CSV, tri en colonne et détail d'événement viendront dans une version ultérieure.

👍
UPDATE

Groupes & rôles — typologies de rôles plus lisibles

Contexte

Les rôles du Back-Office étaient répartis sur 13 typologies très larges (par exemple, la typologie Catalog regroupait les permissions de 6 entités différentes) : sur la page Groupes & Rôles, retrouver un droit précis obligeait à parcourir de longues listes hétérogènes.

Fonctionnement

Les rôles sont reclassés selon une logique une typologie par entité métier (convention « Entité management ») : passage de 13 à environ 25 typologies — Product management, Assortment management, Order management, Payment management, Data Hub management, Store and store view management, etc.
Chaque rôle apparaît désormais sous sa nouvelle typologie dans la page Groupes & Rôles.
Aucune permission n'est modifiée : un opérateur qui disposait d'un rôle le conserve à l'identique, seul son emplacement dans la liste change.

👉 Côté métier : la page Groupes & Rôles devient beaucoup plus lisible — chaque permission se trouve directement sous l'entité qu'elle concerne.

👉 Côté technique : reclassement pur des rôles dans de nouvelles typologies côté catalogue back ; pas de changement de comportement des permissions.

Offer prices — état actif/inactif visible et modifiable dans le Back-Office

Contexte

L'activation / désactivation d'un offer price n'était possible que par job d'import OFFER (champ Active Price) : le Back-Office ne permettait ni de visualiser l'état actif/inactif d'un offer price, ni de le modifier manuellement. Toute vérification ou correction à l'unité obligeait à repasser par un import.

Fonctionnement

L'état actif / inactif d'un offer price est désormais visible dans le Back-Office.
L'opérateur peut activer ou désactiver un offer price manuellement, de façon cohérente avec ce que permet déjà l'import.

📄 Documentation : Offers Import

👉 Côté métier : les opérateurs contrôlent et corrigent l'état d'un offer price à l'unité directement depuis le Back-Office, sans repasser par un job d'import.

👉 Côté technique : exposition dans le front Back-Office du statut d'offer price (ACTIVE / INACTIVE) et de sa mise à jour, alignée sur la capacité existante de l'import OFFER.

Paiement par virement — affichage de l'IBAN sur la page de commande

Contexte

Lors d'un paiement par virement, un IBAN unique est généré pour chaque commande et communiqué au client par email. En cas de problème d'email ou de connexion, l'opérateur n'avait aucun moyen de retrouver cet IBAN pour le recommuniquer au client.

Fonctionnement

L'IBAN généré lors d'un paiement par virement est désormais affiché dans le Back-Office, sur la page de la commande concernée.

👉 Côté métier : l'opérateur peut relancer un client en lui communiquant l'IBAN de sa commande s'il ne l'a pas reçu.

👉 Côté technique : affichage sur la page de commande du Back-Office de l'IBAN pour les paiements par virement.