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 one working week 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 $999 (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.