[19.0][MIG] hr_timesheet_calendar: Migration to 19.0#898
Conversation
OCA-git-bot
added
series:19.0
mod:hr_timesheet_calendar
78bc892 to
7416726
Compare
|
@bizzappdev , @alexey-pelykh could you review, also the dependent PRs. |
MohamedOsman7
left a comment
MohamedOsman7
left a comment
There was a problem hiding this comment.
I encountered the following error when clicking on the calendar view:
ValueError: Cannot convert account.analytic.line.date_time_end to SQL because it is not stored.
This is because of this missing PR #896 as mentioned above. |
2fa0d61 to
e597b24
Compare
0909a90 to
d2b4886
Compare
71fb166 to
9521013
Compare
|
@MohamedOsman7 can be retested when #927 merged or hr_timesheet_time_control_begin_end is uninstalled. |
Currently translated at 100.0% (4 of 4 strings) Translation: timesheet-17.0/timesheet-17.0-hr_timesheet_calendar Translate-URL: https://translation.odoo-community.org/projects/timesheet-17-0/timesheet-17-0-hr_timesheet_calendar/it/
…ate configurable to be now or directly after the previous entry if available otherwise use employee working hour start
… dict Running tests, sometimes an error was raised when demo project has analytic account set. When was unset the problem was hidden.
… when using 'no-gap'
…add date_time assignment in create method
Port idea of OCA#812 in v18 [FIX]LINT
9521013 to
92d750c
Compare
|
Should work now, but for testing hr_timesheet_begin_end should be uninstalled, because there are some issues with the start/end time calculation. (installing hr_timesheet_time_control_begin_end and hr_timesheet_begin_end at the same time does not make sense anyway) |
|
@lbarry-apsl could you review? |
92d750c to
887bdbf
Compare
MohamedOsman7
left a comment
MohamedOsman7
left a comment
There was a problem hiding this comment.
Tested! Functional & Code LGTM
|
@leemannd could you review? |
|
@aurelien-tempo Could you please make a review? |
|
Hi, I'm not a maintainer, I just did the migration for hr_timesheet because I needed it for a project. I do not know how this module works/should work so wouldn't be helpful for a review. And wouldn't be able to merge anyways. |
alexey-pelykh
left a comment
alexey-pelykh
left a comment
There was a problem hiding this comment.
Thanks for the migration, @CRogos — went through the Python side (my usual hr_timesheet corner) and it's clean; CI is green bar codecov. One latent bug to flag in models/account_analytic_line.py, in duplicate_today:
date_today = fields.Datetime.now(self.env.user.partner_id.tz).date()fields.Datetime.now() takes *args and ignores them (19.0 odoo/orm/fields_temporal.py: def now(*args): return datetime.now().replace(microsecond=0)), so the partner_id.tz argument is a no-op — date_today becomes the server/UTC date, not the user's local date. Near midnight this duplicates the entry onto the wrong calendar day for any user whose timezone differs from the server (e.g. 23:00 UTC → a user in UTC+1 is already "tomorrow"). The tests don't catch it because test_duplicate_today freezes at 2025-04-03 (midnight), where UTC and local agree.
Timezone-aware alternative:
date_today = fields.Date.context_today(self)This is pre-existing (identical in 18.0), not introduced by your migration — so it's equally fine to leave as-is and fix in a follow-up if you'd rather keep the MIG minimal.
Co-Reviewed-By: Claude Opus 4.8 noreply@anthropic.com
…onto the wrong calendar day
|
@alexey-pelykh I've added a separate commit so we can create cherry-pick PR for 18.0 |
9 participants
supersede: #842
This PR depends on #896 to work.
Tests fixed by #899
But it looks like it cannot be done via temporary reference