Running several storefronts from one Odoo database sounds tidy until you try to keep each one showing the right catalog. Out of the box, a product is published or unpublished globally, and the website_id field on product.template only pins a record to a single site rather than letting you curate distinct assortments across many. Teams end up cloning products, toggling is_published by hand, or writing throwaway overrides on the website.published.mixin that break the next time the catalog changes. Add B2B requirements — where a signed-in dealer should see wholesale lines that a public visitor never should — and Odoo's native website eCommerce runs out of road. There is no first-class notion of "this SKU is visible on Site A, hidden on Site B, and restricted to these customer groups everywhere."

We build a dedicated visibility layer that treats per-website assortment and audience restriction as real, queryable data instead of a pile of manual flags. The module adds a many-to-many relation between product.template / product.public.category and website, plus an optional link to res.groups and/or a partner tag for user-based restriction. A stored computed field on the product — for example visible_website_ids, driven by @api.depends on the assortment and category rules — resolves effective visibility so the storefront controller can filter the /shop queryset in a single indexed pass rather than post-filtering in Python. Because the logic lives in the ORM, it applies consistently to the website search, category navigation, product suggestions, and the sitemap, not just the grid the shopper first lands on.

Enforcement is done the Odoo-correct way. We extend the _search_get_detail / website controller path and add ir.rule record rules keyed on the current website.get_current_website() and request.env.user, so a hidden or restricted product cannot be reached even by guessing its slug URL — the record rule denies the read, returning a clean 404 rather than a leaking 403. Category trees are pruned per site so empty branches never render, and ir.model.access.csv covers the new configuration models for the manager group. Admins get a clear management surface: list and form views (XML plus OWL widgets where a matrix helps) showing the website-by-product visibility grid, batch actions to publish or restrict an entire category to a site, and optional base.automation rules so newly created products inherit a default assortment. Everything is read/written over the standard XML-RPC and JSON-RPC API, so a PIM or middleware can drive assortments programmatically.

Because this is built to order, we start from your real database — how many websites, whether you are on Community or Enterprise (this works on both; we note where Enterprise-only website features change the approach), your pricelist and B2B rules, and any existing customizations that touch the shop. We deliver on a staging clone first, run UAT against your actual catalog, and only then schedule the production cutover with a rollback path. Typical delivery is 2–4 weeks from confirmed scope, targeting Odoo 17.0, 18.0, or 19.0. Pricing starts from $249 (indicative, single-company base scope); additional websites, deeper B2B/pricelist-driven visibility rules, multi-company record-rule design, and PIM/API integration increase the quoted scope.