[18.0][ADD] mail_gateway_telegram_standalone: New Module - Telegram Bot Integration

[AnmollGarg]

This PR introduces the mail_gateway_telegram_standalone module for Odoo 18.0.

Following the architectural advice from previous reviews in the sale-workflow repository (OCA/sale-workflow#3664), I have implemented this as a standalone base module within social. This provides a reusable engine for Telegram integrations across the ecosystem.

Key Features

• Bot Configuration: Secure storage for Bot Tokens.
• Auto-Discovery: A "Fetch Chats" feature that uses the /getUpdates Telegram API to automatically populate authorized Chat IDs.
• generic API: Provides a send_message() method that other modules (Sales, Purchase, etc.) can call easily.
• Odoo 18 Ready: Removed deprecated field parameters and implemented the latest UI components like rainbow_man.

@rousseldenis, @pedrobaeza, and @alexey-pelykh

[AnmollGarg]

Hey @rousseldenis @pedrobaeza @alexey-pelykh - could you take a look at this when you have a chance? It’s the Telegram base module we talked about.

[pedrobaeza]

I'm wondering: why not using mail_gateway_telegram?

[AnmollGarg]

I'm wondering: why not using mail_gateway_telegram?

mail_gateway_telegram handles chat with customers, while this sends outbound alerts to the chat.

[pedrobaeza]

In fact, you can use it as you want. Check for example #1796, where we add the possibility for automations, and programatically sending of messages (this time, for WhatsApp, but it can be done the same for Telegram).

[AnmollGarg]

In fact, you can use it as you want. Check for example #1796, where we add the possibility for automations, and programatically sending of messages (this time, for WhatsApp, but it can be done the same for Telegram).

Thanks for the feedback, @pedrobaeza. I want to make sure I’m heading in the right direction before I refactor.

Is the following logic correct for the OCA standard?

Inheritance: I will change the module to inherit from mail_gateway_telegram.

Feature Set: I noticed the 'Update Webhook' button in the existing module. My 'Fetch Chats' logic uses getUpdates to proactively populate authorized Chat IDs. I propose adding this as a 'Discovery' feature alongside the existing webhook setup.

Use Case: I will provide a simplified send_message API. This allows other functional modules (like sale or purchase) to send outbound alerts to these discovered chats without needing the full mail-thread overhead.

Does this sound like the right architectural approach for Odoo 18.0?

[pedrobaeza]

Well, I think you can expand mail_gateway for allowing that message sending without chatter basic API, and make use of all the already built tools, just ignoring that part.

[AnmollGarg]

Well, I think you can expand mail_gateway for allowing that message sending without chatter basic API, and make use of all the already built tools, just ignoring that part.

Hi @pedrobaeza,

I've refactored the module to extend mail_gateway as suggested.

However, during testing, I found that the "Fetch Chats" feature (getUpdates) fails when a Webhook is active, as Telegram doesn't allow both simultaneously.

How would you suggest avoiding this conflict to stay aligned with OCA standards?

[pedrobaeza]

I would say to issue an exception in that case

[AnmollGarg]

Hi @pedrobaeza,

Thanks for the guidance. I have just pushed the refactored code:

Inheritance: The module now correctly extends mail_gateway.

Conflict Handling: As suggested, I've implemented a check so that if a Webhook is active, the "Fetch Chats" (getUpdates) method will raise a UserError/Exception explaining that Telegram doesn't support both simultaneously.

Ready for your review whenever you have a moment!

[pedrobaeza]

Thanks for all the changes. I think the only thing that rests is to rename the module to accommodate it to the new structure. mail_gateway_telegram_standalone for example may server, or if you have a better name starting with mail_gateway_telegram.

[AnmollGarg]

Thanks for all the changes. I think the only thing that rests is to rename the module to accommodate it to the new structure. mail_gateway_telegram_standalone for example may server, or if you have a better name starting with mail_gateway_telegram.

Hi @pedrobaeza,

That makes sense. Given that this module now serves as the foundation for others (providing the core API and discovery tools for modules like sale_telegram or purchase_telegram), what do you think about mail_gateway_telegram_base?

If that works for you, I'll go ahead and perform the rename!

[pedrobaeza]

I don't like too much base word, as it's too much ambiguous. In fact, any parent module may be base of the dependent ones. That's why I used standalone for specifying that this doesn't require chatter.

[AnmollGarg]

I don't like too much base word, as it's too much ambiguous. In fact, any parent module may be base of the dependent ones. That's why I used standalone for specifying that this doesn't require chatter.

Understood. I will proceed with your suggestion and rename the module to mail_gateway_telegram_standalone. I'll update the manifest and all internal references accordingly and push the changes shortly. Thanks for the guidance!

[AnmollGarg]

Hi @pedrobaeza, I've updated the module name to mail_gateway_telegram_standalone. Please review when you have a moment. Thanks!

[AnmollGarg]

@rousseldenis PTAL? Thanks!

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[pedrobaeza]

/ocabot merge nobump

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 18.0-ocabot-merge-pr-1824-by-pedrobaeza-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 66251e2. Thanks a lot for contributing to OCA. ❤️