Skip to content

Conversation

fw-bot
Copy link
Contributor

@fw-bot fw-bot commented Nov 26, 2024

Steps

  • create an accrual plan with a level giving 1 hour every month and a carry
    over with a maximum of 4 hours. Set accrued gain time at the start of the period
    and carry-over time at start of the year.
  • create an allocation using this accrual plan, for a time off type in days,
    set the start date on the first day of next year.
  • go to Time Off Dashboard
  • check the balance on the middle of the month of the following year (e.g.
    15 january 2026 if the allocation starts on 1 january 2025).

-> ~14 days of time off available: the max postpone amount is not applied,
the time gained is in days and not in hours and more than 1 day is gained/month
(balance a few days after the start of the allocation should be +1 added_value
but is more than that).

Causes:

  • the maximum amount of carry over postpone_max_days is applied in days
    even if the accrual added_value is in hours and the UI shows postpone_max_days
    as "Up to X hours".
  • get_future_leaves returns a number of hours if the allocation is in hours, even
    if the time off type is in days.
  • the number of hours from the accrual at the beginning of the allocation is too
    high if the start of the accrual is in the future and gain time added at the start
    of the period due to cache not being invalidated.
    if self.type_request_unit in ['hour']:
    return float_round(fake_allocation.number_of_hours_display - self.number_of_hours_display, precision_digits=2)
    res = round((fake_allocation.number_of_days - self.number_of_days), 2)
    fake_allocation._invalidate_cache(['number_of_days', 'number_of_days_display', 'lastcall', 'nextcall', 'number_of_hours_display'])

opw-4272315

Forward-Port-Of: #185699

Steps
- create an accrual plan with a level giving 1 hour every month and a carry
over with a maximum of 4 hours. Set accrued gain time at the start of the period
and carry-over time at start of the year.
- create an allocation using this accrual plan, for a time off type in days,
set the start date on the first day of next year.
- go to Time Off Dashboard
- check the balance on the middle of the month of the following year (e.g.
15 january 2026 if the allocation starts on 1 january 2025).

-> ~14 days of time off available: the max postpone amount is not applied,
the time gained is in days and not in hours and more than 1 day is gained/month
(balance a few days after the start of the allocation should be +1 added_value
but is more than that).

Causes:
- the maximum amount of carry over `postpone_max_days` is applied in days
even if the accrual `added_value` is in hours and the UI shows `postpone_max_days`
as "Up to X hours".
- `get_future_leaves` returns a number of hours if the allocation is in hours, even
if the time off type is in days.
- the number of hours from the accrual at the beginning of the allocation is too
high if the start of the accrual is in the future and gain time added at the start
of the period due to cache not being invalidated.
https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578

opw-4272315

X-original-commit: f9c5502
@robodoo
Copy link
Contributor

robodoo commented Nov 26, 2024

Pull request status dashboard

@fw-bot
Copy link
Contributor Author

fw-bot commented Nov 26, 2024

This PR targets saas-17.4 and is part of the forward-port chain. Further PRs will be created up to master.

More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port

@robodoo robodoo added the forwardport This PR was created by @fw-bot label Nov 26, 2024
@C3POdoo C3POdoo added the OE the report is linked to a support ticket (opw-...) label Nov 26, 2024
@fw-bot
Copy link
Contributor Author

fw-bot commented Dec 3, 2024

@taqu-odoo @Bertrand2 child PR #188728 was modified / updated and has become a normal PR. This PR (and any of its parents) will need to be merged independently as approvals won't cross.

@fw-bot
Copy link
Contributor Author

fw-bot commented Dec 4, 2024

@taqu-odoo @Bertrand2 this forward port of #185699 is awaiting action (not merged or closed).

3 similar comments
@fw-bot
Copy link
Contributor Author

fw-bot commented Dec 5, 2024

@taqu-odoo @Bertrand2 this forward port of #185699 is awaiting action (not merged or closed).

@fw-bot
Copy link
Contributor Author

fw-bot commented Dec 6, 2024

@taqu-odoo @Bertrand2 this forward port of #185699 is awaiting action (not merged or closed).

@fw-bot
Copy link
Contributor Author

fw-bot commented Dec 8, 2024

@taqu-odoo @Bertrand2 this forward port of #185699 is awaiting action (not merged or closed).

@Bertrand2
Copy link
Contributor

robodoo r+

robodoo pushed a commit that referenced this pull request Dec 9, 2024
Steps
- create an accrual plan with a level giving 1 hour every month and a carry
over with a maximum of 4 hours. Set accrued gain time at the start of the period
and carry-over time at start of the year.
- create an allocation using this accrual plan, for a time off type in days,
set the start date on the first day of next year.
- go to Time Off Dashboard
- check the balance on the middle of the month of the following year (e.g.
15 january 2026 if the allocation starts on 1 january 2025).

-> ~14 days of time off available: the max postpone amount is not applied,
the time gained is in days and not in hours and more than 1 day is gained/month
(balance a few days after the start of the allocation should be +1 added_value
but is more than that).

Causes:
- the maximum amount of carry over `postpone_max_days` is applied in days
even if the accrual `added_value` is in hours and the UI shows `postpone_max_days`
as "Up to X hours".
- `get_future_leaves` returns a number of hours if the allocation is in hours, even
if the time off type is in days.
- the number of hours from the accrual at the beginning of the allocation is too
high if the start of the accrual is in the future and gain time added at the start
of the period due to cache not being invalidated.
https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578

opw-4272315

closes #188719

X-original-commit: f9c5502
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
@robodoo robodoo closed this Dec 9, 2024
@fw-bot fw-bot deleted the saas-17.4-17.0-opw-4272315-hr_holidays_accrual_level_carry_hours-taqu-sFlM-fw branch December 23, 2024 18:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

forwardport This PR was created by @fw-bot OE the report is linked to a support ticket (opw-...)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants