POS Block Incognito

Key Features

Pre-load POS boot guard: a JS/OWL hook fires before the interface renders, so no order is ever entered into throwaway storage

Multi-signal incognito detection combining a durable localStorage/IndexedDB write probe, storage-quota and persistence-API heuristics, and browser-specific fallbacks

Translatable QWeb block screen shown in place of the POS when a private/incognito context is detected, with clear operator guidance

Per-register policy via a settings model extending res.config.settings persisted against pos.config (hard block vs soft warn per POS)

Optional manager-override flow gated by group so a supervisor can consciously allow a session with a logged justification

Audit model logging every block, warn, and override event (user, pos.config, timestamp, browser signals) with list/form views

Access control through ir.model.access.csv plus record rules so only POS managers edit policy or view the audit trail

Correct point_of_sale asset-bundle registration in __manifest__.py, keeping the guard inside the supported POS extension pattern

Compatible builds for Odoo 17.0, 18.0, and 19.0, accounting for POS storage-internals and asset-pipeline changes between versions

Community and Enterprise editions both supported, respecting each edition's POS bootstrap differences

Configuration and audit records exposed over XML-RPC/JSON-RPC for external monitoring or compliance tooling

Graceful, absent-signal-safe logic: when the browser gives no conclusive signal the policy default (warn or allow) is applied deterministically, never a false hard-lock of a legitimate register

Automated action (server action) option to notify a manager or raise an alert when repeated incognito attempts occur on a register

No modification of Odoo core: shipped as an isolated addon so upgrades and other POS customisations remain unaffected

Built to order, done for you

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

You order

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

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Odoo's Point of Sale is offline-first by design: unsent orders, the paid-but-not-yet-synced queue, session context, and pricelist/product caches all live in the browser's IndexedDB and local/session storage. When a cashier opens the POS in a private/incognito window, that storage is ephemeral and siloed — orders taken during a network drop can vanish the moment the tab closes, and the session can behave as if a shift never happened. Odoo core gives you no guard for this: there is no native setting to detect the browsing mode, warn the operator, or refuse to boot the POS. Off-the-shelf listings rarely cover the current storage internals across 17.0, 18.0, and 19.0, and a DIY patch tends to break on the next point release. That gap is exactly what this made-to-order module closes.

We build a POS-side guard that runs before the interface finishes loading. On boot it probes the browser environment — attempting a durable write to localStorage/IndexedDB, inspecting storage-quota and persistence signals, and running mode-specific heuristics — to decide with high confidence whether the session is a private/incognito context. If it is, the guard interrupts the POS launch and presents a clear, translatable block screen instead of a half-initialized point of sale, so no cashier ever starts ringing up orders into throwaway storage. The behaviour is delivered as a proper Odoo POS extension: an OWL/JS component layered onto the POS bootstrap, wired through the module __manifest__.py with the correct point_of_sale asset bundles, plus QWeb templates for the block and warning views so the copy and styling match your brand.

Because policy differs per business, we make the guard configurable through server-side models rather than hard-coding it. A settings model (extending res.config.settings, persisted against pos.config) lets you choose per-register whether incognito is hard-blocked or soft-warned, customise the message, and optionally require a manager override. Access is governed by ir.model.access.csv and record rules so only POS managers change the policy, and each block/override event can be written to a logged model for audit — visible in a standard list/form view and reportable via QWeb or the read APIs. Everything is reachable over the XML-RPC/JSON-RPC API for your own tooling, and we respect Community vs Enterprise differences in the POS asset pipeline so the same policy holds on either edition.

Delivery is build-to-order. After a short scoping call we confirm your Odoo version(s), edition, register topology, and the exact block-vs-warn policy, then hand back a fixed written quote and timeline. We develop against a staging copy of your database, run UAT with your team, and deploy with a tested rollback path; typical delivery is 2-4 weeks from confirmed scope. You receive the installable source for your version, documentation, a training session, and a post-go-live support window. Pricing starts from $249 (indicative, single-company base scope); multi-company rollouts, additional POS configs with divergent policies, custom audit/reporting requirements, and support across multiple Odoo versions increase the quoted scope.

What you get

Installable module source code built and tested for your specific Odoo version(s) (17.0/18.0/19.0) and edition

Installation and configuration on your environment, including per-register policy setup on each pos.config

Technical documentation: model/field reference, asset wiring, detection logic, and configuration options

End-user and manager guide plus a live training session for cashiers and POS supervisors

Post-go-live support window for defect fixes and configuration adjustments

UAT on a staging copy of your database with a documented, tested rollback plan before production deployment

Git repository handover with tagged release and commit history for your version

Who this is for

Retail IT / POS administrator

Owns the register fleet and needs a reliable guard so staff can't accidentally run the POS in a private window and lose offline orders. Wants per-register policy, an audit trail, and a clean upgrade path across Odoo versions.

Store or operations manager

Responsible for shift integrity and cash reconciliation. Needs assurance that no sale is ever taken into ephemeral storage, plus a manager-override option for the rare legitimate case, with every override logged.

Compliance / internal audit lead

Needs evidence that data-handling controls are enforced at the point of sale. Values the logged block/override model and API access so events can be pulled into external monitoring or compliance reports.

Odoo partner / in-house developer

Maintains the Odoo deployment and wants a clean, isolated addon that follows the supported POS extension pattern, ships with source and docs, and won't break on the next point release or conflict with other customisations.

How POS Block Incognito Compares

Criterion	ECOSIRE	Custom Build	Competitor
Availability	Built to order for your version, installed and supported by us	You build it in-house from scratch	Instant download, generic build
Incognito detection quality	Multi-signal probe tuned per browser and Odoo version	Depends on your team's research and testing time	Often a single stale heuristic that drifts on updates
Per-register policy (block vs warn)	Configurable per pos.config with optional manager override	Only if you design and build the settings model	Usually one fixed global behaviour
Audit trail of events	Logged model with views, access rules, and API access	Extra work you must specify and build	Rarely included
Version & edition coverage	17.0/18.0/19.0, Community and Enterprise, tested	You maintain each version yourself	Listed versions may lag or be untested on yours
Upgrade safety	Isolated addon, no core patch, re-testable on staging	Risk of breakage you own each release	Varies; may conflict with other modules
Support & accountability	Post-go-live support window and named delivery team	Internal team only	Best-effort vendor tickets
Total cost clarity	Indicative from-price, fixed quote after scoping	Unpredictable internal effort	Low sticker price, hidden fit/maintenance cost

Frequently Asked Questions about POS Block Incognito

Is this an existing app I can download and install right now?

No. This is a build-to-order module. We build, install, and support it for your specific Odoo version and edition after you request a quotation — it is not an instant-download listing. That lets us match the detection logic and POS asset wiring to your exact 17.0/18.0/19.0 setup rather than shipping a one-size-fits-all binary.

How long does delivery take?

Typical delivery is 2-4 weeks from confirmed scope. The clock starts once we've agreed the Odoo version(s), edition, register topology, and block-vs-warn policy on a scoping call and you've approved the fixed quote. We develop against a staging copy, run UAT with your team, then deploy with a tested rollback plan.

How does pricing and scoping work?

Pricing starts from $249 as an indicative from-price for a single-company base scope. After a short scoping call we give you a fixed written quote. Drivers such as multi-company rollouts, many registers with divergent policies, custom audit/reporting, and support across multiple Odoo versions increase the quoted scope. You approve the fixed quote before we build.

What happens with support and updates after go-live?

Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because the module is delivered as an isolated addon that doesn't patch Odoo core, it survives point-release upgrades cleanly; when you move to a new major Odoo version we can re-target and re-test the build as a separate scoped engagement.

How reliable is incognito detection, and can it wrongly lock a normal register?

Detection combines several signals — a durable storage write probe, storage-quota/persistence heuristics, and browser-specific fallbacks — rather than a single test. When the browser gives no conclusive signal, the policy default you choose (warn or allow) is applied deterministically, so a legitimate register is never falsely hard-locked. You can also enable a manager-override path for edge cases.

Will it work on both Odoo Community and Enterprise, and across our versions?

Yes. We build for Odoo 17.0, 18.0, and 19.0 and support both Community and Enterprise, accounting for the POS storage internals and asset-pipeline differences between them. If you run more than one version we scope each target explicitly so the same policy behaves identically everywhere.

Does it modify Odoo core or interfere with our other POS customisations?

No core modification. It ships as a standalone addon that layers onto the POS bootstrap through the standard extension points and registers only its own assets in __manifest__.py. That keeps it compatible with your existing POS customisations and with future upgrades; we test against your staging database during UAT to confirm no conflicts.