Introduction
In Odoo, models define how data is structured and stored in the database. Every piece of business data you work with, from sales orders to invoices to employees, lives in a model.
Understanding Odoo models is essential for both developers and functional consultants. Models are the foundation of the Odoo data architecture. They define fields, relationships, and business logic.
This article focuses on one of the core models in the HR module: hr.employee. Whether you are building custom HR workflows, integrating payroll systems, or configuring attendance and leave, you will work with this model.
What is the hr.employee Model
The hr.employee model represents employees in Odoo. It is the central place where all personnel information is stored.
This Odoo model is part of the HR (Human Resources) app. It is used across attendance, leave, contracts, payroll, and timesheets.
It is installed when you enable the Employees app. Other modules extend it through Odoo model inheritance. hr_contract adds contract fields. hr_attendance adds check-in and check-out. hr_leave adds time off. Each module adds what it needs without duplicating the core structure.
Odoo also provides hr.employee.public, a restricted view of the same data for users who need limited employee visibility. This is an example of how Odoo uses abstract model patterns and model inheritance to control access.
Key Fields in the Model
Here are the most important Odoo fields in the hr.employee model. Understanding these will help you work effectively with employee records.
1. name
Type: Char. This field stores the employee name. It is typically displayed in many Odoo views and is the primary identifier for the employee record.
2. create_date
Type: Datetime. Stores the date and time when the record was created. Automatically managed by Odoo. Useful for reporting and auditing.
3. write_date
Type: Datetime. Stores the date and time of the last modification. Also automatically managed. Helps track when data was last updated.
4. active
Type: Boolean. Soft delete flag. When False, the record is archived and hidden from default views. Use this when an employee leaves. Records are not physically deleted.
5. company_id
Type: Many2one (res.company). In multi-company setups, this indicates which Odoo company the employee belongs to. Required for most employee records.
6. user_id
Type: Many2one (res.users). Links the employee to an Odoo user. When set, the employee can log in and use Odoo. Used for portal access, timesheets, and approvals.
7. work_email
Type: Char. The work email address. Used for internal communications and notifications.
8. work_phone
Type: Char. The work phone number. Displayed in employee forms and used for contact workflows.
9. mobile_phone
Type: Char. Work mobile number. Often used for SMS or urgent notifications.
10. department_id
Type: Many2one (hr.department). The department the employee belongs to. Used for org charts, reporting, and approval workflows.
11. job_id
Type: Many2one (hr.job). The job position. Links to the hr.job model which defines job titles and open positions.
12. job_title
Type: Char. Free-text job title. Can be used when job_id is not set or for custom titles.
13. parent_id
Type: Many2one (hr.employee). The manager. Enables the hierarchy of employees. Used for approval chains and org structure.
14. coach_id
Type: Many2one (hr.employee). The coach of this employee. Used for performance and development. The coach has no specific rights by default.
15. resource_id
Type: Many2one (resource.resource). Links to the resource model. Used for scheduling, capacity planning, and calendar integration.
16. work_contact_id
Type: Many2one (res.partner). The work contact. Links to the partner record used for work-related communications and documents.
17. address_id
Type: Many2one (res.partner). Work address. Links to a res.partner record for the office or work location.
18. address_home_id
Type: Many2one (res.partner). Private address. The employee's home address, not the office. Used for payroll and emergency contacts.
19. resource_calendar_id
Type: Many2one (resource.calendar). Working schedule. Defines working hours and days. Used for attendance, leave, and planning.
20. employee_type
Type: Selection. Employee type: Employee, Freelancer, or Intern. Required. Affects contract history: only Employee type is supposed to be under contract.
21. barcode
Type: Char. Badge ID. Used for employee identification in attendance kiosk and other barcode scanning.
22. pin
Type: Char. PIN used to check in and out in the Kiosk mode of the Attendance app. Also used to change the cashier in Point of Sale.
23. birthday
Type: Date. Date of birth. Used for HR records and optional birthday reminders.
24. identification_id
Type: Char. National identification number. Used for HR and payroll compliance.
25. passport_id
Type: Char. Passport number. Used for travel and work permit tracking.
26. bank_account_id
Type: Many2one (res.partner.bank). Employee bank account for salary payments.
27. private_email
Type: Char. The employee's personal email. Used when work email is not available.
28. phone
Type: Char. Private phone number. Different from work contact details.
29. contract_id
Type: Many2one (hr.contract). Current contract. Reference to the active contract.
30. contract_ids
Type: One2many (hr.contract). All contracts linked to this employee. Contract history.
31. image_1920
Type: Binary. Employee photo or avatar. Odoo stores multiple sizes. Used in forms, reports, and the directory.
32. related_partner_id
Type: Many2one (res.partner). The contact linked to this employee. Connects employee data to the partner model for CRM and other modules.
33. leave_manager_id
Type: Many2one (res.users). User responsible for approving time off. If empty, approval goes to an Administrator or Approver.
34. expense_manager_id
Type: Many2one (res.users). User responsible for approving expenses. If empty, approval goes to an Administrator or Approver.
35. timesheet_manager_id
Type: Many2one (res.users). User responsible for approving timesheets. If empty, approval goes to a Timesheets Administrator or User.
How This Model Is Used in Business Workflows
1. Employee Directory and Onboarding
When HR creates a new employee, they fill in the hr.employee record. Name, department, job, manager, and contact details. The user_id link is set when the employee gets Odoo access.
2. Attendance and Time Tracking
Employees check in and out via the Attendance app. The check-in and check-out times are stored in hr.attendance, linked to hr.employee. The barcode and pin fields enable kiosk mode.
3. Time Off and Leave
Leave requests reference the employee. The leave_manager_id and resource_calendar_id drive who approves and how many days are allocated.
4. Payroll and Contracts
Payroll uses hr.employee for salary structure, bank account, and contract data. The contract_id links to the current contract. The contract_ids hold the full history.
5. Timesheets and Project Allocation
When employees log time on projects, the timesheet links to hr.employee. The timesheet_manager_id controls approval. The resource_id links to the planning and scheduling tools.
How Developers Extend This Model
Developers extend hr.employee using several patterns. Odoo model inheritance is the main mechanism.
Model Inheritance
Use _inherit = 'hr.employee' to extend the model. Add new fields, override methods, or add constraints. The inherit model in Odoo keeps your changes in a separate module for easy upgrades.
Adding Fields
Define new Odoo fields in your inherited model. Use the right field type: Char, Many2one, Boolean, Integer, Text, Selection. Consider company-dependent fields for multi-company.
Python Extensions
Override create, write, or unlink to add logic. Use super() to call the original. Be careful with computed fields and their dependencies.
Odoo Studio
Odoo Studio lets you add fields without code. Good for quick customizations. For complex logic or upgrades, custom modules are more maintainable.
Best Practices
- Set user_id only when the employee needs Odoo access. Not all employees need a user account.
- Use the parent_id hierarchy correctly. Build the org structure from the top down.
- Set resource_calendar_id for consistent working hours and leave calculations.
- When building API integrations, use the XML-RPC or JSON-RPC API. The hr.employee model in Odoo is fully exposed as an API model. Map external IDs carefully.
- For custom fields, use the
x_prefix or a module prefix to avoid conflicts with future Odoo versions. - Fields restricted to hr.group_hr_user should not be prefetched for users without HR access. Use groups on field definitions.
Common Mistakes
- Creating duplicate employee records instead of searching for existing ones. Use work_email or identification_id for deduplication.
- Mixing up user_id and related_partner_id. user_id is for Odoo login. related_partner_id is the contact record.
- Forgetting to set employee_type. It is required and affects contract behavior.
- Overriding core methods without calling super(). This can break other modules or future upgrades.
- Adding required custom fields without defaults. Existing records will fail validation on upgrade.
- Exposing sensitive HR fields to users without hr.group_hr_user. Use groups on fields that contain private data.
Conclusion
The hr.employee model is central to Odoo HR. It stores employee data, links to contracts, attendance, and leave. Understanding its fields and how modules extend it will help you configure, customize, and integrate Odoo effectively.
Whether you are a functional consultant mapping HR processes or a developer building custom modules, a solid grasp of hr.employee will save time and prevent errors.
Need Help With Your Odoo Implementation ?
Dasolo helps companies implement, customize, and optimize Odoo. We specialize in API integrations and Odoo development. Our team has deep experience with the Odoo data architecture and models like hr.employee.
If you need help with your Odoo implementation, custom HR modules, or integrations, we are here to help. Book a demo to discuss your project.