Skip to main content
Notification representa o conteúdo compartilhado. NotificationRecipient representa o estado individual de cada usuário que recebeu a notificação.

​
Fluxo

​
Etapas

​
Regras

  • O estado de leitura é sempre por usuário.
  • O mesmo usuário não deve ter dois recipients para a mesma Notification.
  • O front resolve a navegação pelo type, resourceDomain, resource e resourceId.
  • payload deve conter apenas dados necessários para renderização ou roteamento.
  • OPS cobre o ambiente operacional da cooperativa; não existe audiência COOPERATIVE.
  • Alertas de guard operacional usam audience = BKO, type = OPERATIONAL_GUARD_ALERT e recipients resolvidos entre usuários internos administradores da MOB/BKO.
  • Notificação cancelada não deve criar novos recipients.
  • Notificação expirada não deve aparecer como ativa.
  • Criação, cancelamento e expiração de Notification publicam notification.created, notification.cancelled e notification.expired.
  • As mesmas mutações solicitam auditoria por audit_log.requested com domain = COMMUNICATION e resource = NOTIFICATION.
  • Criação, leitura, arquivamento, remoção e leitura em massa de NotificationRecipient publicam notification_recipient.created, notification_recipient.marked_as_read, notification_recipient.archived, notification_recipient.deleted e notification_recipient.all_marked_as_read.
  • As mutações de NotificationRecipient solicitam auditoria por audit_log.requested com domain = COMMUNICATION e resource = NOTIFICATION_RECIPIENT.
  • As APIs BKO, OPS, Customer e Driver expõem inbox por audience; o estado é sempre do usuário autenticado, e OPS também força o escopo da organização autenticada.

​
Tipos iniciais

Veja a modelagem em Notification.