Teams that live in Dropbox but run operations in Odoo end up maintaining two parallel filing systems. A signed contract gets dropped into a Dropbox client folder, then re-uploaded as an ir.attachment on the sales order; a QC photo sits in Dropbox but the manufacturing order references nothing. Odoo's native attachment model stores files in the PostgreSQL filestore (or an S3-style backend if you configure ir_attachment storage), but it has no concept of Dropbox — no two-way sync, no per-record folder mapping, and no way to hand a customer a Dropbox shared link straight from a record. Beyond a certain document volume the filestore also bloats backups, and finance/legal want the canonical copy to live where the rest of the company already collaborates: Dropbox.

This is a build-to-order module that ECOSIRE designs, builds and installs against your database — not an existing apps.odoo.com download. We add a Dropbox connection layer wired to the Dropbox HTTP API v2 with OAuth2 (short-lived access tokens plus a stored refresh token, encrypted in ir.config_parameter). Attachments are intercepted at the ir.attachment ORM level via overridden create/write, so any file added to a mapped model — a sale.order, project.task, hr.employee, whatever your scope names — is pushed to Dropbox and linked back by a stored dropbox_path / dropbox_file_id on a companion model. A models.Model mixin exposes compute fields (@api.depends) for sync status and the current shared link, and the folder path per record is generated from a configurable template (for example /Odoo/Sales/{partner}/{name}).

Technically, sync runs through Odoo's scheduler: an ir.cron automated action reconciles changes both ways using Dropbox cursors/deltas, so files added in Dropbox appear as Odoo attachments and vice versa, with conflict handling and per-model selective-sync toggles. Access is governed by ir.model.access.csv plus record rules so only entitled users trigger syncs or mint shared links; a settings page (Odoo res.config.settings OWL/XML view) holds the OAuth connection, folder templates and the selective-sync matrix. Everything is exposed over the standard XML-RPC/JSON-RPC API too, so external systems can query a record's Dropbox link. Where you want offloading, large attachments are uploaded to Dropbox and the local filestore copy is dropped, with the record still serving the file through a proxied download or the shared link — shrinking your Odoo backups. The build works on Community and Enterprise; we flag the handful of places (e.g. Documents app overlap on Enterprise) where behavior differs and scope accordingly.

Delivery is build-to-order. We start with a short scoping call to pin down exactly which models sync, your folder-naming convention, offload policy and Community-vs-Enterprise target, then confirm the scope in writing. Typical delivery is one working week from confirmed scope. You get the installable source for your Odoo version, UAT on a staging database, a rollback plan, technical and user documentation, a training session, and a post-go-live support window — plus the git repository so the code is yours to keep.