[mysubcult]

Merge order. Updated against current master (#97 is in). #103 and this PR now merge cleanly in either order. #99 and this PR both add a column to the same one-line CREATE TABLE lhc_telegram_bot in install.sql / structure.json (and the next lines of the bot model / validator / form), so whichever of the two goes second will show a conflict — no logic overlap, I will update the branch right after the first one is merged. The topic icon and label from #103 are used only when TelegramTopicIcons exists, so this PR also works without #103.

What

A new operator-bot option Create topics for mail conversations of the selected departments (lhc_telegram_bot.mail_topics, off by default). With it, mail conversations of the bot departments are handled in forum topics the same way as chats:

• a new e-mail (mail.conversation_started) opens a topic with a card: customer, subject, text (quoted history cut, long e-mails shortened), attachment names and a link to the conversation in the back office;
• next e-mails of the conversation (mail.conversation_reply) are posted into the same topic;
• text a registered operator writes in the topic is sent to the customer as a reply e-mail through erLhcoreClassMailconvValidator::sendReply — threaded, sent from the mailbox, copied to Sent — and a pending conversation becomes active and is assigned to that operator. The operator gets a short confirmation (or the error) as a reply in the topic.

The customer is the Reply-To address when an e-mail comes from the mailbox's own domain (typical for web forms), otherwise the sender.

How

• providers/TelegramMailTopics.php — listeners, card/message text, reply.
• Topics are lhc_telegram_chat rows with type = 2 and chat_id = mail conversation id; all existing lookups filter type = 1, so chat topics and commands are untouched.
• GenericmessageCommand: when the topic is not a chat topic, TelegramMailTopics::operatorReply() is tried; it returns null for anything that is not a mail topic of this bot.
• Bot option: model, pos, validator, form, doc/structure.json, doc/install.sql; README section.

Only text is mailed for now; files and commands (/…, !…) are not sent to the customer.

Tested

On a production install with three mailboxes: new e-mail → topic with the card; replies from the customer (also arriving in another mailbox of the same conversation) → posted into the topic; operator text → e-mail delivered to the customer, conversation active and assigned.

🤖 Generated with Claude Code

[mysubcult]

Thanks for merging #97, #98, #100, #101 and #104! I merged master into this branch and resolved the overlap with #97 (both disable_link_preview and mail_topics are kept), and moved the README section to the end so it no longer overlaps #103. It is mergeable again; #103 merges cleanly before or after it. #99 touches the same CREATE TABLE line, so if #99 goes in first I will update this branch right away.

[mysubcult]

Quick follow-up on the pending Telegram PRs: GitHub currently reports #99 (command menu), #102 (mail topics), #103 (topic icons), #105 (429 handling), #107 (visitor location/language) and #108 (widget voice messages) as individually mergeable. I have not found an unanswered review request on them.

We updated our installation to core master 8a26fa41e today. The existing Telegram fork's suggestion, reply-contract and deduplication checks pass; the mailboxes also connect and authenticate successfully after the core update.

#99 and #102 both extend the one-line bot-table CREATE statement. Once either is accepted, I can refresh the other branch to keep both fields. These remain independent proposals, so you can review whichever fits the extension first; #105 is a small reliability fix if you would like a starting point.