Chez FastComments, nous savons que vous recevez déjà suffisamment de notifications. C'est pourquoi nous prenons des mesures pour limiter les notifications que reçoivent les utilisateurs tout en les maintenant en contact avec leurs communautés. Nous souhaitons également tenir les administrateurs et les modérateurs informés et leur signaler quand une action est nécessaire.

Nous enverrons des notifications pour les événements suivants aux administrateurs et modérateurs :

• Récapitulatif de la communauté (fréquence configurable).
• Demandes d'aide de la communauté et rappels.
• Nouveaux commentaires de l'heure.

Pour les commentateurs :

• Lorsqu'une personne répond à votre commentaire (par e-mail).
• Lorsqu'on vous mentionne (notification dans l'application et par e-mail).
• Lorsqu'une personne répond dans le même fil (notification dans l'application et par e-mail).
• Lorsqu'une personne répond à un commentaire enfant dans le même fil (notification dans l'application et par e-mail).
• Lorsqu'une personne répond à une page à laquelle vous êtes abonné (notification dans l'application et par e-mail).
• Lorsqu'un utilisateur commente pour la première fois (mais pas avec SSO).
• Lorsqu'un utilisateur laisse un commentaire dans une session non vérifiée (mais pas avec SSO).
  • Nous n'envoyons pas plusieurs e-mails de vérification dans ce cas. Seul le premier, qui vérifiera toute l'activité dans la même session.

...et enfin uniquement pour les administrateurs :

• Lorsque les intégrations sont terminées.
• Lorsque les migrations sont terminées.
• Lorsque les importations ou exportations sont terminées.
• En cas de problèmes de facturation.
• Rappels de fin d'essai.

Certaines notifications sont groupées afin d'éviter l'envoi massif de notifications aux utilisateurs. En savoir plus dans la section suivante Notification Types.

Il existe plusieurs types de notifications et de canaux par lesquels FastComments envoie des notifications :

• Immédiates par e-mail.
• Immédiates via l'application.
  • Celles-ci sont affichées sous l'icône de la cloche de notifications.
• Regroupées par e-mail.
  • Elles sont regroupées sur une base horaire. S'il n'y a rien à envoyer pour l'utilisateur dans cette tranche horaire, nous n'envoyons pas d'e-mail.
• Planifiées par e-mail.
  • Par exemple, le Community Digest Summary, qui peut être envoyé quotidiennement, hebdomadairement ou mensuellement (ou désactivé).

Pour SSO, il y a la configuration suivante à prendre en compte pour les notifications :

• Savoir si l'utilisateur a choisi de recevoir des notifications.
  • Cela se fait en définissant le flag optedInNotifications sur true ou false dans l'objet SSOUser.
  • Cela peut être défini via l'API.
  • De plus, si vous passez une valeur pour ce flag dans la charge utile, elle sera automatiquement mise à jour lorsque l'utilisateur charge un fil de commentaires.
• Savoir si l'utilisateur a choisi de recevoir des notifications d' abonnement.
  • Cela se fait en définissant le flag optedInSubscriptionNotifications sur true ou false dans l'objet SSOUser.
  • Cela peut être défini via l'API.
  • De plus, si vous passez une valeur pour ce flag dans la charge utile, elle sera automatiquement mise à jour lorsque l'utilisateur charge un fil de commentaires.
• Définir leur adresse email.
  • S'il est absent, nous ne pouvons pas envoyer de notifications par email.
• Savoir s'il faut désactiver les liens de désabonnement dans les emails.
  • Cela se fait via le flag disableUnsubscribeLinks dans l'objet Tenant.
  • Cela peut être défini via l'API.
• Savoir s'il faut utiliser un lien de désabonnement personnalisé.
  • Cela se fait via la propriété footerUnsubscribeURL sur l'objet DomainConfig.
  • Cela peut être défini via l'API.
  • Vous pouvez également envisager de définir les en-têtes de désabonnement pertinents via emailHeaders dans le même objet.