Odoo 19: Fixing res.partner Rules and Chatter Access Errors

The Chatter-Induced Partner Access Problem

Implementing custom access rules in Odoo, particularly for the res.partner model, can lead to unexpected access errors when users interact with the partner form view. A common scenario involves users belonging to groups like sales_team.group_sale_salesman, who correctly see only their assigned partners according to a custom ir.rule. However, upon opening such a partner record, an error message surfaces: 'Failed to write field res.partner.message_partner_ids Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, test (id=5) doesn't have 'read' access to: - Contact, Administrator (res.partner: 3)'. This error often points to the custom ir.rule as the culprit.

The root cause lies in how Odoo's chatter functionality operates. The chatter utilizes the message_partner_ids field, which lists followers or participants in a conversation. When a user tries to access a partner record, the system attempts to read this field. If the ir.rule is too restrictive, it might prevent the user from reading related partners (like administrators or other internal users) that are present in the message_partner_ids list, even if those partners are not directly accessed. This creates a logical conflict: the user can see the main partner record but cannot access associated chatter data, leading to the write/read access error.

This issue highlights a subtle but critical interaction between record rules and core Odoo features like the chatter. The specific error, 'Failed to write field res.partner.message_partner_ids', indicates that while the user might have permission to view the primary partner, the underlying logic that updates or reads the chatter's follower list is failing because it encounters records the user is explicitly forbidden from reading by the custom rule. This necessitates a careful review and adjustment of the ir.rule to accommodate the operational needs of Odoo's collaborative tools.

Understanding the Role of ir.rule and res.partner

ir.rule in Odoo is a powerful mechanism for enforcing data security and access control. When defining a rule for res.partner, the intent is typically to restrict which users can view, create, write, or unlink partner records. For example, a rule might be created to ensure sales representatives only see partners they are assigned to. The provided rule configuration demonstrates this intent:

<record id="access_only_my_documents_rule" model="ir.rule"\>
  <field name="name"\>Access only own documents (partner)\</field\>
  <field name="model_id" ref="base.model_res_partner"/\>
  <field name="domain_force"\>[('user_id', 'in', user.id)]\</field\>
  <field name="groups" eval="[Command.link(ref('sales_team.group_sale_salesman'))]" /\>
\</record\>

This rule aims to filter partners based on the user_id field, granting access only to those records where the user_id matches the current user. It's applied to the sales_team.group_sale_salesman group. While effective for direct partner list views, this granular filtering can conflict with Odoo's dynamic features, such as the chatter, which often requires broader read access to related records to function correctly.

The res.partner model is fundamental to Odoo's ERP system, representing contacts, customers, and internal users. Its extensive use across modules means that restrictive rules applied here can have far-reaching consequences. When a user opens a partner form, Odoo might load associated data for display, including chatter messages and their participants. If the ir.rule's domain, such as [('user_id', 'in', user.id)], is too narrow, it can prevent the system from reading necessary related records within the chatter’s message_partner_ids, triggering the access denial.

Diagnosing the 'Failed to write field res.partner.message_partner_ids' Error

The error message 'Failed to write field res.partner.message_partner_ids' is a strong indicator that the problem lies with how the access control rules interact with the chatter's follower management. The chatter maintains a list of partners involved in the conversation, stored in the message_partner_ids field. When a partner form is opened, Odoo attempts to display this information, which involves reading the partner records associated with message_partner_ids. If the custom ir.rule restricts access to any of these related partner records, the read operation will fail, leading to the observed error.

The problematic part of the domain in the provided example, [('user_id', 'in', user.id)], might be too strict. While it correctly limits direct access to partners owned by the user, it fails to account for system-level access needs. For instance, administrative users or system-generated followers might not have their user_id field directly populated in a way that matches this rule, yet they are essential for the chatter to function. The error message explicitly blames the 'Access only own documents (partner)' rule, confirming that the rule is indeed the cause of the access denial for chatter-related records.

Furthermore, the syntax of the domain itself could be a point of failure. A more standard and often correct syntax for checking if a record belongs to the current user is ('user_id','=',user.id) rather than ('user_id', 'in', user.id), especially if user_id is a single reference field. Although 'in' with a list containing one element would technically work, it's less direct. The core issue, however, remains the restrictive nature of the domain preventing access to necessary chatter followers.

Strategies for Resolving Chatter Access Issues

To resolve the 'Failed to write field res.partner.message_partner_ids' error, the primary approach is to adjust the ir.rule for res.partner to be less restrictive regarding chatter participants. One effective method is to add an exception to your existing rule that allows access to internal users or system-generated partners. For instance, you could modify the domain to include partners that are associated with an Odoo user (e.g., employee records or system administrators) regardless of the main ownership criteria.

A recommended modification involves adding a condition that checks for the presence of associated user records. For example, the domain could be modified to something like: [('user_id', '=', user.id)] | [('user_ids', '!=', False)]. This ensures that the rule grants access to partners directly assigned to the user via user_id, OR partners that have associated users (implying they might be internal employees or system accounts). The user_ids field (plural) is often used in Odoo to link to multiple users, such as in employee records.

Another robust strategy, suggested as a best practice, is to avoid applying overly strict record rules directly on the res.partner model. Instead, it's often more effective to restrict access at the level of business documents that relate to partners, such as sales orders, invoices, or projects. This approach protects sensitive transactional data while allowing core contact information to be more broadly accessible, thereby preventing conflicts with features like the chatter which rely on a wider network of contact information. If partner restriction is absolutely necessary, carefully consider exceptions for internal users.

Correcting Domain Syntax in ir.rule

The syntax used for the domain in an ir.rule is critical for its correct functioning. In the example provided, the domain is set as [('user_id', 'in', user.id)]. While the intention is to filter partners based on the current user, the use of 'in' with a single user ID might not be the most idiomatic or robust way to express this constraint. For a field like user_id, which typically stores a single many-to-one relation to a user record, the correct operator is usually '='.

A corrected and more standard domain syntax would be [('user_id', '=', user.id)]. This explicitly states that the user_id field of the partner record must exactly match the ID of the current user. If there's a possibility that a partner might be associated with multiple users and you intend to grant access if the current user is among them, a different field or a different model might be involved, or the field itself might be a one-to-many or many-to-many relationship. However, for the common case of restricting partners to their assigned sales representative, '=' is the appropriate operator.

It's also important to consider the context in which user.id is evaluated. Within an ir.rule's domain_force, user refers to the current user executing the operation. Ensuring that this variable is correctly resolved and that the field being filtered (user_id) accurately represents the ownership or association you intend to enforce is paramount. Correcting the domain syntax from 'in' to '=' is a crucial first step in troubleshooting, though as discussed, the fundamental issue often lies in the restrictiveness of the overall domain rather than just the operator.

Where This Approach Does Not Fit

While adjusting ir.rules to accommodate the chatter is a viable solution for many Odoo implementations, this approach is not a universal panacea and has limitations. Applying overly broad exceptions to res.partner rules, such as the suggestion to include [('user_ids', '!=', False)], can inadvertently grant access to sensitive partner information that should remain restricted. If your business process requires strict segregation of all partner data, even beyond direct ownership, then modifying the partner rule to include system users or all internal partners might compromise data privacy and security objectives.

Furthermore, if the chatter functionality itself is heavily customized or relies on complex logic that involves intricate relationships with other models, simply adjusting the res.partner rule might not be sufficient. The error could stem from a combination of factors, including other active ir.rules on related models, or specific settings within the chatter's technical configuration. In such advanced scenarios, a deeper dive into Odoo's access control inheritance and potential conflicts between multiple security rules would be necessary.

Finally, for very large or complex ERP systems, performance implications must be considered. Overly complex domains or excessive use of exceptions within ir.rules, particularly on frequently accessed models like res.partner, can degrade query performance. While fixing the chatter error is important, it should be balanced against the overall system responsiveness. In some cases, rethinking the data access strategy entirely, rather than patching existing rules, might be a more sustainable long-term solution, especially in a large Python-based Odoo development context.

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.