Périmètre

🖥️ Back-Office

Configuration du serveur SMTP éditable depuis le Back-Office

Contexte

Jusqu'à présent, la configuration du serveur d'envoi d'emails (SMTP) n'était pas modifiable depuis le Back-Office : tout changement (rotation de mot de passe, changement de serveur, rétablissement de l'envoi d'emails) nécessitait une intervention technique de DJUST. Les administrateurs disposant des droits sur les paramètres de l'application peuvent désormais gérer cette configuration en autonomie.

Fonctionnement

Un nouveau bloc Serveur d'envoi (SMTP) est disponible dans la carte Configuration de la messagerie des paramètres de l'application. Il permet de consulter et de modifier la configuration SMTP, y compris le type d'authentification, désormais affiché en lecture.

Le mot de passe SMTP bénéficie d'un traitement sécurisé : il n'est jamais réaffiché, et s'il n'est pas ressaisi lors d'une modification, la valeur existante est conservée. Un avertissement accompagne le champ mot de passe pour prévenir tout écrasement involontaire. L'accès à cet écran reste conditionné aux droits sur les paramètres de l'application.

Impact API

• ADM-SETTINGS-510 : le type d'authentification (authType) est désormais renvoyé en lecture.
• ADM-SETTINGS-211 : le mot de passe SMTP existant est conservé lorsqu'il n'est pas transmis dans la requête.

📄 Documentation : Mailer Settings Configuration Guide

👉 Côté métier : les administrateurs peuvent rétablir ou modifier l'envoi des emails de la plateforme en autonomie, sans dépendre d'une intervention technique.

👉 Côté technique : l'API des paramètres mailer expose authType en lecture et préserve le mot de passe SMTP non transmis, permettant un écran d'édition fiable sans risque d'effacement du secret.

Protection contre l'auto-retrait des droits d'accès au Back-Office

Contexte

Un utilisateur disposant du droit de gérer les rôles pouvait, depuis la gestion des permissions, retirer ses propres rôles critiques et perdre instantanément l'accès au Back-Office, sans possibilité de retour en arrière sans intervention DJUST.

Fonctionnement

Une auto-protection est désormais en place : un utilisateur ne peut plus valider une modification qui lui ferait perdre ses propres droits critiques d'accès au Back-Office (consultation des groupes, création et modification des utilisateurs).

Cette protection s'applique dans deux cas :

• la modification des permissions d'un groupe dont l'utilisateur est membre, si elle retire un rôle critique que ses autres groupes ne couvrent pas ;
• le retrait de son propre compte d'un groupe portant un rôle critique, si aucun de ses autres groupes ne porte ce rôle.

Dans ces situations, l'API refuse l'opération et le Back-Office affiche un message explicite invitant à faire réaliser la modification par un autre opérateur. La gestion des droits des autres utilisateurs reste inchangée : elle demeure de la responsabilité de l'opérateur, accompagnée d'un avertissement avant validation.

📄 Documentation : Rôle Utilisateur

👉 Côté métier : plus d'auto-lockout par maladresse — un administrateur ne peut plus se retirer lui-même l'accès à la gestion des utilisateurs et des rôles.

👉 Côté technique : l'API de gestion des groupes et des permissions refuse toute modification qui retirerait à l'utilisateur courant ses propres droits critiques, avec une erreur explicite consommée par le Back-Office.

🔗 Data Hub

Import de commandes — avancement du statut au-delà de l'expédition

Contexte

L'import de commandes (CSV ou API) refusait toute mise à jour d'une commande logistique dont le statut avait dépassé PARTIALLY_SHIPPED. Il était donc impossible de faire avancer une commande déjà SHIPPED vers COMPLETED via l'import, alors qu'il s'agit d'une transition légitime — un blocage pénalisant pour les flux logistiques répartis sur plusieurs fichiers.

Fonctionnement

Le changement de statut via l'import est désormais autorisé quel que soit le statut courant de la commande, tant que la transition respecte le sens d'avancement du cycle de vie : une avance de statut est acceptée (ex. SHIPPED → COMPLETED), un retour en arrière reste refusé (ex. SHIPPED → DRAFT).

Le comportement existant est préservé pour le reste : les régressions de statut restent bloquées et les mises à jour de custom fields restent possibles quel que soit le statut.

📄 Documentation : Orders Import

👉 Côté métier : les commandes réparties sur plusieurs fichiers d'import peuvent désormais être clôturées normalement (SHIPPED → COMPLETED).

👉 Côté technique : les jobs d'import ORDER (CSV et API) contrôlent le sens de la transition de statut au lieu du statut courant.