| 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
One authored source, version shims that keep it running on Odoo 16.
Why this module
EH HR Compatibility
Author once, branch never
Downstream modules import a constant instead of testing the running version themselves. The single place that knows about a rename is this module, so the feature code reads the same on every series, including Odoo 16.
Nothing to maintain twice
No models, no singletons, no caches, no global state, and no imports from any other platform module. It is pure Python that is importable before the registry is built, so there is no install order or data to reconcile.
Renames that do not drop data
The migration helper renames a column only when the old name exists and the new one does not, checked against information_schema first. The rename is idempotent, so re-running a pre-migrate script is a no-op rather than a data loss event.
Day in the life
Where it quietly does its job
A developer on the platform writes state = fields.Selection(..., **tracking()) and an action with view_mode set through legacy_view_mode('list,form,kanban'). On Odoo 16 that view mode comes back as tree,form,kanban and CONTRACT_MODEL resolves to hr.contract, so the same source that ships for newer series loads cleanly here. When a field needs to assign security groups, the code calls groups_field(env) for the right key and user_groups(user) to read members, never touching groups_id or group_ids directly. None of this is visible to an end user; it is the seam that lets one codebase install on Odoo 16.
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 checks information_schema for both the old and new column names and renames only when the old exists and the new does not, so a pre-migrate script can run twice without dropping a column or raising.
CONTRACT_MODEL hides the hr.contract to hr.version rename behind one constant. On Odoo 16 it resolves to hr.contract, so callers never hardcode either literal.
user_groups, group_users and groups_field absorb the groups_id to group_ids and users to user_ids renames by probing _fields at call time, returning the correct recordset or dict key for the running version.
setup_access_dropdown renders an implication chain as one exclusive access-level selector, using res.groups.category_id on Odoo 16 to 18 and res.groups.privilege on 19 plus. It looks groups up by name and creates the category only if missing, so re-installs do not duplicate records.
The shim imports only odoo.release, with no env, no records and no models, so it is importable before the registry is built and cannot create a circular dependency with the modules that use it.
legacy_view_mode rewrites list to tree for series before Odoo 17, so an action authored once in the newer vocabulary still presents a valid view_mode on Odoo 16.
What is inside
Built to do the job, end to end.
- Version detection constants. ODOO_VERSION, IS_17_PLUS, IS_18_PLUS and IS_19_PLUS are derived once from release.version_info and exposed as plain values, so downstream code reads a constant rather than re-parsing the version.
- Model and field rename shims. CONTRACT_MODEL for the hr.contract to hr.version rename, plus user_groups, group_users and groups_field for the user and group field renames, each resolved against the live _fields map.
- View and OWL helpers. legacy_view_mode converts list to tree for older series, and owl_import_path returns the canonical @odoo/owl path used by the build-time view backport step.
- Migration and access helpers. safe_field_rename performs an idempotent, information_schema-guarded column rename for pre-migrate scripts, and setup_access_dropdown builds a portable exclusive access-level dropdown across the category_id and privilege models.
- What it installs. No models of its own and no data, views, wizards or cron. It is a pure Python helper library that depends only on base, exposed through a stable import surface for the rest of the platform.
Honest about the edges
What this does not do, so nothing surprises you.
- This module is a developer-facing helper library. It has no user interface, no menus, no views and no configuration screens, so installing it on its own changes nothing visible in Odoo.
- It defines no models and stores no data. It is consumed by other EH HR Platform modules through Python imports and does nothing useful by itself.
- It ships no automated tests of its own. Its helpers are exercised by the wider EH HR Platform test suite, not by tests inside this module.
- It targets Odoo 16 Community on this listing. The same source carries shims for newer series, but what is sold here is the Odoo 16 build.
- The migration helper covers the specific column-rename case it documents. It is not a general migration framework and does not move or transform row data.
- owl_import_path returns a path string for the build step; this module does not itself rewrite or bundle JavaScript assets.
odoo 16 hr compatibility, odoo version compatibility shim, hr.contract hr.version rename, groups_id group_ids odoo, res.groups privilege access level, idempotent column rename migration, odoo release version_info helper, list tree view_mode odoo 16, owl import path odoo, erp heritage hr platform, odoo 16 community hr, version agnostic odoo addon
Please log in to comment on this module