- Home
- Apps
- Multichannel & PIM Tools
- Shop Product Price Visibility
Illustrative previewA build-to-order Odoo module that controls exactly who sees product prices on your website shop and eCommerce
storefront — by login state, customer group, region, or product. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.
What is Shop Product Price Visibility?
A build-to-order Odoo module that controls exactly who sees product prices on your website shop and eCommerce storefront — by login state, customer group, region, or product. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0. 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
Most B2B, wholesale, and trade sellers running Odoo eCommerce eventually hit the same wall: prices are either public to everyone or the entire storefront sits behind a portal login. Odoo core gives you no middle ground. You cannot easily say "show retail prices to guests, show negotiated prices to logged-in trade accounts, and show a Request-a-Quote button to everyone else." The native website_sale templates render list_price and pricelist-adjusted prices unconditionally in the shop grid, the product detail page, and search results — so hiding a price usually means someone hand-overrides QWeb and breaks the add-to-cart flow, structured data, and the pricelist engine in the process.
We build a purpose-made module that adds a first-class price-visibility layer on top of website_sale without forking it. The core is a small set of ORM models and configuration fields: a visibility policy stored against product.template and product.public.category, evaluated per request against the current website, the logged-in res.partner (and their commercial parent), assigned res.groups, geolocation/country, and the resolved pricelist. A compute method decorated with @api.depends on the partner, pricelist, and policy resolves — for each visitor — whether the price is shown, masked, replaced with a call-to-action, or gated behind login. We override the relevant templates through inheritance (xpath on website_sale.products_item, website_sale.product, and the cart/mini-cart) so the price node is conditionally rendered while add-to-cart, wishlist, and comparison behavior stay intact. Where a product is priced-hidden, we optionally swap the buy button for a configurable "Request a Quotation" action that feeds crm.lead or sale.order in draft.
Because visibility touches money and access, we wire it correctly at the data layer: ir.model.access.csv grants for the new configuration models, ir.rule record rules so a website manager only edits policies for their own website in multi-company/multi-website installs, and server-side enforcement so a hidden price is never leaked through the JSON-RPC//shop controllers or the product_template public read — hiding on the template alone is not enough, since a crafted request can otherwise pull the value. Admin-facing configuration lives in clean backend views (form/list) plus a settings panel, and every policy change is captured for auditability. The module ships with an automated action option to flip visibility on schedule (for example, reveal prices only during a trade-show window) and is packaged with a correct __manifest__.py declaring dependencies (website_sale, sale), data files, and version, tested against Odoo 17.0, 18.0, and 19.0 on both Community and Enterprise (Enterprise-only surfaces like advanced pricelist UI are handled gracefully when absent).
Delivery is build-to-order: it starts with a short scoping call to map your exact rules — which visitor segments, which products or categories, what the fallback should be, and how quotation requests should flow — after which we return a fixed quotation and a delivery plan. Typical delivery is one working week from confirmed scope. We build on a staging copy of your database, run UAT with you, and hand over installable source, documentation, and a git repository. Pricing starts from $999 (indicative, single-company base scope); additional websites, multi-company record-rule complexity, deep customer-group/geolocation segmentation, and quotation-workflow integration increase the quoted scope.
What you get
- Installable, commented source code for your Odoo version (17.0, 18.0, or 19.0) as a self-contained module
- Installation and configuration on your environment, including dependency and data-file setup
- Technical documentation: models, fields, record rules, template overrides, and configuration reference
- End-user guide plus a live training session for your website/catalog administrators
- UAT on a staging copy of your database with a documented rollback plan before go-live
- Post-go-live support window for defect fixes and configuration questions
- Git repository handover with full commit history and tagged release
- Manifest, security (ir.model.access.csv + ir.rule), and view files ready for your CI/deployment pipeline
Who this is for
B2B / Wholesale seller on Odoo eCommerce
Runs a public catalog for brand discovery but wants prices shown only to approved trade accounts, with everyone else seeing a quote request. Needs segment-based visibility without locking the whole shop behind login.
Website / eCommerce manager
Owns the storefront and needs a backend UI to set price-visibility rules per product or category, differentiate guests from logged-in customers, and schedule reveal windows — without editing QWeb or risking the add-to-cart flow.
Odoo partner or in-house developer
Wants a clean, upgrade-safe module that extends website_sale via inheritance, enforces visibility server-side, ships proper ir.rule security, and arrives with source, docs, and a git repo they can maintain.
Multi-website / multi-company operator
Serves different regions or brands from one Odoo instance and needs price visibility scoped per website and per company via record rules, with region/geolocation-aware rules.
How Shop Product Price Visibility Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Visitor segmentation (guest / group / region) | Full: partner, res.groups, website, country, pricelist | Possible but you design and build it all | Usually login-vs-guest only, limited group logic | None — price is public or whole shop behind login |
| Server-side enforcement (no leak via RPC) | Enforced in controllers + read paths | Only if the developer remembers to | Often template-only; value still served | N/A — price always served |
| Add-to-cart / pricelist integrity | Preserved; price node overridden in isolation | Depends on implementation quality | Sometimes breaks cart or comparison | Intact but no visibility control |
| Multi-website / multi-company scoping | ir.rule record rules per website/company | Extra effort to design correctly | Frequently single-website assumptions | Not applicable |
| Quote-request fallback on hidden price | Optional draft crm.lead / sale.order button | Buildable on request | Rarely included | None |
| Odoo 17/18/19 + Community/Enterprise | Built and tested for your exact version | Whatever you target and test | Varies; may lag new releases | Version-native but no feature |
| Fit to your exact rules | Scoped to your segments and fallback logic | Fully bespoke, at full build cost/time | Generic; adapt your process to it | No configuration for this |
| Delivery model & support | Build-to-order 2–4 wks, source + git + support window | Your team owns time, risk, and upkeep | Instant install, self-serve support only | Included but feature absent |
Frequently Asked Questions about Shop Product Price Visibility
How long does delivery take?
This is a build-to-order module, not an off-the-shelf download. Typical delivery is one working week from confirmed scope. The exact timeline is fixed in your quotation and depends on how many visitor segments, websites, and quotation-workflow integrations are involved. Simple single-website rules land toward the shorter end; multi-company, geolocation, and CRM-integrated flows toward the longer end.
How does pricing and scoping work?
Pricing starts from $999 as an indicative single-company base scope. We hold a short scoping call to map your exact rules, then send a fixed written quotation before any build begins — no surprises. Additional websites, multi-company record-rule complexity, deep customer-group or geolocation segmentation, and quotation-workflow integration increase the quoted scope.
What about support and updates after go-live?
Every build includes a post-go-live support window for defect fixes and configuration questions. Because you receive the full source and git repository, your team can maintain it, or we can provide ongoing support and version upgrades (for example moving from Odoo 17.0 to 18.0 or 19.0) under a separate agreement.
Does this work on Odoo Community or only Enterprise?
Both. The module targets Odoo 17.0, 18.0, and 19.0 on Community and Enterprise. Core visibility logic sits on website_sale and sale, which exist in Community. Enterprise-only surfaces such as advanced pricelist UI are handled gracefully when present and don't break when absent.
Won't hiding the price break add-to-cart or the pricelist engine?
No. We override only the price node through QWeb inheritance (xpath), leaving add-to-cart, wishlist, comparison, and the pricelist engine intact. On hidden-price products we can optionally swap the buy button for a 'Request a Quotation' action. Visibility is also enforced server-side, so the flow stays consistent and the hidden value is never leaked through the shop controllers.
Can prices be shown to some customers and hidden from others?
Yes — that's the core purpose. Rules evaluate the logged-in res.partner, their commercial parent, assigned res.groups, the current website, country/geolocation, and the resolved pricelist. So you can show retail prices to guests, negotiated prices to logged-in trade accounts, and a quote request to everyone else, all from one policy set.
How is this different from just editing the website theme?
A theme edit hides the price only in the template — the value is still served to the browser and readable via the JSON-RPC read paths and structured data. We enforce visibility at the data and controller layer, add proper security (ir.model.access.csv + ir.rule), and package it as an upgrade-safe module rather than a fragile template hack.
Related Modules

ShipStation Connector for Odoo (V2 API)
Build-to-order two-way Odoo-ShipStation V2 sync: multi-carrier labels, live rates, orders and tracking writeback.

Shopee Marketplace Connector (SEA)
Build-to-order Odoo connector syncing Shopee orders, listings, inventory, price and SLS logistics across multiple SEA shops.

Social Commerce Connector
A build-to-order Odoo connector that turns social storefront and live-commerce orders into real sales orders, with catalog publishing, stock reservation, fulfilment tracking and payout reconciliation. ECOSIRE scopes, builds, installs and supports it for your Odoo 17.0, 18.0 or 19.0 database.
Shop Product Price Visibility
A build-to-order Odoo module that controls exactly who sees product prices on your website shop and eCommerce storefront — by login state, customer group, region, or product. ECOSIRE scopes, builds, installs, and supports it for Odoo 17.0, 18.0, and 19.0.
- Per-visitor price-visibility resolver evaluating website, logged-in res.partner, commercial parent, res.groups membership, country/geolocation, and resolved pricelist
- Visibility policy fields on product.template and product.public.category with inheritance so a category rule cascades to its products unless overridden
- Four visibility modes per rule: show price, mask/blur value, replace with a call-to-action, or gate behind login
- QWeb template overrides via xpath on website_sale.products_item, website_sale.product, and mini-cart that conditionally render the price node without breaking add-to-cart, wishlist, or comparison
