Odoo Changelog — 2023-09-26

Tuesday, September 26, 2023

1 change · master

Refactoring(1)

Code cleanup and technical improvements

[IMP] hr_holidays: refactor leave hr_holidays_duration

Enterprisemasterhr_holidaysdocuments_hr_holidayshelpdesk_holidayshr_payroll_holidaysl10n_be_hr_payrolll10n_hk_hr_payrolll10n_lu_hr_payrollplanning_holidaysproject_holidaystimesheet_grid_holidaystest_l10n_be_hr_payroll_accountMedium

Time off requests now rely on the employee's requested dates as the main input, with system dates calculated automatically using work schedules and time zones. This reduces inconsistent leave calculations and makes payroll, planning, timesheets, documents, projects, and helpdesk integrations easier to maintain.

Original PR description

The idea of current date_{from,to} computations is as follows: The user selects the request_date_{from,end} (and optionally request_hour_{from,to} and these inputs are then processed into a…

The idea of current date_{from,to} computations is as follows:

The user selects the request_date_{from,end} (and optionally request_hour_{from,to} and these inputs are then processed into a date_{to,from}, taking into account the type of leave, the work schedule (resource_calendar) and time zone (since date_{to,from} are saved in UTC while the request_dates are stored in the user's timezone.

However, in practice this computation is very messy, resulting in date_{to,from} needing to be specified in all demo data and test cases, even though it should be derived from the request dates. Various superfluous or poorly named methods also exist in this flow (eg _get_start_or_end_from_attendance which really performs a timezone conversion, the logic of which resource calendar to use is scattered across the whole model etc).

date_{to,from} are used many times as inputs throughout the code, with code being present te inverse compute request_date_{from,to} from these values. However in reality this is not possible to do consistently.

Therefore with this commit, we restore request_date_{from,to} as the sole possible inputs, with date_{from,to} being derived from them. In addition, the timezone and resource calendar are consolidated into their own fields, with a single computation method computing them.

task-3081565

#time off#leave management#payroll#work schedules#time zones

The idea of current date_{from,to} computations is as follows: The user selects the request_date_{from,end} (and optionally request_hour_{from,to} and these inputs are then processed into a date_{to,from}, taking into account the type of leave, the work schedule (resource_calendar) and time zone (since date_{to,from} are saved in UTC while the request_dates are stored in the user's timezone. However, in practice this computation is very messy, resulting in date_{to,from} needing to be specified in all demo data and test cases, even though it should be derived from the request dates. Various superfluous or poorly named methods also exist in this flow (eg _get_start_or_end_from_attendance which really performs a timezone conversion, the logic of which resource calendar to use is scattered across the whole model etc). date_{to,from} are used many times as inputs throughout the code, with code being present te inverse compute request_date_{from,to} from these values. However in reality this is not possible to do consistently. Therefore with this commit, we restore request_date_{from,to} as the sole possible inputs, with date_{from,to} being derived from them. In addition, the timezone and resource calendar are consolidated into their own fields, with a single computation method computing them. task-3081565