Discuss Module in Odoo 19:
Internal Messaging, Channels, and Mail Gateway

Channels: Public, Private, and Group Conversations

Channels are the backbone of Discuss. They replace email distribution lists with persistent, searchable conversations that live inside Odoo. In Odoo 19, channels have been restructured under the discuss.channel model (replacing the older mail.channel alias) with three distinct types that control visibility and access.

Public Channels

Navigate to Discuss → Channels → New. Set the Privacy field to Everyone. Public channels are visible to all internal users in the channel directory. Use them for company-wide announcements, cross-department coordination, or general discussion topics. Any employee can join without an invitation.

Private Channels

Set Privacy to Invited People Only. Private channels are invisible in the directory — users can only join if explicitly added by a channel administrator. Use them for management discussions, HR-sensitive topics, or project teams that need a clean separation from the rest of the company.

Group Channels

Set Privacy to Selected Group of Users and pick a security group from the Authorized Group field (e.g., sales_team.group_sale_manager). Only members of that group can see and join the channel. This is ideal for role-based communication: all sales managers share a channel, all warehouse supervisors share another.

import xmlrpc.client

url = 'https://your-odoo.com'
db = 'production'
uid = 2  # admin
password = 'your_api_key'

models = xmlrpc.client.ServerProxy(f'{{url}}/xmlrpc/2/object')

# Create a public channel for company announcements
public_channel_id = models.execute_kw(db, uid, password,
    'discuss.channel', 'create', [{
        'name': 'Company Announcements',
        'channel_type': 'channel',
        'group_public_id': False,  # Everyone (public)
        'description': 'Official company-wide updates and news',
    }])

# Create a private channel for the finance team
private_channel_id = models.execute_kw(db, uid, password,
    'discuss.channel', 'create', [{
        'name': 'Finance Team',
        'channel_type': 'channel',
        'group_public_id': None,
        'description': 'Internal finance discussions',
    }])

# Add specific members to the private channel
user_ids = models.execute_kw(db, uid, password,
    'res.users', 'search', [[
        ('groups_id', 'in', [
            models.execute_kw(db, uid, password,
                'ir.model.data', 'check_object_reference',
                ['account', 'group_account_manager'])[1]
        ])
    ]])

for user_id in user_ids:
    models.execute_kw(db, uid, password,
        'discuss.channel', 'add_members',
        [[private_channel_id], [user_id]])

Mail Gateway Configuration: Catchall, Bounce, and Incoming Routes

The mail gateway is the bridge between external email and Odoo. It ensures that replies to outgoing Odoo emails land on the correct record (invoice, helpdesk ticket, purchase order) instead of in someone's personal inbox. In Odoo 19, this is handled by the mail module through a combination of incoming mail servers, catchall aliases, and bounce handling.

Step 1: Configure the Outgoing Mail Server

Go to Settings → Technical → Email → Outgoing Mail Servers. Create a new SMTP server with your provider's credentials. The critical fields are:

• SMTP Server: e.g., smtp.gmail.com or mail.yourdomain.com
• SMTP Port: 587 (TLS) or 465 (SSL)
• Connection Security: TLS (STARTTLS) recommended
• Username / Password: Service account credentials (not a personal mailbox)

Step 2: Configure the Incoming Mail Server

Go to Settings → Technical → Email → Incoming Mail Servers. Create a new server using IMAP (preferred) or POP3. This server will poll the catchall mailbox for new emails and route them into Odoo.

# Configure incoming IMAP server for catchall
incoming_server = models.execute_kw(db, uid, password,
    'fetchmail.server', 'create', [{
        'name': 'Catchall Inbox',
        'server_type': 'imap',
        'server': 'imap.yourdomain.com',
        'port': 993,
        'is_ssl': True,
        'user': 'catchall@yourdomain.com',
        'password': 'app_specific_password',
        'state': 'draft',
        'configuration': 'automatic',
    }])

# Activate the server
models.execute_kw(db, uid, password,
    'fetchmail.server', 'button_confirm_login',
    [[incoming_server]])

# The server will now poll every 5 minutes (default)
# Adjust interval via Settings → Technical → Automation →
# Scheduled Actions → "Mail: Fetchmail Service"

Step 3: Set Catchall and Bounce Aliases

Navigate to Settings → General Settings → Discuss. Configure the two critical aliases:

• Catchall Email Alias: catchall@yourdomain.com — receives replies to all outgoing Odoo emails. The mail.catchall.alias system parameter stores the local part (e.g., catchall).
• Bounce Email Alias: bounce@yourdomain.com — receives delivery failure notifications. Stored in mail.bounce.alias. Odoo uses the bounce address as the SMTP envelope sender to separate delivery errors from real replies.

The mail.catchall.domain system parameter must match your MX domain exactly. When Odoo sends an email from a sales order, it sets the Reply-To header to something like catchall+SO-00042@yourdomain.com. The + alias trick (subaddressing) lets a single mailbox receive replies for every record in the system. When the fetchmail service picks up this email, Odoo parses the +SO-00042 suffix and routes the reply to the correct sale order chatter.

Step 4: Email Routing — How Odoo Matches Emails to Records

Understanding the email routing pipeline is critical for debugging. When a new email arrives, Odoo processes it through the mail.thread method message_route() in this order:

1. Message-Id / In-Reply-To: If the email is a reply, Odoo matches the In-Reply-To or References header to an existing mail.message record. This is the most reliable routing method.
2. Alias matching: Odoo checks the To and CC headers for any registered mail.alias addresses. If support@yourdomain.com is an alias for the helpdesk team, the email creates a new ticket.
3. Catchall fallback: If no alias matches, the email goes to the catchall route. Odoo attempts to extract a record reference from the email address (e.g., catchall+SO-00042) and routes the message to that record.
4. Default routing: If all else fails, the email is either discarded or forwarded to a designated fallback channel, depending on your mail.default.from and alias configuration.

To debug routing issues, enable Developer Mode and check the mail.mail model for failed entries. You can also increase the mail module's log level by adding --log-handler=odoo.addons.mail:DEBUG to your Odoo startup command. This logs every step of the routing pipeline, including which headers were checked and why a particular route was selected or rejected.

Notification Preferences: Inbox vs. Email

Every Odoo user has a notification preference that determines how they receive messages: Handle by Emails or Handle in Odoo (Inbox). This setting lives under Preferences on the user's profile (res.users field notification_type).

Inbox Mode (Handle in Odoo)

Messages appear in the Discuss inbox as notifications. No emails are sent. The user must open Odoo to see new messages. This is the preferred mode for teams that work inside Odoo all day — warehouse operators, sales reps using the CRM, support agents on helpdesk. It eliminates email overload and keeps the conversation inside the ERP.

Email Mode (Handle by Emails)

Every Odoo notification generates an email. The user receives messages in their external inbox (Gmail, Outlook, etc.) and can reply directly — the mail gateway routes the reply back to the correct record. This mode is better for users who don't live in Odoo: executives who check email but rarely log into the ERP, external partners with portal access, or field workers who rely on their phone's email app.

The notification_type field is set per user, but you can enforce a default for new users via a server action or by overriding the _default_notification_type method on res.users. In Odoo 19, the Discuss module also respects subtype subscriptions — a user following a record can choose which subtypes trigger notifications (e.g., "only notify me on status changes, not on every internal note").

Subtype Subscriptions and Follower Management

When a user follows a record (sale order, project task, helpdesk ticket), they subscribe to all default subtypes. But most users do not need every notification. On the record form, click the followers section, then the pencil icon next to a follower's name. A dialog shows checkboxes for each subtype: "Discussions," "Activities," "Note," and model-specific subtypes like "Stage Changed" or "Rating Received." Unchecking a subtype stops that category of notification for that follower on that record.

For bulk management, use the message_subscribe() method with the subtype_ids parameter. This is useful when you want to auto-subscribe users to new records with a limited set of subtypes — for example, subscribing all sales managers to new quotations but only for the "Quotation Confirmed" subtype.

Channel Moderation and Message Control

For large organizations or public-facing channels, moderation prevents noise and off-topic messages from overwhelming the conversation. Odoo 19 includes built-in moderation controls on channels through the moderation field on discuss.channel.

Enabling Moderation

Open a channel, go to the Settings tab, and enable Moderation. Add moderators by selecting users in the Moderators field. When moderation is active, messages from non-moderator members are held in a pending queue until a moderator approves, rejects, or discards them.

Moderation Options

Moderators see a banner at the top of the channel showing the number of pending messages. For each message, the moderator can:

• Accept: Publish the message to all channel members
• Reject: Delete the message and optionally send a rejection explanation to the author
• Discard: Silently remove the message without notification
• Allow: Whitelist the author so their future messages bypass moderation
• Ban: Block the author from posting in the channel entirely

Moderation is particularly useful for channels linked to external email aliases. If a channel receives messages from an alias (e.g., info@yourdomain.com), spam emails will appear as pending messages instead of polluting the channel feed. Moderators review and approve only legitimate messages.

Automated Moderation with Scheduled Actions

For channels with high message volume, manual moderation is not sustainable. You can create a scheduled action (ir.cron) that automatically processes the moderation queue based on rules: auto-discard messages older than 48 hours, auto-accept messages from whitelisted domains, or auto-reject messages containing specific keywords.

from odoo import models, fields, api
from datetime import timedelta


class DiscussChannelModerationCron(models.Model):
    _inherit = 'discuss.channel'

    def _cron_auto_moderate_pending(self):
        """Auto-discard pending messages older than 48 hours
        and auto-accept messages from trusted domains."""
        cutoff = fields.Datetime.now() - timedelta(hours=48)
        trusted_domains = ['@yourdomain.com', '@partner.com']

        # Find all pending moderation messages
        pending_msgs = self.env['mail.message'].search([
            ('moderation_status', '=', 'pending_moderation'),
        ])

        for msg in pending_msgs:
            # Auto-accept from trusted domains
            if msg.email_from and any(
                domain in msg.email_from
                for domain in trusted_domains
            ):
                msg._moderate_accept()
                continue

            # Auto-discard if older than 48 hours
            if msg.create_date <= cutoff:
                msg._moderate_discard()

        # Log summary
        accepted = len(pending_msgs.filtered(
            lambda m: m.moderation_status == 'accepted'
        ))
        discarded = len(pending_msgs.filtered(
            lambda m: m.moderation_status == 'rejected'
        ))
        _logger.info(
            'Auto-moderation: %d accepted, %d discarded',
            accepted, discarded,
        )