The Access Error occurs because the res.users model and its inherited fields (such as fields added by the Employees module) require specific access rights that your users do not have. When you add a custom field (x_signature) to the res.users model, any reference to that field in the res.users view triggers access checks for related fields as well. In this case, fields inherited from hr.employee (e.g., barcode, birthday) are restricted to users with specific Employee-related permissions.
Here’s how you can resolve this without granting additional access rights to the Employees module:
Solution 1: Use a Separate Model for the Custom Field
Instead of adding the custom field (x_signature) directly to res.users, create a new model and link it to res.users. This isolates your custom field from access rules defined for the Employees module.
- Create a New Model: Define a new model (res.user.signature) with a Many2One relation to res.users:
pythonCopy codefrom odoo import models, fields
class ResUserSignature(models.Model):
_name = 'res.user.signature'
_description = 'User Signature'
user_id = fields.Many2one('res.users', string="User", required=True, ondelete='cascade')
signature = fields.Binary(string="Signature")
- Add the Field to the View: Extend the res.users view to include the signature field from the new model:
xmlCopy code<record id="view_res_users_signature" model="ir.ui.view">
<field name="name">res.users.signature.form.inherit</field>
<field name="model">res.users</field>
<field name="inherit_id" ref="base.view_users_form" />
<field name="arch" type="xml">
<xpath expr="//field[@name='employee_type']" position="after">
<field name="user_signature_ids.signature" widget="image"/>
</xpath>
</field>
</record>
- Test Access Rights: This approach isolates the x_signature field, and users will not encounter access errors since you’re no longer inheriting restricted fields from hr.employee.
Solution 2: Adjust Field Access Control
If you need to keep the x_signature field on the res.users model, explicitly set its access rights to make it accessible for users without permissions to the Employees module.
- Grant Access to the Custom Field: Add a record rule or modify field-level security for x_signature:
pythonCopy codefrom odoo import models, fields
class ResUsers(models.Model):
_inherit = 'res.users'
x_signature = fields.Binary(string="Signature", groups="base.group_user")
- The groups="base.group_user" ensures that all regular users can access this field.
- Ensure the Field is Readable by All Users:
- If the default security on res.users restricts access to fields such as barcode or birthday, ensure your custom field doesn’t trigger access checks for restricted fields. Use sudo() in your Python code if necessary when reading or writing the field.
Solution 3: Use Computed or Related Fields
If the custom field is related to hr.employee but needs to be accessible in res.users, use a computed field that respects user permissions.
- Add a Computed Field: Define the x_signature field as a computed field:
pythonCopy codeclass ResUsers(models.Model):
_inherit = 'res.users'
x_signature = fields.Binary(string="Signature", compute="_compute_signature")
def _compute_signature(self):
for user in self:
if user.employee_id:
user.x_signature = user.employee_id.sudo().x_signature
else:
user.x_signature = False
- Test Access: Using sudo() ensures that the computation bypasses the restrictive access rules for employee_id fields, while users can still view the field on the form.
Solution 4: Adjust the Record Rule for res.users
If you prefer to adjust access rules directly:
- Relax the Record Rules: Identify the restrictive record rules for res.users (related to the Employees module) and customize them. For example, you might find rules like this:
xmlCopy code<record id="hr_employee_rule_users" model="ir.rule">
<field name="name">Employees: User Read Access</field>
<field name="model_id" ref="base.model_res_users" />
<field name="groups" eval="[(4, ref('hr.group_hr_user'))]" />
<field name="domain_force">['|', ('id', '=', user.id), ('employee_ids', '!=', False)]</field>
</record>
- Modify or disable the restrictive rule, but note that this is not recommended as it might introduce unintended side effects.
Conclusion
The best solution depends on your specific use case:
- Use Solution 1 if you want a clean separation of concerns (best practice).
- Use Solution 2 if you want to simplify and directly expose the custom field.
- Use Solution 3 if the field is related to hr.employee but should respect access rights.