Skip to main content
UI Enhancer – Save List Column Width Automatically — A build-to-order Odoo module that quietly remembers each user's list-vie — 1/1Illustrative preview

A build-to-order Odoo module that quietly remembers each user's list-view column widths and restores them on

every load, so nobody re-drags the same columns after every refresh. ECOSIRE builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.

What is UI Enhancer – Save List Column Width Automatically?

A build-to-order Odoo module that quietly remembers each user's list-view column widths and restores them on every load, so nobody re-drags the same columns after every refresh. ECOSIRE builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.

Key Features

Persists each user's list-view column widths across sessions, refreshes, filter changes, and re-login without any manual re-drag
Extends the OWL `ListRenderer` column-resize handler to capture width on drag-end rather than patching Odoo core
Stores preferences in a dedicated model (e.g. `ui.list.column.width`) keyed by `user_id`, `res_model`, view reference, and `field_name`
Per-user isolation via `ir.model.access.csv` plus a record rule scoping rows to `user_id = uid` — one user's layout never affects another's
Reads and applies saved widths before first paint so columns render at preferred size with no visible flicker or re-layout jump
Debounced write path collapses a burst of resize events into a single clean ORM save via RPC
Optional per-user 'reset to default widths' action to return any view to Odoo's computed defaults on demand
Graceful normalization of stale or out-of-range stored widths through a compute/validation layer so corrupt values are ignored, not applied
Works consistently across list views for any model you nominate — sales, inventory moves, accounting lines, CRM pipelines, or custom models
Multi-company safe: saved widths respect the active company context and never leak across companies
Version-pinned builds for Odoo 17.0, 18.0, and 19.0 handling the OWL and asset-bundle differences between releases
Clean addon packaging with its own `__manifest__.py`, assets bundle registration, and no monkey-patching of unrelated views
Optional admin-defined default layouts that seed a starting width for new users while still allowing personal overrides
Compatible with both Odoo Community and Enterprise editions of the targeted version

Built to order, done for you

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

  1. 1

    You order

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

  2. 2

    We build & install

    ECOSIRE builds, configures and installs it on your Odoo.

  3. 3

    Go live + support

    You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.

Technical Specifications

Odoo Compatibility
Odoo 17, Odoo 18, Odoo 19
Editions
Enterprise & Community
License
Licence confirmation required
Python Requirement
Python 3.10+
Database
PostgreSQL 12+

About this Product

Odoo's list views let users drag column borders to widen or narrow a field, but that resize lives only in the current browser view. The moment a record is opened and closed, a filter is applied, the page is refreshed, or the user logs in the next morning, every column snaps back to Odoo's computed default widths. For teams that live in wide list views all day — a warehouse team scanning stock.move lines, an accountant reconciling account.move.line, a sales manager working a long crm.lead pipeline — that means re-dragging the same three or four columns dozens of times a day. Native Odoo has no per-user persistence for column widths in either Community or Enterprise; the width calculation is derived from the field type and content, and there is no standard setting, ir.config_parameter, or user preference that captures a manual resize.

We build a focused UI enhancement that closes exactly that gap. On the client side we extend the list renderer (the OWL ListRenderer component and its column-resize handler) so that when a user finishes dragging a column border, the new width is captured against a stable key built from the model, the view (view_id / action context), and the field name. On the server side we add a small model — for example ui.list.column.width — with fields for user_id (defaulting to self.env.user), res_model, view_ref, field_name, and width, plus a compute/normalization layer so out-of-range or stale values are ignored gracefully. Widths are read back when the list mounts and applied before first paint, so columns render at the user's preferred size with no visible flicker or re-layout. Persistence is per-user by design, so one person widening a column never disturbs a colleague's layout.

The technical implementation stays firmly inside Odoo's supported extension surface rather than patching core. Security is enforced with ir.model.access.csv giving each internal user read/write only on their own rows, backed by a record rule scoping ui.list.column.width to user_id = uid so the store is genuinely private per user and multi-company safe. The client persists changes through the standard ORM (via RPC), so the same preferences hold whether a user is on the web client or any interface that renders the list view. We keep the write path debounced and lightweight so a burst of resizes results in a single clean save, and we add an optional per-user "reset column widths" action for when someone wants to return a view to Odoo defaults. Everything is packaged as a clean addon with its own __manifest__.py, assets bundle registration, and version-pinned builds for Odoo 17.0, 18.0, and 19.0 (the OWL and asset-bundle differences between those releases are handled in the version we ship you).

Because this is build-to-order, you are not downloading a pre-existing marketplace app. After a short scoping call we confirm which models and views should remember widths, your target Odoo version and edition, and whether you want extras such as admin-set default layouts or export/import of preferences between databases. We then build, test on a staging copy of your environment, and hand over installable source. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); broader coverage — many models and views, multi-company record-rule tuning, admin-managed default layouts, or migration of saved preferences across databases — increases the quoted scope, and you receive a fixed quote after the scoping call before any work begins.

What you get

  • Installable, version-pinned source code for your Odoo release (17.0, 18.0, or 19.0), built to your confirmed scope
  • Installation and configuration on your environment, including assets bundle registration and access-rights setup
  • Technical documentation covering the data model, record rules, client extension points, and how to add new models/views to the persistence set
  • End-user guide plus a live training session for the teams who work in the affected list views
  • UAT on a staging copy of your database with a documented rollback plan before any production change
  • Post-go-live support window for defect fixes and configuration adjustments
  • Git repository handover with full commit history and tagged release for your Odoo version

Who this is for

Operations & Warehouse Teams

Teams who spend the day in wide `stock.move` / `stock.picking` list views and lose their tuned column layout on every refresh. They need each operator's preferred widths to stick so scanning long lists stays fast.

Finance & Accounting Users

Accountants reconciling `account.move.line` and journal lists want reference, partner, and amount columns sized their way permanently, without re-dragging after every filter or record open.

Sales & CRM Managers

Managers working long `crm.lead` and `sale.order` pipelines who arrange columns for their reporting flow and want that layout restored automatically at next login.

Odoo Administrators & IT Leads

Admins who need a per-user, permission-scoped preference store that is multi-company safe, does not patch core, and can be maintained and version-migrated cleanly across 17.0/18.0/19.0.

How UI Enhancer – Save List Column Width Automatically Compares

CriterionECOSIRECustom BuildCompetitorOdoo Native
Column width persistence across sessionsBuilt-in and automatic, per user, restored before first paintPossible but you design and maintain the whole store yourselfMay persist widths but on its own fixed key schemeNone — widths reset to computed defaults every load
Per-user isolationRecord rule scopes rows to `user_id = uid`, fully privateDepends entirely on how your team writes the rulesOften global or user-level with limited controlNot applicable — nothing is saved to isolate
Scope tailored to your models/viewsChosen with you at scoping, extendable laterFully bespoke but built from scratchFixed to the vendor's assumptions, hard to narrowNo configuration exists
Core-safe implementationClean addon, extends OWL `ListRenderer`, no core patchQuality varies with your developer's disciplineUnknown until you audit the sourceN/A
Odoo 17/18/19 + Community/EnterpriseVersion-pinned build for your exact targetYou handle every version's OWL/asset differencesVersion coverage depends on the listingBehaves identically — no persistence anywhere
Support & handoverPost-go-live window, docs, training, git repo handoverOnly what you resource internallyVendor ticket queue, no source ownershipStandard Odoo support, feature not covered
Total cost & predictabilityIndicative from $999, fixed quote after scopingOpen-ended developer time and maintenanceLow list price, but rigid and no tailoringNo licence cost and no capability
Multi-company behaviourRespects active company context, multi-company safeMust be engineered and tested deliberatelyRarely designed for multi-company nuanceNot applicable

Frequently Asked Questions about UI Enhancer

How long does delivery take?

This is build-to-order, so it is not an instant download. After we agree the scope on a short call, typical delivery is one working week. Simpler single-model, single-company scopes land toward the shorter end; broad multi-model or multi-company work with admin default layouts takes longer. We confirm the timeline in writing with your fixed quote.

How does pricing and scoping work?

Pricing starts from $999 as an indicative from-price for a single-company base scope. The final number depends on how many models and views must remember widths, your edition, and extras like admin-managed defaults or cross-database preference migration. After a 15–45 minute scoping call we send a fixed quote, and no build work starts until you approve it.

What about support and future updates?

Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because we hand over the git repository and full source, your own team can maintain it too. When you upgrade Odoo — for example 18.0 to 19.0 — we can quote a version-migration pass separately, since OWL and asset-bundle internals change between major releases.

Does this modify Odoo core or is it a clean addon?

It is a clean, self-contained addon with its own `__manifest__.py`. It extends the OWL `ListRenderer` and its resize handler through Odoo's supported client extension points and adds a dedicated model for the saved widths — it does not monkey-patch unrelated views or overwrite core files, which keeps upgrades and audits straightforward.

Are the saved widths private to each user?

Yes. Each user's widths are stored against their own `user_id` and protected by `ir.model.access.csv` rules plus a record rule scoping rows to `user_id = uid`. One person resizing a column never changes anyone else's layout, and the store respects the active company context so it is multi-company safe.

Which Odoo versions and editions are supported?

We build and version-pin for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. You tell us your exact target during scoping and we deliver a build tested against that version so the OWL and asset-bundle differences are handled correctly.

Can we choose exactly which list views remember their widths?

Yes. During scoping you nominate the models and views that matter most — for instance inventory moves, accounting lines, or your CRM pipeline. We can start with a focused set and, if you want, include an admin-defined default layout that seeds sensible starting widths while still allowing each user to override them.

Request a quote

UI Enhancer

A build-to-order Odoo module that quietly remembers each user's list-view column widths and restores them on every load, so nobody re-drags the same columns after every refresh. ECOSIRE builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.

  • Persists each user's list-view column widths across sessions, refreshes, filter changes, and re-login without any manual re-drag
  • Extends the OWL `ListRenderer` column-resize handler to capture width on drag-end rather than patching Odoo core
  • Stores preferences in a dedicated model (e.g. `ui.list.column.width`) keyed by `user_id`, `res_model`, view reference, and `field_name`
  • Per-user isolation via `ir.model.access.csv` plus a record rule scoping rows to `user_id = uid` — one user's layout never affects another's

Request a Quotation

Tell us about your UI Enhancer requirements and we'll send pricing, licensing options and a tailored proposal — usually within one business day.

No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.