Benachrichtigungen

Schritt-für-Schritt für Einsteiger

Voraussetzungen: Lesen Sie die beiden folgenden Einsteigerhandbücher, schließen Sie die lokale Web-Einrichtung ab und öffnen Sie dieses Monorepo im Stammverzeichnis in Ihrem Editor. Webeinstellungen gehören in apps/web/.env.local; Next.js liest das Stammverzeichnis .env nicht. /dashboard im Standard-Fake-Modus ist eine Demo ohne Datenbank; /auth benötigt eine migrierte Datenbank.

Kurze Begriffe: Ein Arbeitsbereich umfasst die einzelnen Benutzer, Daten und Einstellungen eines Teams. Der Server ist das vertrauenswürdige Backend; Halten Sie Anbieterschlüssel aus Browser- und Telefoncodes fern. Eine Migration ist eine versionierte Datenbankänderung, die Tabellen erstellt oder aktualisiert. Ein KI-Modell ist der Motor, der antwortet; Der Modellkatalog ist die Liste der verfügbaren Modell-IDs und Preise des Servers. Ein Anbieter ist ein externer Dienst wie ein KI-, E-Mail- oder Abrechnungsdienst. Eine Berechtigung ist eine Bewilligung, die einem Arbeitsbereich die Nutzung einer Funktion ermöglicht. Ein Webhook ist eine Nachricht, die ein Dienst an den URL eines anderen Dienstes sendet.

1. Melden Sie sich als Testmitglied an und öffnen Sie Einstellungen → Benachrichtigungen, um die verfügbaren Kanaleinstellungen zu überprüfen.

2. Verwenden Sie zwei Testmitglieder in einem Arbeitsbereich und lösen Sie mit EMAIL_PROVIDER=local ein lokales Testereignis aus, z. B. eine Einladung.

3. Bestätigen Sie, dass nur berechtigte Mitglieder und aktivierte Kanäle eine Benachrichtigung in der App oder im lokalen Postausgang erhalten. Senden Sie keine Testnachrichten an echte Mitglieder.

Beginnen Sie für benutzerdefinierten Code mit dem bereitgestellten prompts/README.md und kopieren Sie die nächstgelegene Eingabeaufforderung: prompts/new-app-screen.md für einen App-Bildschirm oder prompts/new-landing-page.md für eine öffentliche Seite. Geben Sie Ihrem Programmieragenten für Server-, Datenbank- oder Anbieterarbeiten die Aufgabe dieses Handbuchs und bitten Sie ihn, AGENTS.md, .ai/PROJECT_CONTEXT.md und passende .ai/-Spiegel zu lesen; Überprüfen Sie die hier genannten genauen Quelldateien. Listen Sie Dateien auf und prüfen Sie sie vor der Bearbeitung. Bewahren Sie den Arbeitsbereichseigentum und die Nur-Server-Geheimnisse. und zeige dir den Unterschied. Teilen Sie ihm das gewünschte Verhalten, Eingabe- und Ausgabefelder, zulässige Rollen, erwartete Erfolge und Fehler sowie das Testkonto, den Anbieter oder das Gerät mit. Beispielwerte verwenden; Fügen Sie niemals ein echtes Geheimnis ein.

• Bevor Sie beginnen
• Terminal-Grundlagen
• Lokales Web-Setup
• Agentenaufforderungen und Projektspeicher

Produkt-Ereignispipeline verwenden

notification-events.ts ordnet Abrechnungs-, Budget-, Einladungs-, Mitgliedschafts- und Kontoverbindungsereignisse lokalisierten Texten und Zustellplänen pro Mitglied zu. API und App-Clients lesen die Benachrichtigungen des angemeldeten Workspace; Einstellungen bestimmen die verfügbaren Kanäle.

Einige Ereignisse bleiben absichtlich in der App. Fehler beim Aktualisieren verbundener Konten dürfen zum Beispiel weder Token-Details offenlegen noch unaufgeforderte E-Mails auslösen.

Empfängereinstellungen beachten

Verwenden Sie den vorhandenen Zustellplaner, Standardeinstellungen und Optionen zum Ausschluss des Akteurs, statt unabhängig Nachrichten an alle Mitglieder zu senden. Transaktions-E-Mails verwenden weiterhin den konfigurierten Provider und erfassen ihr eigenes Zustellergebnis.

Empfänger und Status überprüfen

Testen Sie eine deaktivierte Einstellung, ausgeschlossenen Akteur, entferntes Mitglied, Verhalten als ungelesen und gelesen sowie einen anderen Workspace. Halten Sie dynamische Aktualisierungen zugänglich und prüfen Sie lokalisierte Nachrichten.

• E-Mail-Versand
• Benachrichtigungswörterbücher

Einrichtung und Konfiguration

Der Notification-Service (notification-service.ts) speichert workspace-scoped In-App-Records; GET /api/notifications listet sie für das angemeldete Mitglied, und die Mark-read-Route aktualisiert den Zustand. Pro-Nutzer-Präferenz-Flags gaten Kategorien wie Produkt-Updates und Sicherheits-Alerts.

Mitglieder verwalten Präferenzen unter /settings/notifications. Plattform-Ankündigungen werden über announcement-actions verfasst und über dieselbe Pipeline zugestellt.

GET   /api/notifications
PATCH /api/notifications   (mark-read)

Emitted on mutations, e.g.:
  member.left
  member.role_changed

Implementierungsablauf

Emitte eine Notification nach erfolgreicher Mutation — nie bevor der Write committet. Halte Payloads strukturiert (Typ, Workspace, Referenzen), damit das Interface sie rendern und routen kann, ohne Prosa zu parsen.

Prüfe das Präferenz-Flag, bevor du eine deaktivierbare Kategorie zustellst; sicherheitsrelevante Hinweise (neue Session, Key-Änderungen) sollten verpflichtend bleiben.

Überprüfung und Fehlerbehebung

Verifiziere, dass eine deaktivierte Präferenz die Zustellung unterdrückt, Mark-read über Sessions hinweg persistiert, ein anderer Workspace die Records nicht listen kann und Ankündigungen die vorgesehenen Mitglieder erreichen. Halte Notification-Fan-out abseits des kritischen Request-Pfads, wenn das Volumen wächst.