Backend Integration

For backend developers extending or maintaining Messaging.

Services

Add a provider by implementing the adapter interface and registering it — nothing in the controllers changes.

Controllers & guards

Every messaging/{sessions,chats,messages,labels} controller stacks @UseGuards(AdminAuthGuard, PermissionGuard) and tags each route with @RouteName('chat.<action>[.<providerType>]'). Message endpoints that touch a specific chat also carry @RequireChatRecord(...) for row-level scope.

CallsController is read-only: AdminAuthGuard + @SkipPermissions(), with visibility filtered in the service by ChatVisibilityPolicy.

Permissions & database

Chat access is stored in role_chat_rights (role_id, provider, action, level) with levels A > G > M > D folded to the highest across a caller's roles. Missing row defaults: read → M, writes → D.

Two services own all resolution — never re-implement it:

• ChatAccessFilterBuilder (core/services/chat-access-filter.builder.ts) — resolveLevel, canProviderAction, group checks.
• ChatVisibilityPolicy (core/services/chat-visibility.policy.ts) — canSee, selectVisibleAdmins (WS fan-out), applyVisibilityFilter (SQL predicate for lists).

Super-admins and holders of admin.* bypass (G0).

Events

Messaging reacts to CRM events via @OnEvent listeners in events/listeners/ (both run inside tenantScope.runInScope and swallow errors):

• notification.admin-assigned.whatsapp.requested → WhatsApp notify the assignee.
• comment.mentioned → WhatsApp notify the mentioned admin.

Outbound realtime broadcasts go through Redis pub/sub → MessagingEventsGateway. See Events.

Queues (Bull)

Multi-tenant safety

Messaging runs on the shared hyper-tenant DB. All DB access must go through the pinned repoProvider; Bull processors decorate the handler with @TenantScoped(). See Data isolation before touching any query or worker.