Out of the box, Odoo Point of Sale treats access as coarse-grained: any user in the point_of_sale.group_pos_user group can typically open any configured POS, resume any open session, and browse the full backend order list under pos.order. On a busy shop floor with multiple cashiers, shifts, and locations, that creates real problems — a cashier can pick up or edit another operator's session, staff see turnover and refund history that isn't theirs, and managers lose the ability to tie a drawer to a single accountable person. Odoo's native res.groups and menu-level access controls stop at "can use POS / cannot use POS"; they do not express "this user may only touch their own sessions and orders," which is exactly the row-level boundary retail operations need. That is where the standard model runs out of road.

ECOSIRE builds a POS access-restriction module that layers row-level and configuration-level control on top of Odoo's security stack. The core mechanism is ir.rule record rules on pos.session and pos.order, evaluated against the logged-in user so that a restricted operator only sees and resumes sessions and orders they own, while managers retain a global view through a dedicated bypass group. We add a pos.config-level allow-list — an allowed_user_ids many2many (or per-config user assignment, decided at scoping) enforced both in the backend and in the POS session-opening flow — so a user can only launch the specific registers assigned to them. Access rights are declared cleanly in ir.model.access.csv and new res.groups records (for example a "POS Restricted User" versus "POS Manager" split), and the frontend is adjusted with OWL/JS overrides in the POS UI so the register picker and open-orders list respect the same boundaries the backend enforces — the restriction holds whether the user comes in through the point-of-sale interface or the pos.order backend menus.

Everything is packaged as a proper installable module: a versioned __manifest__.py depending on point_of_sale, models and any compute logic under models/ following Odoo ORM conventions (models.Model, typed fields, @api.depends/@api.constrains where server-side validation is needed to block cross-user session pickup), security artifacts, backend views in XML, and the POS OWL overrides. Because the boundary is enforced server-side through record rules — not just hidden in the UI — it also holds for programmatic access over the XML-RPC/JSON-RPC API, so an integration or script running as a restricted user is bound by the same rules. We target your exact platform: Odoo 17.0, 18.0, or 19.0, and Community or Enterprise (POS behaves differently between the two, and the OWL POS framework changed across these versions, so we build and test against your specific edition rather than shipping a one-size binary).

Delivery is build-to-order. After a short scoping call we confirm exactly how "ownership" should work for your floor — per-user, per-shift, per-register, or per-location — plus manager bypass rules and any edge cases (shared drawers, supervisor overrides, returns handled by a different operator). We then build against your Odoo version and edition, run UAT on a staging database, and install to production with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company enforcement, multiple restriction dimensions (register plus location plus shift), integration with an existing custom POS flow, or migration of historical session/order ownership data increases the quoted scope. You receive a fixed quote after the scoping call — the from-price is indicative, not a firm figure.