Odoo Portal Users Can't See Products: Troubleshooting
When Odoo portal users are unable to view product information on your website, it often stems from misconfigured access rights and record rules. This article details common failure points and provides solutions for ensuring products are visible to the correct portal users.

The Problem: Hidden Products for Portal Users
A common challenge in Odoo when exposing data to portal users is ensuring they can access not only sales orders but also the associated product details. While configuring access for sales orders might seem straightforward, product visibility often falters. This discrepancy can lead to a fragmented user experience, where customers can see their order history but lack the context of the products they purchased or are interested in. The root cause typically lies in how Odoo's security rules, specifically record rules and access rights, are applied to product models.
The issue frequently arises because product models, such as product.template and product.product, have specific access control requirements that differ from other business documents like sales orders. Simply applying a generic rule or assuming inherited access is insufficient. Without meticulously defined ir.rule entries and corresponding access control lists (ACLs) for these product models, portal users will encounter empty lists or access denied errors when attempting to view product data, regardless of whether their sales orders are correctly displayed.
Understanding Odoo's Access Control Mechanisms
Odoo employs a robust security system based on access rights and record rules. Access rights, often managed via XML by defining entries in ir.model.access.csv or directly through the UI, dictate whether a user group has permissions for basic operations like read, write, create, and unlink on a given model. For portal users (typically associated with the base.group_portal group), these settings must be explicitly defined to grant read access to product data.
Record rules (ir.rule) provide a more granular level of control by filtering the records a user can see or interact with within a model, based on specific domains. These rules can be global or specific to a model and can be applied to one or more user groups. For portal users to see products, record rules must be set up to either permit access to all relevant products or to specific products based on defined criteria, ensuring the domain allows visibility without oversharing sensitive information.
Configuring Record Rules for Products
When portal users cannot see product models, the primary suspects are the ir.rule configurations for product.template and product.product. As one Stack Overflow asker found, rules intended for sales orders may work, but replicating that success for products requires specific definitions. For instance, defining a rule like rule_portal_product_template_final_recipient with model_id pointing to product.model_product_template and assigning it to base.group_portal is a crucial step. The domain_force field is particularly important; an empty list ([]) for this field, while seemingly permissive, typically signifies that the rule should apply without further domain restrictions, effectively granting read access to all records the user group is otherwise permitted to see.
The initial attempt might involve setting domain_force to [], indicating no additional filtering beyond the base access rights. If this doesn't yield results, one might experiment with domains like (1, '=', 1), which acts as a universal 'true' condition, ensuring the rule always matches. However, the true issue often lies not in the domain's logic for visibility, but in whether the record rule itself is correctly linked to the portal group and the product model, and if any other, more restrictive rule is inadvertently overriding it. The absence of explicit rules for related models, such as sales order lines, can also break the chain of visibility.
Checking Access Rights
Beyond record rules, explicit access rights are fundamental. For portal users to even attempt to read product data, the product.template and product.product models must have read access granted to the base.group_portal group. This is often configured in Odoo's security files, typically named ir.model.access.csv, or can be managed through the UI under Settings -> Users & Companies -> Groups. An entry like access_product_template_group_portal,product.model_product_template,base.group_portal,1,0,0,0 would grant read access (the first '1') but deny create, write, and unlink (the '0's).
That Stack Overflow asker had indeed tried such access rights for product.template and product.product for the portal group. However, a common pitfall is ensuring these entries are correctly formatted and that no conflicting rules are set. For example, an implicit denial or a rule designed for internal users might take precedence if not carefully managed. Verifying that the access rights specifically permit 'read' operations for the portal group on the relevant product models is a necessary prerequisite before record rules can effectively grant visibility.
The Role of Related Models: The Sale Order Line
Sometimes, the visibility of a primary record (like a sales order) can be dependent on the visibility of its related components. In Odoo, a sales order is composed of sales order lines, which in turn link to product templates and products. If portal users can see sales orders but not their products, the missing link might be the sale.order.line model.
As the accepted answer to that Stack Overflow question demonstrates, adding a record rule for sale.order.line specifically for the portal group can resolve this. Such a rule, similar to the product rules, would have its model_id set to sale.model_sale_order_line and be assigned to base.group_portal, often with a simple domain_force of []. This ensures that the intermediate records (the order lines) are also accessible, allowing Odoo's ORM to successfully navigate from the visible sales order to its associated product details, thereby resolving the visibility issue.
Potential Pitfalls and When This Approach May Not Fit
While meticulously configuring ir.rule and access rights for product models, sales orders, and sales order lines addresses the common scenario, it's important to recognize its limitations. This approach assumes that the portal user's primary goal is to view products directly associated with their sales orders or perhaps a public catalog. If the requirement is to display products from a complex, multi-company setup, or products that require specific business logic beyond simple read access (e.g., products only available if a certain condition is met on the partner record), then a simple domain may not suffice.
Furthermore, heavily customized Odoo installations or integrations with third-party systems might introduce additional layers of access control or data visibility logic that override standard Odoo rules. In such cases, the problem might not be with the fundamental Odoo security setup but with custom code that interferes with record fetching. It's also worth noting that if the Odoo instance uses third-party modules that manage product visibility or pricing, those modules' security settings might take precedence over or interact unexpectedly with the base Odoo ir.rule configurations, requiring a deeper dive into that specific module's implementation.
This article draws on Portal users can`t see product model and an answer to it, on the Stack Exchange network, licensed under CC BY-SA 4.0.
- #ir.rule
- #odoo
- #odoo-16
- #portal users
- #product visibility
- #record-rules



Comments