admin/Odoo-Modules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(fusion_clock): tz resolver uses company.partner_id.tz (res.company has no tz in Odoo 19)

Browse Source 
_resolve_tz fell back to env.company.tz, which raises AttributeError for any
user without a personal tz (surfaced by the new list-wide pay-period filters,
which resolve a company-level tz). Use env.company.partner_id.tz. Regression
test added. Bump 3.15.0 -> 3.15.1.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
gsinghpal
2026-05-31 11:23:27 -04:00
parent 3f78f652e7
commit 1a1ab2da4f
3 changed files with 20 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
fusion_clock/models/tz_utils.py
View File

@@ -10,10 +10,12 @@ date boundaries, and display strings in the **user's local timezone**
so that queries, penalties, and UI all reflect the real calendar day.
Timezone resolution order:
1. Explicit employee.tz (if an employee record is available)
2. env.user.tz (logged-in portal / backend user)
3. env.company.tz (company-level default)
4. 'UTC' (last resort — should rarely happen)
1. Explicit employee.tz (if an employee record is available)
2. env.user.tz (logged-in portal / backend user)
3. env.company.partner_id.tz (company-level default; res.company has
no tz field in Odoo 19 — it lives on the
company's partner)
4. 'UTC' (last resort — should rarely happen)
"""
import pytz
@@ -25,7 +27,7 @@ def _resolve_tz(env, employee=None):
tz_name = (
(employee.tz if employee else None)
or env.user.tz
or env.company.tz
or (env.company.partner_id.tz if env.company.partner_id else None)
or 'UTC'
)
try: