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 $249.00 USD; request a quote for a scoped proposal.
App manifest
Built around your workflow
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.
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.
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 2–4 weeks from confirmed scope. Pricing starts from $249 (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.
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.
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.
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.
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.
| 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 | |
| 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 | |
| Audit trail | Session log with termination reason for evidence packs | Only if you scope and build logging yourself | Usually none or minimal | |
| 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 | |
| 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 | |
| Upgrade & maintenance | Clean module + git handover + support window | You maintain and re-test on every upgrade | Depends on a third-party's release cadence | |
| User experience on timeout | Optional keep-alive warning + clean re-login redirect | Depends entirely on your build | Often a hard, unwarned logout | |
| Delivery & accountability | Scoping, UAT, rollback, install, and support by ECOSIRE | Internal effort and risk on your side | Self-install download, support varies |
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.
This is a build-to-order module. After a confirmed scope, typical delivery is 2–4 weeks. 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.
Pricing starts from $249 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.
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.
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.
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.
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.
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.