A build-to-order Odoo module that lets your team move and reconfigure the chatter panel — right rail, bottom drawer, or collapsed — instead of being locked to Odoo's fixed layout. Scoped, built, installed, and supported by ECOSIRE. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
App manifest
Built around your workflow
A build-to-order Odoo module that lets your team move and reconfigure the chatter panel — right rail, bottom drawer, or collapsed — instead of being locked to Odoo's fixed layout. Scoped, built, installed, and supported by ECOSIRE.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Odoo.
You go live in about 2–4 weeks, with a post-launch support window.
Odoo's chatter — the message, activity, and follower thread that lives on almost every form view — is fixed by the framework. On standard Odoo 17/18/19 it renders in a predetermined place relative to the form: a right-hand rail on wide screens, stacked below on narrow ones, with layout switching handled internally by the web client. For teams that live inside long forms all day — sales orders, manufacturing orders, project tasks, helpdesk tickets — that rigidity is a real friction. The chatter either eats horizontal space you'd rather give to the record, or it's buried below the fold where activity reminders and log notes get missed. Odoo core gives you no setting to move it, and pushing the panel around from the outside means fighting the OWL web client's own layout logic every time you upgrade.
Flexible Chatter is a module we build to order that gives you explicit control over where the chatter sits and how it behaves. Technically, it extends the FormRenderer/chatter mounting layer in the OWL web client and layers a preference model on top: a small models.Model stores per-user and per-model chatter placement (for example right, bottom, collapsed, or hidden), read at render time so each user sees their own layout without touching anyone else's. Placement can be resolved by a priority chain — user override first, then a model-level default set by an administrator, then a global fallback — so a power user on sale.order can keep the thread as a slide-out drawer while a casual user keeps it inline. We wire the preference writes through a lightweight controller/ORM call so the choice persists across sessions and devices, and we respect Odoo's existing access rules: the placement records are governed by ir.model.access.csv and record rules so a user can only read and write their own preferences.
Because this rides on the framework rather than hard-coding CSS overrides, it stays robust across the layouts Odoo already ships. We handle the responsive breakpoints (so a "right rail" gracefully becomes a bottom drawer on mobile), keep keyboard and accessibility behavior intact, and make sure the message composer, activity scheduler, follower management, and attachment previews all continue to work in the new position. The module carries a clean __manifest__.py with pinned dependencies, its OWL/QWeb template extensions are namespaced to avoid clashing with other studio or third-party customizations, and admin defaults are exposed through a normal settings view rather than requiring developer-mode edits. It works on Odoo Community and Enterprise; where Enterprise-only widgets change the chatter's surroundings we adapt the mounting logic accordingly, and we build and test against your exact edition and minor version.
Delivery is build-to-order: after a short scoping call we confirm which models the placement options apply to, which layout modes you want, and whether administrators or end users own the defaults, then we build against your target Odoo version (17.0, 18.0, or 19.0) and edition. Typical delivery is 2–4 weeks from confirmed scope, including UAT on a staging database, a rollback plan, and handover of the git repository. Pricing starts from $249 (indicative, single-company base scope); the number of models covered, multi-company preference isolation, and integration with existing web-client customizations increase the quoted scope. You get a fixed quote after the scoping call — no surprise line items.
Own the Odoo instance and want to set a sane default chatter layout per model — inline on lightweight records, drawer on heavy transactional forms — while still letting individual users override it. They need admin-level defaults without editing code in developer mode.
Live inside long `sale.order`, `purchase.order`, or manufacturing forms all day and need maximum horizontal room for line items, yet still want log notes and scheduled activities one click away rather than buried below the fold.
Work primarily out of the chatter on `project.task` and `helpdesk.ticket` — messages, activities, and followers are the job. They want the thread pinned prominently (e.g. an expanded side panel) instead of collapsed to the edge of the screen.
Roll Odoo out to mixed user bases across devices and want a supported, upgrade-safe way to control chatter placement rather than a one-off CSS hack that breaks on the next minor version, with a clean git repo they can maintain.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Chatter placement control | Right rail, bottom drawer, collapsed, or hidden — per user and per model | Whatever you build; depends on in-house skill | Usually a fixed set of positions, one behavior for everyone | |
| Per-user vs global defaults | Priority chain: user override → model default → global fallback | Possible but you design and maintain the logic | Often global-only or a single user toggle | |
| Upgrade safety | Extends the web-client layer, built and tested per minor version | Risk depends on approach; CSS hacks break on upgrade | Varies; may lag new Odoo versions | |
| Fit to your models | Targeted to the exact models and layouts you specify | Fully bespoke, at full build cost | Generic, applies broadly with little tailoring | |
| Security model | `ir.model.access.csv` + record rule scoping each user's preferences | You implement and audit access yourself | Depends on vendor; not always documented | |
| Cost & commitment | From $249 indicative; fixed quote after scoping | Typically highest — dev time from scratch | Low list price, but generic and self-supported | |
| Support & handover | Post-go-live window, docs, training, git repo handover | Only what your team documents internally | Forum/ticket support, no bespoke handover | |
| Delivery model | Build-to-order, 2–4 weeks, UAT + rollback on staging | Your project timeline and resourcing | Instant download, self-install |
This is a build-to-order module, not an instant download. After a scoping call to confirm the models, layout modes, and who owns the defaults, typical delivery is 2–4 weeks from confirmed scope. That window includes building against your exact Odoo version and edition, UAT on a staging database, and handover.
Pricing starts from $249 as an indicative from-price for a single-company base scope. The final number depends on how many models you want placement options for, whether you need multi-company preference isolation, and how much it must integrate with existing web-client customizations. You get a fixed quote after the scoping call — no open-ended billing.
Every build includes a post-go-live support window for defect fixes and configuration tweaks. Because the module extends the web-client chatter layer rather than hard-coding CSS overrides, it's designed to survive minor-version updates; when you move to a new major version (e.g. 18.0 → 19.0) we can quote a migration to rebuild and retest against it.
Yes. We build and test against your exact edition and minor version. Where Enterprise-only widgets change the chatter's surroundings, we adapt the mounting logic accordingly. We support Odoo 17.0, 18.0, and 19.0.
Both. Placement is resolved through a priority chain: a per-user override wins first, then a model-level default an administrator sets, then a global fallback. So a power user can keep the chatter as a slide-out drawer on sales orders while everyone else keeps it inline, all governed by record rules so users only edit their own preference.
We namespace the QWeb/OWL template inheritance and route preferences through a dedicated model and controller, specifically to avoid clashing with Studio or other third-party web-client customizations. During UAT on staging we verify your existing customizations and the chatter's composer, activities, followers, and attachments all continue to work before anything touches production.
Preferences live in a dedicated `models.Model` written through an ORM/controller call, so the choice persists across sessions and devices rather than only in the browser. Access is governed by `ir.model.access.csv` and a record rule that limits each user to reading and writing their own placement records.
A build-to-order Odoo module that lets your team move and reconfigure the chatter panel — right rail, bottom drawer, or collapsed — instead of being locked to Odoo's fixed layout. Scoped, built, installed, and supported by ECOSIRE.