Odoo V19 res.partner Rule Errors with Chatter

The Problem with Restrictive Partner Rules

When implementing custom security rules in Odoo, particularly for the res.partner model, developers often encounter an unexpected error when users attempt to open a partner form view. This error, typically manifesting as Failed to write field res.partner.message_partner_ids, indicates that a user lacks the necessary read access to certain partner records. This is not due to a direct attempt to modify partner data, but rather an indirect consequence of Odoo's internal mechanisms, specifically the chatter functionality.

The root cause lies in the interaction between a strictly defined ir.rule on res.partner and the chatter's message_partner_ids field. This field, used for managing followers and notifications, often includes internal users or other contacts that may not satisfy the criteria of the custom rule. Consequently, when the chatter attempts to read these related records, the ir.rule blocks access, leading to the error and preventing users from accessing the partner form, even if they should otherwise have permission.

This issue can be particularly frustrating because the error message, while informative about the lack of access, doesn't immediately point to the chatter as the culprit. Users with the sales_team.group_sale_salesman group, for instance, might correctly see only the partners they are assigned to, but then face a hard crash when trying to open any partner's form view, thanks to the chatter attempting to access records outside their permitted scope.

Understanding the Mechanism of Failure

The ir.rule in this case aims to restrict access to res.partner records based on the user_id field, linking it to the sales_team.group_sale_salesman group. The domain [('user_id', 'in', user.id)] is intended to ensure a salesman only sees partners associated with them. However, this rule is applied globally to all read and write operations on res.partner, including those initiated by Odoo's core features.

When a partner form view is opened, Odoo's UI and backend logic trigger various processes, including the loading of the chatter. The chatter populates its message_partner_ids field by querying res.partner records that are involved in the partner's communication history or are set as followers. If these queried partners do not match the ir.rule's domain (e.g., they are internal users or belong to a different salesman), the user performing the action will be denied read access to them.

The specific error Failed to write field res.partner.message_partner_ids is somewhat misleading; it’s the underlying read operation on message_partner_ids that fails, preventing the form from loading correctly. This failure cascades, blocking the user from interacting with the partner record entirely. The error message explicitly lists Access only own documents (partner) as the blocking rule, highlighting the conflict.

Correcting Domain Syntax

A minor but important point in troubleshooting such issues is ensuring the correct syntax for Odoo's domain expressions. The domain [('user_id', 'in', user.id)] might be syntactically incorrect or less idiomatic than desired for a single user. A more standard and explicit way to refer to the current user's ID in a domain is [('user_id', '=', user.id)].

While Odoo's flexibility sometimes allows in with a single-element list to function similarly to =, using the equals operator is clearer and less prone to misinterpretation. This corrected syntax ensures that the domain precisely targets records where the user_id field matches the ID of the currently logged-in user, which is the intended logic for a single-user restriction.

However, it's crucial to note that correcting the syntax alone does not resolve the fundamental conflict with the chatter. The underlying problem remains that even with the correct domain, other necessary partner records will be inaccessible. This syntax correction is a prerequisite for writing accurate and efficient Odoo code but does not address the access control conflict.

Strategies for Resolving Chatter Access Issues

The most direct solution to prevent the Failed to write field res.partner.message_partner_ids error is to avoid applying overly restrictive ir.rules directly to the res.partner model. Instead, it is often best practice to apply such restrictions to specific business document models (e.g., sale.order, account.move) that are related to partners. This allows users to see the business context without needing broad access to all partner records.

If restricting res.partner is absolutely necessary, a common workaround involves adding an exception to the ir.rule's domain. This exception should permit access to partner records that are essential for system functionality, such as internal users or employees. An example of such an exception could be [('user_id', '=', user.id)] OR [('user_ids', '!=', False)]. The latter condition, ('user_ids', '!=', False), targets partner records that are linked to Odoo users, which typically include internal employees and administrators.

By including such an exception, the ir.rule allows the chatter to read the necessary res.partner records related to system users, thereby resolving the access error. This approach balances the need for specific data access control with the requirement for core ERP functionalities like communication and notifications to operate smoothly. The combination of rules ensures that salesmen see their assigned partners while also allowing the system to access internal contacts for chatter purposes.

When This Approach Does Not Fit

Applying strict record rules directly on res.partner is generally discouraged in Odoo development precisely because of the cascading effects on core features like the chatter, messaging, and user management. When a company's security model requires very granular control over who can see which partners, a nuanced approach is necessary. Simply blocking access via ir.rule without considering these dependencies is a recipe for system instability and user frustration.

This solution, while effective for resolving the specific chatter access error, might not be suitable if the goal is to achieve absolute data segregation of all partner information. If, for example, a company needs to ensure that a partner record is completely invisible to a user unless explicitly shared, then even the ('user_ids', '!=', False) exception might grant too much visibility to internal employee contacts associated with partners. In such extreme cases, a more complex custom module or a different ERP system might be required.

Furthermore, this troubleshooting primarily addresses access errors triggered by the message_partner_ids field. Other Odoo features or custom modules that perform read/write operations on res.partner might also be affected by restrictive ir.rules. It is essential to test all relevant functionalities after implementing any security rule to ensure comprehensive system integrity.

This article draws on Access ir.rule res.partner Odoo V19 / Troubleshooting with chatter and an answer to it, on the Stack Exchange network, licensed under CC BY-SA 4.0.