nocobase-app-plugin-notification

Resolve notificationServiceToken from the application's ServiceContainer and call send() with an idempotencyKey, recipient, channels, and content. Never create a second manager or call a Provider directly; the result returns the Notification id and Delivery snapshots.

Enable the core plugin plus the in-app and provider packages, then define the notification.channels array using defineInAppChannelConfig and defineEmailChannelConfig with SMTP or Resend Providers. Load passwords and API keys from the runtime secret source and run migrations before starting delivery.

No, accepted only means the Provider confirmed it accepted the submission. It does not prove final delivery to or reading by the recipient, so keep querying getNotification or getByIdempotencyKey until Deliveries reach a terminal state.

Pending usually means the queue worker or reconciler is not running, while unknown means a Provider submission may have happened but confirmation was lost. Check Deliveries, Attempts, and correlated server logs, and never auto-retry an unknown Delivery without Provider evidence.

Terminal failed Deliveries can be retried with retryDelivery and a recorded reason after fixing the cause. Unknown Deliveries require checking Provider evidence first; without valid Provider idempotency, retrying accepts possible duplication and the reason must document that decision.

Implement a NotificationChannelDefinition for recipient resolution and rendering, and a NotificationProviderDefinition for the external submission, then register both via notificationExtensionRegistryToken before the first send. Keep credentials and network I/O in the Provider and redact secrets from errors and logs.