Kunden

Ein Kunde ist ein Website-Mitglied aus Sicht des Admins: ein Record eines Modells mit aktivierten Konten, identifiziert über seine Identität (meist eine E-Mail). Eine eigene Kundentabelle gibt es nicht. Hat dein Workspace zwei Kontomodelle - etwa members und wholesale - zeigt der Bereich Kunden beide, mit einem Tab pro Modell.

Der Bereich liegt in der Admin-Navigation neben Commerce und Team. Er erscheint, sobald mindestens ein Modell Konten aktiviert hat; vorher verweist er auf Modelle.

Die Liste

Suche nach Identität, filtere nach Status und nach Firma, wenn das Modell eine deklariert. Jede Zeile zeigt das Anzeigefeld des Records (oder die Identität, wenn es leer ist), das Modell, den Status, die letzte Anmeldung, das Beitrittsdatum und - mit orders:view - die Zahl der laufenden Bestellungen und die Ausgaben des Kunden je Währung. Ausgaben werden nie über Währungen hinweg summiert.

• active - kann sich anmelden.
• pending - registriert, E-Mail noch nicht verifiziert. Gibt es nur, wenn das Modell Verifizierung verlangt.
• suspended - Anmeldung verweigert, alle Sitzungen beendet.

Eine Sperre nach zu vielen Fehlversuchen ist kein Status: die Zeile zeigt gesperrt bis, und sie läuft von selbst ab.

Klicke einen Spaltenkopf, um zu sortieren: Identität, Status, letzte Anmeldung, Beitritt, Bestellungen. Die Sortierung steht in der Adresszeile, eine sortierte Ansicht lässt sich also merken oder teilen. Sortieren nach Bestellungen braucht orders:view.

Kunde hinzufügen legt einen Konto-Record aus dem Admin an, im Modell des aktuellen Tabs oder einem gewählten, sodass du jemanden einrichten kannst, bevor er die Website je besucht. CSV exportieren schreibt jeden Kunden, der zu Suche, Filtern und Sortierung passt - nicht nur die Seite - mit den Bestellspalten, wenn du Bestellungen sehen darfst. Zellen, die mit einem Formelzeichen beginnen, werden escaped, damit die Datei sicher in einer Tabellenkalkulation aufgeht.

Markiere Zeilen, um gesammelt zu sperren oder freizugeben, bis zu 100 auf einmal. Kunden, bei denen die Änderung nicht geht - noch nicht verifiziert, schon im Zielzustand - werden übersprungen und gezählt, der Rest geht durch.

Die Detailseite

Die Kontokarte, eine Karte Bestellhistorie (laufende Bestellungen, Ausgaben je Währung, letzte Bestellung; braucht orders:view), dann drei Tabs: Profil (die Felder des Records, nur lesend, Relationen als Label des verknüpften Records; Bearbeiten öffnet denselben Record-Dialog wie Modelle), Bestellungen und Warenkörbe dieses Kunden. Das Profil ist der Record, Bearbeiten braucht also models:edit; die beiden Tabs brauchen orders:view und carts:view.

Sperren und freigeben

Sperren blockiert die Anmeldung und macht jeden Access- und Refresh-Token des Kunden ungültig - die nächste Anfrage mit einem alten Token wird abgewiesen. Bestellungen, Warenkörbe und der Record selbst bleiben. Ein pending-Konto lässt sich nicht sperren: seine Verifizierung würde sonst zu einem Weg, es zu aktivieren.

Freigeben lässt den Kunden wieder anmelden und hebt jede Sperre auf. Beide Aktionen verweigern, wenn das Konto schon im Zielzustand ist - ein Agent, der einen Aufruf wiederholt, kann es nicht zweimal umschalten.

Passwort zurücksetzen, Verifizierung und Entsperren

Die Kontokarte bietet die Aktion, die zum Status passt. Passwort-Reset senden mailt einem aktiven Kunden einen Link zum Setzen eines neuen Passworts; er gilt eine Stunde. Verifizierung erneut senden schickt einem pending-Kunden einen frischen Link und macht den vorigen ungültig. Entsperren erscheint nur, solange eine Sperre läuft: es löscht den Fehlversuchszähler und die Anmeldedrossel, sodass der Kunde sofort wieder probieren kann. Ein gesperrter Kunde bekommt keine davon; erst freigeben.

Beide E-Mails gehen über die Mail-Einstellungen des Workspace und brauchen die öffentliche Website-URL, weil der Link auf deine Website zeigt. Wurde der Link ausgestellt, aber der Mailer hat die Nachricht abgelehnt, sagt der Admin das, statt so zu tun als ob. Jeder Kunde bekommt höchstens fünf dieser E-Mails pro Stunde, damit ein hängendes Formular kein Postfach flutet. Ein Passwort-Reset wird auf einem Modell ohne Passwort-Anmeldung verweigert.

Bestellungen und Gäste

Eine Bestellung eines angemeldeten Mitglieds hängt an diesem Mitglied. Eine Gastbestellung wird später zugeordnet, wenn der Gast dieselbe E-Mail registriert und verifiziert - „meine Bestellungen“ füllt sich rückwirkend. Aus dem Bestelldetail kannst du einen Kunden auch von Hand zuordnen oder lösen. Die Bestellliste sucht nach der Identität des Kunden und nach dem auf der Bestellung eingefrorenen Firmennamen und lässt sich auf eine Firma eingrenzen.

Firmen (B2B)

Im Tab Funktionen des Kontomodells benennst du ein Firmenfeld (eine Relation zu deinem Firmenmodell) und ein Firmenrollenfeld (ein Select wie buyer / approver). Die Kundenliste bekommt dann eine Firmenspalte und einen Filter, Bestellungen und Warenkörbe lassen sich nach Firma listen, und eine Bestellung friert den Firmennamen beim Checkout ein, damit eine spätere Umbenennung die Historie nicht umschreibt. Nichts von der Firma erscheint auf der öffentlichen API. Ein Besucher kann sich bei der Registrierung auch keine Firma aussuchen: register weist eine Payload ab, die das Firmen- oder Firmenrollenfeld setzt, sodass nur der Admin (oder ein Agent über update_record) einen Kunden einer Firma zuordnet.

Berechtigungen

• customers:view - Bereich, Liste und Detail sehen, CSV exportieren. Standard in der Rolle Viewer.
• customers:manage - sperren und freigeben (einzeln oder gesammelt), Kunde hinzufügen, Passwort-Reset senden, Verifizierung erneut senden, entsperren. Standard in der Rolle Editor.
• orders:view - die Bestellspalten, die Sortierung nach Bestellungen und die Karte Bestellhistorie.

Einen Kunden einer Bestellung zuzuordnen ist eine Bestelländerung und braucht orders:manage.

Aus MCP und Spotlight

Dieselbe Oberfläche steht Agenten zur Verfügung: list_customers (Modell, Status, Suche, Firma, Paging), get_customer (Zusammenfassung plus Record-Daten), suspend_customer und unsuspend_customer, send_customer_password_reset, resend_customer_verification und unlock_customer. Jeder Kunde, den ein Agent liest, trägt orderStats - laufende Bestellungen, Ausgaben je Währung, letzte Bestellung - oder null, wenn der Token keine Bestellungen sehen darf. Ein Sammelwerkzeug gibt es absichtlich nicht: ein Agent bestätigt einen Kunden nach dem anderen. get_model liefert die auth-Konfiguration des Modells, update_model setzt die Firmenfelder. list_orders und get_order liefern customerId, companyId und companyName (null bei Gastbestellungen), und list_orders nimmt einen companyId-Filter und eine Suche über den eingefrorenen Firmennamen, sodass die Bestellungen einer Firma einen Agenten auf demselben Weg erreichen. Siehe den Werkzeugkatalog.

Nächste Schritte

• Mitglieder-Authentifizierung - der Registrierungs- und Anmeldefluss deiner Website.
• Commerce - Bestellungen, Warenkörbe und Checkout.
• Mitglieder und Rollen - wer im Team welche Berechtigung bekommt.