- Home
- Apps
- SaaS Tools
- Inactive Sessions Timeout
Illustrative previewA build-to-order Odoo module that automatically expires inactive user sessions after configurable idle delays,
per user group and access context.
ECOSIRE designs, builds, installs, and supports it for your Odoo 17, 18, or 19 environment.
What is Inactive Sessions Timeout?
A build-to-order Odoo module that automatically expires inactive user sessions after configurable idle delays, per user group and access context. ECOSIRE designs, builds, installs, and supports it for your Odoo 17, 18, or 19 environment. 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
Built to order, done for you
No DIY setup — a working app, built, installed and supported by ECOSIRE.
- 1
You order
Start with a one-time build price. We scope it with you at kickoff.
- 2
We build & install
ECOSIRE builds, configures and installs it on your Odoo.
- 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
Every logged-in Odoo user who walks away from a warehouse terminal, a shared POS workstation, or an unlocked laptop is a standing security exposure. Odoo core keeps a session alive on a long-lived session_id cookie and, by default, does not force-close a session purely because the user stopped interacting — the standard session-timeout setting behaves more like an absolute cookie lifetime than a true idle timer. For teams under SOC 2, ISO 27001, HIPAA, GDPR, or internal-audit pressure, "the screen just stays logged in" is a finding waiting to happen, and native controls run out of road exactly where auditors look hardest: no per-group idle policy, no distinction between an accountant's browser and a public-facing kiosk, no forced re-authentication, and no record of why a session ended.
Inactive Sessions Timeout is a made-to-order Odoo module we build to close that gap. At its core it tracks last-activity time per session and expires sessions that exceed a configurable idle delay, independent of the absolute cookie lifetime. We implement a lightweight activity heartbeat in OWL/JS on the web client that stamps a server-side last_activity value against a session-tracking model (an ORM models.Model with proper ir.model.access.csv entries and record rules), plus an overridden authentication/dispatch layer that checks elapsed idle time on each request and cleanly invalidates the session — redirecting to the login screen — once the threshold is crossed. Idle delays are data-driven configuration: a global default on res.config.settings, with optional overrides per res.groups so that, for example, finance users time out after 5 minutes while back-office planners get 30. A scheduled action (ir.cron) sweeps and garbage-collects stale server-side session records so the store never bloats.
Because it is built rather than bought off a shelf, we scope it to your real threat model. Common extensions we implement include a client-side "you will be logged out in N seconds" warning dialog with a keep-alive button, exemptions for long-running background tabs or specific automated integrations, tighter rules for POS and public kiosks, separate handling for the JSON-RPC/XML-RPC API surface (which uses API keys or session auth differently from the interactive web client), and an audit log capturing session start, last activity, and reason-for-termination for your evidence pack. Everything is delivered as a clean, installable module with a versioned __manifest__.py, respecting Community vs Enterprise differences and tested against your target Odoo 17.0, 18.0, or 19.0.
Delivery is build-to-order: it starts with a short scoping call to confirm your idle-delay policy matrix, which user groups and access contexts are in play, and any compliance evidence you need. We then build on a staging copy of your database, run UAT with you, and deploy to production with a rollback plan and a git repository handover. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company idle policies, POS/kiosk hardening, API-surface handling, and deeper audit-logging or SIEM integration increase the quoted scope.
What you get
- Installable source code for your Odoo version (17.0, 18.0, or 19.0) as a clean module with a versioned `__manifest__.py`
- Installation and configuration on your environment, including the idle-delay policy matrix and per-group overrides
- Technical documentation: models, security rules, cron, dispatch overrides, and configuration reference
- End-user and administrator guide plus a live training session for your admins
- Post-go-live support window for defect fixes and configuration adjustments
- UAT on a staging copy of your database with a documented rollback plan
- Git repository handover with full commit history and tagged release
- Session audit-log setup and a sample compliance evidence export
Who this is for
IT Security & Compliance Lead
Owns SOC 2 / ISO 27001 / HIPAA controls and needs demonstrable, per-role idle-session expiry with an audit trail. Native Odoo's absolute-lifetime timeout doesn't satisfy the control, and they need documented evidence for auditors.
Odoo System Administrator
Manages the production instance and shared workstations. Wants a configurable, low-maintenance timeout with a cron sweep and admin force-logout, without hand-patching core on every upgrade across 17/18/19.
Operations Manager (Retail / Warehouse / Clinic)
Runs shared POS terminals, warehouse scanners, and front-desk kiosks where staff walk away mid-shift. Needs short, non-overridable idle windows on public devices while office staff keep longer sessions.
Finance / Back-Office Team Lead
Handles sensitive accounting and payroll data and wants stricter timeouts for their group specifically, with a keep-alive warning so long data-entry sessions aren't lost without notice.
How Inactive Sessions Timeout Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Idle vs absolute expiry | True last-activity idle timer enforced server-side | Whatever you build; easy to conflate with cookie lifetime | Often a single global idle value, limited nuance | Behaves mostly as absolute session-cookie lifetime |
| Per-group / context policies | Per-`res.groups` overrides + POS/kiosk/API profiles | Possible but you design and maintain it all | Rarely more than one or two tiers | Single global value, no per-role control |
| Audit trail | Session log with termination reason for evidence packs | Only if you scope and build logging yourself | Usually none or minimal | No session-termination audit trail |
| Fit to your threat model | Scoped to your compliance and device landscape | Fully bespoke but on your engineering time | Fixed feature set, take it or leave it | Generic, one-size default |
| Odoo 17/18/19 & edition fit | Built and tested for your exact version and edition | Your team owns cross-version testing | May lag new majors or assume one edition | Version-bound to core behavior |
| Upgrade & maintenance | Clean module + git handover + support window | You maintain and re-test on every upgrade | Depends on a third-party's release cadence | Moves only when core changes |
| User experience on timeout | Optional keep-alive warning + clean re-login redirect | Depends entirely on your build | Often a hard, unwarned logout | Session simply becomes invalid |
| Delivery & accountability | Scoping, UAT, rollback, install, and support by ECOSIRE | Internal effort and risk on your side | Self-install download, support varies | Included but limited to core capability |
Frequently Asked Questions about Inactive Sessions Timeout
How is this different from the session timeout already in Odoo settings?
The native setting behaves largely as an absolute session-cookie lifetime — it expires a session after a fixed period regardless of activity, and it is a single global value. This module tracks real last-activity time server-side and enforces true idle expiry, with per-group policies, warning dialogs, POS/kiosk profiles, API-surface handling, and an audit trail that native controls don't provide.
What is the delivery lead time?
This is a build-to-order module. After a confirmed scope, typical delivery is one working week. That covers building on a staging copy of your database, UAT with your team, and a production deployment with rollback. It is not an instant apps.odoo.com download — we build, install, and support it for you.
How does pricing and scoping work?
Pricing starts from $999 as an indicative from-price for a single-company base scope. We hold a short scoping call to confirm your idle-delay matrix, groups, and compliance needs, then send a fixed written quote. Drivers such as multi-company policies, POS/kiosk hardening, API-surface handling, and deeper audit-logging or SIEM integration increase the quoted scope.
Will it work with our Odoo version and Community vs Enterprise?
Yes. We build and test against Odoo 17.0, 18.0, or 19.0 as needed, and account for Community vs Enterprise differences in the web client and settings surface. We confirm your exact version and edition during scoping so the delivered module is targeted, not a lowest-common-denominator build.
Will timing out interactive sessions break our XML-RPC / JSON-RPC integrations?
No. Interactive web sessions and the API surface are handled distinctly. API-key-authenticated integrations are governed separately from browser sessions, and specific service accounts or automations can be whitelisted so background jobs keep running while human sessions still expire on idle.
What support and updates do we get after go-live?
Every build includes a post-go-live support window for defect fixes and configuration adjustments, plus full technical documentation and a git repository handover. Beyond that window, we offer ongoing support and version-migration (for example moving the module to a newer Odoo release) as a scoped follow-on engagement.
Can different teams have different timeout durations?
Yes. Idle delays are data-driven: a global default plus per-`res.groups` overrides, resolved to the strictest applicable rule per user. Finance can time out in 5 minutes while planners get 30, and shared POS or kiosk devices can be given short, non-overridable windows independent of the user's group.
Related Modules

iDEAL & Bancontact Local Checkout for Odoo
Native iDEAL bank-select & Bancontact QR checkout for Benelux Odoo stores. PSP-agnostic, webhook-reconciled, refund-ready. Built to order.

Image Preview Widget
A build-to-order Odoo widget that lets users preview images directly inside form, list, and kanban views without downloading them or opening a new tab. ECOSIRE builds, installs, and supports it for your Odoo 17.0/18.0/19.0 database.

India GSTR Filing & GSTR-2B Reconciliation
File GSTR-1 and reconcile GSTR-2B input tax credit against vendor bills directly inside Odoo. Built, installed and supported by ECOSIRE.

India Payroll (PF, ESI, PT, TDS)
Build-to-order Odoo India payroll: PF, ESI, Professional Tax & TDS automation with Form-16, challan and ECR exports.
Inactive Sessions Timeout
A build-to-order Odoo module that automatically expires inactive user sessions after configurable idle delays, per user group and access context. ECOSIRE designs, builds, installs, and supports it for your Odoo 17, 18, or 19 environment.
- Server-side per-session `last_activity` tracking on a dedicated ORM model, decoupled from the absolute session-cookie lifetime so true idle expiry is enforced rather than approximated
- Configurable global idle-timeout delay stored on `res.config.settings`, editable without touching code or redeploying
- Per-`res.groups` idle-policy overrides (e.g. finance 5 min, planners 30 min) resolved to the strictest applicable rule per user
- OWL/JS activity heartbeat in the web client that stamps last-activity on real interaction (mouse, keyboard, navigation) while ignoring passive background polling