Clients
Tous les comptes de votre site dans une liste : qui s'est inscrit, qui a vérifié, qui est verrouillé - et l'interrupteur qui empêche quelqu'un de se connecter.
Un client est un membre du site vu depuis l'admin : un enregistrement d'un modèle dont les comptes sont activés, identifié par son identité (en général un e-mail). Il n'y a pas de table clients à part. Si votre espace de travail a deux modèles de comptes - par exemple members et wholesale - l'espace Clients liste les deux, avec un onglet par modèle.
L'espace se trouve à côté de Commerce et Équipe dans la navigation de l'admin. Il apparaît dès qu'au moins un modèle a les comptes activés ; avant cela, il renvoie vers Modèles.
La liste
Recherchez par identité, filtrez par statut et par entreprise quand le modèle en déclare une. Chaque ligne montre le champ d'affichage de l'enregistrement (ou l'identité s'il est vide), le modèle, le statut, la dernière connexion, la date d'inscription et - avec orders:view - le nombre de commandes en cours et ce que le client a dépensé, par devise. Les dépenses ne sont jamais additionnées entre devises.
active- peut se connecter.pending- inscrit, e-mail pas encore vérifié. N'existe que si le modèle exige la vérification.suspended- connexion refusée, toutes les sessions terminées.
Un verrouillage après trop de tentatives échouées n'est pas un statut : la ligne affiche verrouillé jusqu'à et il expire de lui-même.
Cliquez un en-tête de colonne pour trier : identité, statut, dernière connexion, inscription, commandes. Le tri est dans la barre d'adresse, une vue triée peut donc être mise en favori ou partagée. Trier par commandes demande orders:view.
Ajouter un client crée un enregistrement de compte depuis l'admin, sur le modèle de l'onglet courant ou celui que vous choisissez, pour préparer quelqu'un avant même sa première visite. Exporter en CSV écrit chaque client correspondant à la recherche, aux filtres et au tri courants - pas seulement la page - avec les colonnes de commandes quand vous pouvez voir les commandes. Les cellules qui commencent par un caractère de formule sont échappées pour que le fichier s'ouvre sans risque dans un tableur.
Cochez des lignes pour suspendre ou rétablir en masse, jusqu'à 100 à la fois. Les clients pour qui le changement est impossible - pas encore vérifiés, déjà dans l'état cible - sont ignorés et comptés, les autres passent.
La page de détail
La carte du compte, une carte Historique des commandes (commandes en cours, dépenses par devise, dernière commande ; demande orders:view), puis trois onglets : Profil (les champs de l'enregistrement, en lecture seule, les relations affichées par le libellé de l'enregistrement lié ; Modifier ouvre le même dialogue que Modèles), Commandes et Paniers de ce client. Le profil est l'enregistrement, le modifier demande donc models:edit ; les deux onglets demandent orders:view et carts:view.
Suspendre et rétablir
Suspendre bloque la connexion et invalide chaque jeton d'accès et de rafraîchissement du client - la requête suivante avec un ancien jeton est refusée. Les commandes, les paniers et l'enregistrement restent. Un compte pending ne peut pas être suspendu : sa vérification deviendrait sinon un moyen de l'activer.
Rétablir laisse le client se reconnecter et lève tout verrouillage. Les deux actions refusent si le compte est déjà dans l'état cible : un agent qui réessaie un appel ne peut pas le basculer deux fois.
Réinitialisation du mot de passe, vérification et déverrouillage
La carte du compte propose l'action qui convient au statut. Envoyer une réinitialisation envoie à un client actif un lien pour définir un nouveau mot de passe ; il vaut une heure. Renvoyer la vérification envoie à un client pending un lien neuf et invalide le précédent. Déverrouiller n'apparaît que pendant un verrouillage : il remet à zéro le compteur d'échecs et la limitation de connexion, le client peut réessayer tout de suite. Un client suspendu n'a aucune de ces actions ; rétablissez-le d'abord.
Les deux e-mails partent par les réglages de messagerie de l'espace de travail et exigent l'URL publique du site, car le lien pointe vers votre site. Quand le lien a été émis mais que le serveur de mail a refusé le message, l'admin le dit au lieu de faire semblant. Chaque client reçoit au plus cinq de ces e-mails par heure, pour qu'un formulaire bloqué n'inonde pas une boîte. Une réinitialisation est refusée sur un modèle sans connexion par mot de passe.
Commandes et invités
Une commande passée par un membre connecté est rattachée à ce membre. Une commande d'invité est rattachée plus tard, quand l'invité s'inscrit et vérifie le même e-mail - « mes commandes » se remplit rétroactivement. Depuis le détail d'une commande, vous pouvez aussi rattacher ou détacher un client à la main. La liste des Commandes cherche par identité du client et par nom d'entreprise figé sur la commande, et peut être restreinte à une entreprise.
Entreprises (B2B)
Dans l'onglet Capacités du modèle de comptes, vous nommez un champ entreprise (une relation vers votre modèle d'entreprises) et un champ rôle dans l'entreprise (un select tel que buyer / approver). La liste Clients gagne alors une colonne et un filtre Entreprise, les commandes et paniers se listent par entreprise, et une commande fige le nom de l'entreprise au checkout pour qu'un renommage ultérieur ne réécrive pas l'historique. Rien de l'entreprise n'est exposé sur l'API publique. Un visiteur ne peut pas non plus choisir une entreprise à l'inscription : register refuse une charge utile qui renseigne le champ entreprise ou rôle dans l'entreprise, seul l'admin (ou un agent via update_record) place un client dans une entreprise.
Permissions
customers:view- voir l'espace, la liste et le détail, exporter le CSV. Par défaut sur le rôle Viewer.customers:manage- suspendre et rétablir (un par un ou en masse), ajouter un client, envoyer une réinitialisation, renvoyer la vérification, déverrouiller. Par défaut sur le rôle Editor.orders:view- les colonnes de commandes, le tri par commandes et la carte d'historique.
Rattacher un client à une commande modifie la commande et demande donc orders:manage.
Depuis MCP et Spotlight
La même surface est offerte aux agents : list_customers (modèle, statut, recherche, entreprise, pagination), get_customer (résumé plus les données de l'enregistrement), suspend_customer et unsuspend_customer, send_customer_password_reset, resend_customer_verification et unlock_customer. Chaque client lu par un agent porte orderStats - commandes en cours, dépenses par devise, dernière commande - ou null quand le jeton ne peut pas voir les commandes. Il n'y a pas d'outil en masse, volontairement : un agent confirme un client à la fois. get_model renvoie la configuration auth du modèle et update_model pose les champs entreprise. list_orders et get_order renvoient customerId, companyId et companyName (null pour une commande d'invité), et list_orders accepte un filtre companyId et une recherche sur le nom d'entreprise figé, pour que les commandes d'une entreprise parviennent à un agent par le même chemin. Voir le catalogue d'outils.
Étapes suivantes
- Authentification des membres - le flux d'inscription et de connexion que votre site implémente.
- Commerce - commandes, paniers et checkout.
- Membres et rôles - qui dans l'équipe reçoit quelle permission.