Odoo Portal Users Cannot See Products: A Troubleshooting Guide

When Odoo portal users fail to see product information despite configured sales orders appearing, the issue often lies within record rules and access rights. This guide provides a detailed walkthrough for diagnosing and fixing such visibility problems.

Binary Buddies · 5 min read · 4 views

The Problem: Missing Product Visibility for Portal Users

A common challenge when extending Odoo functionality for external users, particularly through the portal, is ensuring they can view relevant data. Specifically, portal users may be able to access sales orders but encounter an inability to see associated product information. This discrepancy can significantly hinder the user experience, preventing them from fully understanding their orders or browsing available items. The root cause typically involves misconfigured access controls and record rules that govern data visibility.

When sales orders are visible to portal users but their corresponding products are not, it suggests that the access rules for the sale.order model are correctly set up, but those for product.template and product.product are not. This could manifest in a variety of ways, from products appearing as blank entries to entire product sections being inaccessible. Troubleshooting this requires a deep dive into Odoo's security model, paying close attention to how record rules and access rights interact.

The problem described often arises in Odoo 16 environments, where specific configurations for portal users need careful implementation. Developers frequently face this when building custom portals or extending existing e-commerce functionalities. Understanding the hierarchy and application of Odoo's security mechanisms is paramount to resolving these access-related issues effectively and ensuring a seamless experience for all user types.

Understanding Odoo's Security Model: Rules and Access Rights

Odoo employs a robust security model based on record rules and access rights to control data visibility and manipulation. Access rights define the operations (read, write, create, unlink) a user group can perform on a specific model. Record rules, on the other hand, impose further restrictions by defining specific conditions (domains) under which records of a model are accessible. For portal users, who typically operate with limited privileges, these rules must be meticulously crafted to grant access only to necessary data.

The ir.rule model in Odoo is central to defining these record rules. Each rule is associated with a model, a set of user groups (e.g., base.group_portal), and a domain that filters the records. When a portal user attempts to view a record, Odoo evaluates all applicable record rules for that model and the user's groups. If any rule prevents access, the record will not be displayed, even if general access rights permit reading the model.

In the context of product visibility, this means not only must the portal group have 'read' access to product.template and product.product, but specific ir.rule entries must also permit their retrieval. The absence of explicit rules for these product models, or rules that incorrectly filter them out, will result in the observed 'cannot see product' issue.

Troubleshooting Product Visibility with Record Rules

When portal users cannot see products, the first step is to examine the ir.rule configurations for the relevant product models: product.template and product.product. A Stack Overflow question about this problem includes example rules for these models. Note the inclusion of global='False', which signifies that the rule is not applicable globally but rather on a per-record basis or specific context. Crucially, the domain_force field determines which records are accessible.

In the asker's example, the domain_force for the product rules is set to an empty list []. This typically implies that all records of the model should be accessible, subject to other overlapping rules. If this still does not grant visibility, it suggests either a conflict with another rule or that the empty domain is not permissive enough in certain Odoo versions or configurations. Some developers attempt to use (1, '=', 1) as a domain, which is a universal positive condition, but this also failed in the asker's case.

A critical aspect often overlooked is the dependency chain. Products are frequently linked to other models, such as sale.order.line. If portal users can see sales orders but not their products, the issue might stem from an inability to traverse the relationship from the sales order line to the product itself. This indicates that, in addition to rules for product models, rules for intermediate models like sale.order.line might also be necessary.

The Role of Access Rights

While record rules refine visibility, base access rights set the foundational permissions for user groups on Odoo models. For portal users (identified by the base.group_portal group), explicit read access must be granted to the product.template and product.product models. The asker's access entries include lines like access__product_template__group_portal,access__product_template__group_portal,model_product_template,base.group_portal,1,0,0,0. The numerical values represent permissions (read, write, create, unlink).

A value of '1' in the 'read' column indicates that reading the model is permitted for that group. If the 'read' permission is '0' for the base.group_portal on product.template or product.product, then portal users will inherently be unable to see these records, regardless of the record rules configured. It is essential to verify these explicit access rights within Odoo's security settings or via XML definitions.

The asker's configuration shows conflicting access right definitions where some indicate write/create/unlink permissions, while others show none. This type of inconsistency can lead to unpredictable behavior. For portal users, typically, only read access is required for viewing products. Ensuring the portal group has a '1' for read access on these product models is a prerequisite for record rules to take effect.

Addressing Dependencies: The Sale Order Line Example

The accepted answer to the Stack Overflow question highlights a crucial point: the need to consider related models. In the context of sales orders and products, the sale.order.line model acts as the intermediary. If portal users can view the main sale.order but not the products listed within it, it's plausible that the sale.order.line model itself is not accessible or is incorrectly filtered for the portal group.

Adding a record rule for sale.order.line, as suggested, can resolve this. The answer's rule rule_portal_sale_order_line, with an empty domain_force and assigned to the base.group_portal, aims to grant read access to all sale order lines for portal users. This allows them to traverse from the sale order to its constituent lines, and subsequently, to the associated product details.

This solution underscores a general principle in Odoo development: security configurations must account for the entire data model relationships. When displaying hierarchical or linked data, ensure that access and visibility rules are applied not only to the primary models but also to all intermediary models through which the data is accessed. This layered approach is key to preventing such visibility gaps.

Where This Approach Does Not Fit

While configuring record rules and access rights is the standard Odoo mechanism for controlling data visibility, this approach has limitations. It is primarily designed for internal Odoo access control and may become cumbersome for complex, user-specific public-facing websites that require highly dynamic content filtering beyond simple group-based rules. If the requirement is to show specific product bundles or personalized product recommendations based on complex external logic, a simple ir.rule configuration might not suffice.

Furthermore, overly broad or numerous record rules can impact performance, especially on large datasets. If a portal user needs to view thousands of products, and each product fetch triggers complex rule evaluations, the user experience can degrade. In such scenarios, optimizing the rules, potentially by making them global where appropriate or by denormalizing data, might be necessary, or a completely different architectural approach might be warranted.

This method also assumes a standard Odoo setup. Customizations in the product module, or the use of third-party modules that alter product visibility or relationships, could introduce new complexities that these rules alone cannot address. Debugging then requires understanding the interplay between standard Odoo security, custom code, and third-party extensions, making the troubleshooting process significantly more intricate.

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.

  • #Python
  • #odoo
  • #odoo-16
  • #product visibility
  • #record-rules
  • #rules

Comments

Add a comment
Sign in with Google to join the conversation