Set up Telegram from a bot token posted in the support chat - #1583

Summary

Customers keep pasting their Telegram bot token into the support chat instead of the connector setup page, and then wait for us to install it by hand. This lets the Cloud backend do it from the chat, without a click, under strict identity rules.

Who is acting comes only from the verified widget identity, never from the message: Libredesk resolves the contact from the HS256 JWT our backend signs (external_user_id = <host>:<userId>, secret only on Cloud), and the message must come from that contact. Everything else is re-checked in our database at install time.

Changes

• ee/support/support-telegram-setup.service.ts (new): on message.created, finds exactly one Telegram bot token in an incoming, non-private contact message and installs telegram-bot when all of these hold:
  • live-chat conversation, sender = the conversation's contact, contact type contact, external_user_id prefixed with this instance's host;
  • user exists, email verified, exactly one active workspace, role ADMIN or EDITOR (several workspaces → setup link; viewer → told to ask an editor);
  • the workspace has no Telegram connector yet (never replaces or duplicates; answers with the existing connector's link);
  • Telegram getMe accepts the token (otherwise the catalog's verify hint);
  • plan allows another connector (LicenseGuardService); at most 3 such installs per workspace a day, one per conversation (tag telegram-auto-setup).
    Then: importAdapter + attachToDefaultServer as the dashboard does, security event CONNECTOR_INSTALLED_VIA_SUPPORT_CHAT, product event setup_completed (via: support_chat), a reply in the chat, and an email to the user and every workspace admin.
• support.controller.ts: routes message.created to it (the triage still handles conversation.created).
• libredesk.client.ts: conversation() and reply().
• Triage prompt: no "revoke it" suggestion for a Telegram bot token.
• Core: AdaptersModule exports AdaptersService; new security event name; connectorAddedFromSupportEmail template + EmailService.sendConnectorAddedFromSupportEmail.

Deployment modes: Cloud only in practice. The handler runs where LIBREDESK_* is set (only Cloud). Dedicated instances and self-hosted installations do not load the triage webhook; self-hosted does not load the support module at all.

The token is never logged, never echoed in the chat reply and not stored in the security event.

Type

• New feature

Testing

• Added/updated unit tests (support-telegram-setup.service.spec.ts: happy path, ignored senders/identities, unverified, several workspaces, viewer, existing connector, invalid token, plan limit, dedupe and daily limit)

Commands, in packages/backend after npm ci and npx prisma generate:

• npx jest src/ee/support src/settings/email src/adapters/adapters.controller --maxWorkers=4 → 8 suites, 1012 tests passed
• npx tsc --noEmit -p tsconfig.json → no errors
• npm run lint → 0 errors (11 existing warnings, none in changed files)
• npm test -- --maxWorkers=4 → 1044 suites passed; src/auth/jwt-or-management-key.guard.spec.ts fails with 13 tests, and fails the same way on clean main (baseline, not from this change)

Checked against the live desk (read-only): conversation detail carries inbox_channel: livechat, contact.id, contact.type: contact, contact.external_user_id = cloud.anythingmcp.com:<id>; incoming contact messages carry sender_id = contact.id.

After deploy: add message.created to Libredesk webhook 1 (now conversation.created only) and tell the desk's AI assistant not to ask for a revoke of a Telegram bot token.

Checklist

• My code follows the existing code style
• I have tested my changes locally
• All existing tests pass (npm test): see the baseline failure above
• This PR has a descriptive title