Notifications

Parcours pas à pas pour débuter

Prérequis : Lisez les deux guides pour débutants ci-dessous, terminez la configuration locale du Web et ouvrez ce monorepo à sa racine dans votre éditeur. Les paramètres Web appartiennent à apps/web/.env.local ; Next.js ne lit pas la racine .env. /dashboard dans le mode faux par défaut est une démo sans base de données ; /auth nécessite une base de données migrée.

Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.

1. Connectez-vous en tant que membre test et ouvrez Paramètres → Notifications pour consulter les préférences des chaînes disponibles.

2. Utilisez deux membres de test dans un espace de travail et déclenchez un événement de test local, tel qu'une invitation, avec EMAIL_PROVIDER=local.

3. Confirmez que seuls les membres éligibles et les chaînes activées reçoivent une notification dans l'application ou dans la boîte d'envoi locale. N’envoyez pas de messages de test à de vrais membres.

Pour le code personnalisé, commencez par le prompts/README.md fourni et copiez l'invite la plus proche : prompts/new-app-screen.md pour un écran d'application ou prompts/new-landing-page.md pour une page publique. Pour le travail sur un serveur, une base de données ou un fournisseur, confiez à votre agent de codage la tâche de ce guide et demandez-lui de lire les miroirs AGENTS.md, .ai/PROJECT_CONTEXT.md et .ai/ correspondants ; inspectez les fichiers sources exacts nommés ici ; lister les fichiers et les vérifications avant de les modifier ; préserver la propriété de l'espace de travail et les secrets du serveur ; et je vous montre la différence. Indiquez-lui le comportement souhaité, les champs d'entrée et de sortie, les rôles autorisés, les succès et erreurs attendus, ainsi que le compte, le fournisseur ou l'appareil de test. Utilisez des exemples de valeurs ; ne collez jamais un vrai secret.

• Avant de commencer
• Bases du terminal
• Configuration locale Web
• Invites de l'agent et mémoire du projet

Utiliser le pipeline d’événements produit

notification-events.ts associe les événements de facturation, budget, invitation, appartenance et compte connecté à un texte localisé et à un plan de livraison par membre. L’API et les clients de l’application lisent les notifications de l’espace de travail connecté ; les préférences déterminent les canaux autorisés.

Certains événements restent volontairement dans l’application. Par exemple, les échecs d’actualisation d’un compte connecté ne doivent pas exposer de détails sur les jetons ni déclencher un e-mail non sollicité.

Respecter les préférences du destinataire

Utilisez le planificateur de livraison existant, les préférences par défaut et les options d’exclusion de l’auteur au lieu d’envoyer indépendamment un message à chaque membre. Les e-mails transactionnels passent toujours par le fournisseur configuré et enregistrent leur résultat de livraison.

Vérifier les destinataires et l’état

Testez une préférence désactivée, l’exclusion de l’auteur, un membre supprimé, l’état lu/non lu et un autre espace de travail. Rendez les mises à jour dynamiques accessibles et vérifiez que les messages sont localisés.

• Envoi par e-mail
• Dictionnaires de notifications

Configuration et paramètres

Le service de notification (notification-service.ts) stocke des enregistrements in-app scopés au workspace ; GET /api/notifications les liste pour le membre connecté et la route mark-read met à jour l'état. Des drapeaux de préférence par utilisateur gatent des catégories comme les mises à jour produit et les alertes de sécurité.

Les membres gèrent leurs préférences sous /settings/notifications. Les annonces de plateforme sont rédigées via announcement-actions et livrées par le même pipeline.

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

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

Processus d’implémentation

Émettez une notification après une mutation réussie — jamais avant que l'écriture soit commitée. Gardez les payloads structurés (type, workspace, références) pour que l'interface puisse les rendre et les router sans parser de la prose.

Vérifiez le drapeau de préférence avant de livrer une catégorie désactivable ; les avis liés à la sécurité (nouvelle session, changements de clés) doivent rester obligatoires.

Vérification et dépannage

Vérifiez qu'une préférence désactivée supprime la livraison, que mark-read persiste entre sessions, qu'un autre workspace ne peut pas lister les enregistrements et que les annonces atteignent les membres visés. Gardez le fan-out des notifications hors du chemin critique de la requête quand le volume grandit.