fix(notification): pass matched types to common inbox notifications

[dhaval-patel262]

Problem

getCommonNotificationTxes() passes a hardcoded empty array as the types argument to pushInboxNotifications():

https://github.com/hcengineering/platform/blob/develop/server-plugins/notification-resources/src/index.ts#L118-L134

Every notification created through this helper is therefore stored with types: [].

NotificationsHandler resolves allowed providers per notification type — it iterates notification.types, looks each one up, and calls getAllowedProviders(). With an empty array it evaluates nothing, logs NotificationsHandler: no notifications with email provider, skipping, and returns.

The result: notifications created via this helper can never be delivered by email, or by any provider other than inbox — regardless of user settings or defaultEnabled on the type.

This affects everything routed through the helper — time ToDos, process approvals, HR requests. Activity-message notifications are unaffected, because that call site passes its types through, which is why chat notifications are emailed and ToDo/approval ones are not.

Reproduce

1. Configure the mail service and set MAIL_URL on transactor and account.
2. Run a Process with a RequestApproval or CreateToDo step (process:ids:ApproveRequestCreated / process:ids:ProcessToDoCreated, both defaultEnabled: true).
3. The inbox notification appears; no email is sent. The stored notification has types: [], and the transactor logs the "skipping" line above.

Fix

The types are already computed. isShouldNotifyTx() returns a NotifyResult (Map<Ref<NotificationProvider>, NotificationType[]>) and it is passed into this function as notifyResult — it is used on the line above to decide whether to proceed at all. Forward the inbox provider's matched types instead of discarding them:

(notifyResult.get(notification.providers.InboxNotificationProvider) ?? []).map((t) => t._id)

NotifyResult holds full NotificationType docs while pushInboxNotifications takes Ref<NotificationType>[], hence the .map. The ?? [] keeps the previous behaviour if the provider is somehow absent, though the guard clause above already returns early in that case.

Verification

Applied against a self-hosted v0.7.423 transactor. Before, on an approval gate:

NotificationsHandler: processing inbox notifications  notificationTypes: []
NotificationsHandler: no notifications with email provider, skipping

After:

NotificationsHandler: processing inbox notifications
  notificationTypes: ["process:ids:ProcessToDoCreated","process:ids:ApproveRequestCreated"]
processEmailNotifications: sending email

and the mail service delivered to each collaborator. Inbox notifications are unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ws4kJfxwU8wq1yAgeix942