| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Lines of code | 78 |
| Technical Name |
eh_hr_compat |
| License | LGPL-3 |
| Website | https://erpheritage.com.au |
| Versions | 16.0 17.0 18.0 19.0 |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Lines of code | 78 |
| Technical Name |
eh_hr_compat |
| License | LGPL-3 |
| Website | https://erpheritage.com.au |
| Versions | 16.0 17.0 18.0 19.0 |
EH HR Compatibility Layer
One import surface that absorbs the Odoo API changes so HR feature modules never branch on the version themselves.
Why this module
EH HR Compatibility Layer
Stop branching on the version in every module
Feature modules import CONTRACT_MODEL, tracking, legacy_view_mode, user_groups, group_users, groups_field and setup_access_dropdown from one place. The version is read once from odoo.release.version_info and the right answer is handed back, so call sites never touch odoo.release or a raw version number themselves.
Absorbs the field and model renames that break HR addons
CONTRACT_MODEL resolves hr.contract versus hr.version. user_groups, group_users and groups_field resolve the res.users groups_id to group_ids and res.groups users to user_ids renames by introspecting _fields, so the same call works whether the field was renamed or not.
Idempotent helpers that will not drop data
safe_field_rename renames a column only when the old name exists and the new one does not, checked against information_schema first, so re-running a migration is a no-op rather than a failure. setup_access_dropdown looks records up by name, so re-installs do not duplicate categories or privileges.
Day in the life
A field rename ships in a new Odoo series and your HR suite keeps building
Odoo renames res.users.groups_id to group_ids and moves the access-level grouping from category_id onto a privilege. Without a shim, every module that assigns a security group or reads a user's groups breaks, and you scatter version checks across the codebase. With eh_hr_compat, the feature modules already call groups_field(env) when writing vals and user_groups(user) when reading, and setup_access_dropdown branches on privilege_id versus category_id internally. The rename is absorbed in one file, the call sites do not change, and the dropdown still renders as one ordered, mutually exclusive access level on the user form.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
safe_field_rename queries information_schema.columns first and renames only when the old column exists and the new one does not, so running a pre-migrate twice is a no-op rather than an error and never silently drops a renamed column's data.
user_groups, group_users and groups_field decide between group_ids and groups_id, and between user_ids and users, by checking the live _fields of the record, so the same code path works on a series where the rename happened and one where it did not.
setup_access_dropdown looks up its ir.module.category, res.groups.privilege and groups by name before creating them, so a second install reuses the existing records instead of creating duplicate access categories or privileges.
setup_access_dropdown inspects res.groups._fields and writes privilege_id when present, otherwise category_id, so the access-level dropdown renders correctly whether the categorisation lives on the legacy category or the newer privilege.
setup_access_dropdown resolves group XML ids with raise_if_not_found=False, filters out the misses, and returns early when nothing resolves, so a partial install does not raise.
api_shim imports only odoo.release and touches no env, no records and no models, so the surface is importable before the registry is built and carries no caches or global state that could go stale.
What is inside
Built to do the job, end to end.
- Version detection. ODOO_VERSION plus IS_17_PLUS, IS_18_PLUS and IS_19_PLUS derived once from odoo.release.version_info, so downstream code reads a boolean instead of parsing a version string.
- Model and field shims. CONTRACT_MODEL for hr.contract versus hr.version, user_groups and group_users for reading group and member recordsets, and groups_field for the field name when building create or write vals.
- View and field-attribute helpers. legacy_view_mode rewrites list to tree for older series, tracking returns the tracking kwarg pair for field definitions, and owl_import_path returns the canonical @odoo/owl import string.
- Migration and access helpers. safe_field_rename for idempotent column renames in pre-migrate scripts, and setup_access_dropdown to render an implication chain of groups as a single exclusive access-level selector on the user form.
- Shape of the module. No models, no wizards, no data files, no views and no security records. depends on base only. A pure Python import surface with no singletons, caches or global state.
Honest about the edges
What this does not do, so nothing surprises you.
- This is developer infrastructure for the EH HR Platform, not an end-user application. There is no UI, no menu and no configuration screen.
- It defines no models, stores no records and holds no business logic or state of its own. Installing it alone does nothing visible; it exists to be imported by the EH HR feature modules.
- It does not migrate your data by itself. safe_field_rename is a helper you call from a pre-migrate script; the module ships no migration scripts.
- It has no cron jobs, no advisory locks, no savepoints and no multi-company logic. Those concerns live in the feature modules that depend on it.
- The shipped code targets Odoo 17 Community. The broader 16, 18 and 19 support described for the platform is produced and tested at the platform level, not by this module on its own.
- depends on base only, so it adds the helper surface but pulls in none of the HR application modules; those are declared by the feature modules that use it.
Odoo 17 HR compatibility module, hr.contract hr.version shim, groups_id group_ids Odoo, Odoo version compatibility layer, idempotent field rename migration, list vs tree view mode Odoo, res.groups privilege category_id, Odoo HR developer module, version agnostic Odoo addon, ERP Heritage HR Platform
Please log in to comment on this module