Mobile Messaging Integration - Base Framework for Odoo Discuss

Key Features

Provider-agnostic abstract gateway base class (models.Model) that channel modules subclass — one integration contract, many providers

New ORM models for message envelope, delivery status and per-channel gateway configuration, fully persisted and auditable

Native mail.thread / mail.message integration so mobile messages log into the same record chatter as email and internal notes

@api.depends computed message-state fields (queued, sent, delivered, failed) with stored history

Webhook controller endpoint for inbound messages and asynchronous delivery-receipt callbacks

Outbound send API callable from other modules and over XML-RPC / JSON-RPC for programmatic enqueueing

ir.model.access.csv access rights plus dedicated security groups for gateway config vs message-log viewing

Multi-company record rules so message logs and gateway credentials stay scoped per company

Automated-action / server-action hooks to trigger sends on record state changes (e.g. order confirmed, ticket resolved)

Configurable retry and failure-state handling with error messages surfaced on the message record

QWeb templates for message-body rendering so content stays maintainable and translatable

Clean __manifest__.py with minimal dependencies (base, mail) — installs on Community or Enterprise

Credential storage handled via Odoo config/parameters rather than hard-coded values, kept out of logs

OWL-ready view structure and XML list/form views for configuration and message-log inspection

Compatible and tested against Odoo 17.0, 18.0 and 19.0

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Most teams that run Odoo eventually hit the same wall: customer conversation lives in one place (Discuss, mail.thread, the chatter) while the channel customers actually reply on — their phone — lives in a disconnected mobile app or a browser tab nobody logs. Sales confirmations, delivery notices, service updates and one-off replies get copy-pasted by hand, or worse, never reach the record they belong to. Odoo core gives you email and internal messaging, but out of the box it has no notion of an outbound/inbound mobile messaging gateway, no delivery-state tracking, and no clean abstraction layer to bolt a third-party provider onto. That is exactly the gap this base module fills.

This is the foundation layer — a deliberately provider-agnostic base module that gives your Odoo the reusable scaffolding every mobile-messaging feature depends on. Technically, we ship a new set of ORM models (models.Model) for message envelopes, delivery status and per-channel configuration, wired into the existing mail.thread / mail.message backbone so a mobile message logs into the same chatter timeline as email and notes. The module defines a mailing.gateway-style connector interface (an abstract base you subclass per provider), outbound send methods, a webhook controller endpoint for inbound and delivery-receipt callbacks, and @api.depends computed fields for message state (queued, sent, delivered, failed). Everything is exposed through the standard XML-RPC/JSON-RPC API so external systems and your other custom modules can enqueue messages programmatically.

Because it is the base, it is built to be extended rather than to lock you in. The __manifest__.py declares clean dependencies (mail, base) and no heavyweight extras, so it installs on Community or Enterprise. Security is real, not an afterthought: dedicated groups plus ir.model.access.csv entries and record rules scope who can view message logs and who can configure gateways — with multi-company record rules where you run more than one company. We include the views (XML list/form for configuration and message logs, an OWL-friendly structure ready for later interactive widgets), an automated action / server-action hook so other modules can trigger sends on state changes, and optional QWeb templates for message-body rendering. The result is a stable, documented contract that your team — or a future ECOSIRE feature module — can build channel-specific behavior on without re-plumbing the fundamentals.

Delivery is build-to-order. After a short scoping call we confirm exact scope in writing — your Odoo version (17.0, 18.0 or 19.0), Community vs Enterprise, which provider gateway you intend to connect, single- vs multi-company, and any data or workflow specifics. We then build against a staging copy of your database, run UAT with you, and only deploy to production with a documented rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company topology, additional provider integrations, deeper localization, and data-migration volume increase the quoted scope. You always get a fixed written quote after the scoping call — never a surprise.

What you get

Installable source code for the base module, built and tested for your exact Odoo version (17.0 / 18.0 / 19.0) and edition

Installation and configuration on your staging environment, then production deployment

Technical documentation covering models, the gateway interface, webhook endpoint and extension points

End-user / admin guide plus a live training session for your team

UAT on a staging copy of your database with a documented rollback plan before go-live

Post-go-live support window for defect fixes and configuration questions

Git repository handover with full commit history and tagged release

Version-compatibility notes and upgrade guidance for future Odoo releases

Who this is for

Odoo administrator / internal Odoo team

Runs Odoo in-house and wants a clean, documented base layer to build mobile-messaging features on, rather than hacking a one-off script into an existing module. Needs proper models, security and an extension contract they can maintain.

Operations or customer-service lead

Wants outbound notifications and inbound replies to land on the right Odoo record in the chatter, so the team stops copy-pasting between a phone app and Odoo. Cares about delivery-state visibility and audit trail.

Odoo implementation partner / systems integrator

Delivering a project for their own client and needs a reliable, provider-agnostic messaging foundation they can extend per provider. Values the abstract gateway interface, git handover and version compatibility across 17/18/19.

Multi-company / multi-brand operator

Runs several companies in one Odoo database and needs message logs and gateway credentials scoped per company via record rules, with a base that supports that topology from day one.

How Mobile Messaging Integration - Base Framework for Odoo Discuss Compares

Criterion	ECOSIRE	Custom Build	Competitor
Fit to your setup	Built to your exact version, edition and provider intent	Fully bespoke but you specify and own everything	Generic; you adapt your process to it
Mobile gateway abstraction	Provider-agnostic abstract base class to subclass	Only if you design it that way	Often hard-wired to one provider
Chatter / mail.thread integration	Logs into the record chatter natively	Depends on developer discipline	Varies; sometimes a siloed log
Security model	Dedicated groups, ir.model.access.csv, multi-company record rules	As good as you build it	Baseline access rules, rarely multi-company
Delivery-state tracking	Computed state fields + webhook receipts	Build from scratch	Basic or absent
Extensibility for future features	Documented contract designed to be extended	Yours to maintain	Hard to extend cleanly
Ongoing cost & support	Fixed quote + post-go-live support window	Full dev cost + you own maintenance	Licence/subscription, generic support
Handover	Full source, git repo, docs, training	Whatever your team documents	Compiled/limited-source, docs vary

Frequently Asked Questions about Mobile Messaging Integration - Base Framework for Odoo Discuss

Is this a ready-made app I can download and install right now?

No. This is a build-to-order engagement, not an existing marketplace download. ECOSIRE builds the module against your specific Odoo version, edition and requirements, then installs and supports it. You receive installable source code and a git repository, but it is produced for your scope — not pulled off a shelf.

How long does delivery take?

Typical delivery is 2–4 weeks from confirmed scope. The clock starts once we finish the scoping call and you sign off the written scope. Simpler single-company builds land toward the shorter end; multi-company topology, extra provider integrations or data migration extend it.

How does pricing and scoping work?

Pricing starts from $249 as an indicative from-price for a single-company base scope. We never quote a firm price before understanding your setup. After a short scoping call we send a fixed written quote; drivers such as multi-company, additional integrations, localization depth or migration volume adjust it. The indicative price is a starting point, not the final figure.

What do I get for support and updates after go-live?

Every engagement includes a post-go-live support window for defect fixes and configuration questions, plus version-compatibility notes. Because we hand over the full git repository and technical docs, your team can maintain it too. Longer-term maintenance or upgrades to a new Odoo major version can be arranged as a separate scoped engagement.

Does it work on Odoo Community or only Enterprise?

The base module depends only on core `base` and `mail`, so it installs on both Community and Enterprise. We confirm your edition during scoping and test against it. It is built and validated for Odoo 17.0, 18.0 and 19.0.

Which messaging provider does it connect to?

The base module is deliberately provider-agnostic — it ships an abstract gateway interface designed to be subclassed per provider. Connecting a specific provider (credentials, endpoint, message format) is done as a channel layer on top of this base, which we scope with you. We describe capability generically; the base gives you the reusable foundation either way.

How do you deploy without breaking my live Odoo?

We build and test on a staging copy of your database, run UAT with you against it, and only then deploy to production — with a documented rollback plan in hand. Additive ORM models and access rules mean the change is contained and reversible.