A test introduced with https://github.com/odoo/odoo/pull/96432
revealed an issue with the level limits for the accrual plans.
The only applied limit was the one of the current level at the end of
the run, however if for whatever reason multiple levels had to be
processed at once (if the database was shut down for a long period of
time for example), the individual levels would not apply any limit logic
to their behaviour which meant that you could have a different behaviour
between running the cron each day and running it after a long period.
This commit aims to fix that issue by applying the said limit.
OPW-2868297
closesodoo/odoo#97540
X-original-commit: 09fa1020f42d641fc0011d482cdd08aea4f4085a
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Create an accrual plan and an allocation request such as described
in the added test and validate the allocation request
- Run the scheduled action for accrual plan computation
- Check the number of allocated days
Expected behavior:
The first level should bring 6 days, the second 3 days and the last
1 day for a total of 10 days
Current behavior:
The 3 level give non integer values closed to the expected for a
total of 9,... days.
Explanation:
When transiting between two levels the nextcall was the last day
of the current level to have the right level, this creates an
inconsistency as the end_date of the _process_accrual_plan_level
level should go up to the first day of the next level to have the
full number of days expected. To solve the issue we change the
level selection so that if the date is the first day of the
level it is still in the previous level. We also modify the places
where the nextcall was modified when transiting level so that there
is no more one day delta anymore.
opw-2868297
closesodoo/odoo#96665
X-original-commit: 5d055130c97c5d8367c2b71fc617f588c5e15741
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
Base the number_of_hours_display on the company calendar instead of the
employee calendar to avoid modifying the informative allocated value
in case of a working schedule change.
closesodoo/odoo#96419
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit fixes a bad call to relativedelta missing a `day` key for an
argument.
closesodoo/odoo#95705
X-original-commit: b59e81b6c34e7a4e2f35cf719c811883b289ddb5
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Create an accural plan with two levels, the first should have
its action_with_unused_accruals set as lost. The second should
start one year after the first level.
- Use this plan on a employee and make it start the first day of
the previous year.
Current behavior:
The number of allocated day is wrong and can even be negative
Expected behavior:
The days of the first level are lost and there is the right amount
of allocated days,
Eplanation:
The _end_of_the_year function was first designed to be only called
on the first day of the year but the it changed since then without
updating it's content and it can calle any day of the year now. In
this case the use of today() does not make sense and it should be
replaced by the first day of the current year.
opw-2868297
closesodoo/odoo#94897
X-original-commit: 476818972e93b32df6f25cf299f631a8f7eb3af4
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If a public holiday is created, modified or deleted,
all declared (non-refused) leaves related to that period will have
their duration re-evaluated and individual remaining time offs will
be computed accordingly.
If the duration of the leave is evaluated at 0 after the creation
of the public holiday, the leave will be set as cancelled.
task-2636215 [Time Off]Grant back time off when public day off is created
closesodoo/odoo#81225
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Create a Time off Type for which an allocation can be requested
by the employee and with approval "Set by Time Officer"
- Set a Time Off approver on the employee
- Create an allocation
Current behavior:
The allocation approval activity is assigned to the employee
Expected behavior:
The allocation approval activity is assigned to the time off officer
Explanation:
The first fix commit c2bac984f2de160008b27fb52b1d0ae7abd02abb didn't
take into consideration the "Set by Time Officer" approval, we add
here this possible value "set" in order to have a complete fix.
opw-2849972
closesodoo/odoo#92608
X-original-commit: 7239fad29c4b409097ba2a0d2f92d8b9fa8fd5ca
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
In hr_holidays, each allocation granted to an employee has a smart button to see the linked
time off for this employee.
The create button on the tree view that shows these time off opens the form
with self.env.user.employee_id as default employee.
This commit changes the default employee of the time off to be the one of the original allocation
task-2844554
closesodoo/odoo#90739
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Create a Time off Type for which an allocation can be requested
by the employee and approved by the time off officer
- Set a Time Off approver on the employee
- Create an allocation
Current behavior:
The allocation approval activity is assigned to the employee
Expected behavior:
The allocation approval activity is assigned to the time off officer
Problem
The function _get_responsible_for_approval used the validation types
of v14 instead of the one of v15.
XML modification:
While using the form for the time off types I notice that the logic
was incomplete for the "responsible time off officer" invisible and
required fields. the field can not be invisible if the approved by
time off officer is set and it should be required to avoid errors.
opw-2849972
closesodoo/odoo#92067
X-original-commit: 2e2b89eed31e74cb6123f065c7790726753d585d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit aims to improve the time off experience by:
- fixing the "cancelled" ribbon on time offs
- removing the archive dropdown action
- removing the "off until" banner in discuss if the user's leave is not validated
TaskID 2800647
closesodoo/odoo#87650
Signed-off-by: Kevin Baptiste <kba@odoo.com>
With new key of `allocation_validation_type` field, this code is no
longer relevant
closesodoo/odoo#91464
X-original-commit: 89faeeab7efe3bcc629bd4d48f44eb9a55bee9ec
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The field "Kind of leave" was a bit confusing, here we re-word the
labels to make clearer what is its purpose.
closesodoo/odoo#90942
Taskid: 2693319
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In case we try to delete an allocation, we should add a check if there
are already taken leaves, otherwise it could lead to an incoherent
situation with validated leaves without allocation while their
associated time off type is requiring allocation.
closesodoo/odoo#90932
X-original-commit: 45567dddacae82f9b4e985703cbb9e7736e9beb0
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
When the user is set in another timezone than the context timezone, the first or last work interval retrieved to calculate the number of days
between two dates is starting later or ending earlier depending on the user timezone.
The number of days displayed between two dates is therefore not an integer.
e.g.
A time off taken between 08/06/2021 and 10/06/2021 (timezone in the context is Europe/Brussels) will give:
- Number of days: 3 days if the user is in Europe/Brussels
- Number of days: 2.69 if the user is in Asia/Calcutta (first work interval starting later)
- Number of days: 2.5 if the user is in US/Pacific (last work interval ending earlier)
task-2646655
closesodoo/odoo#77036
Related: odoo/upgrade#3486
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Step to reproduce:
- As mitchell admin
- Change user's/employee tz to something != UTC
- Go to time off
- Click on the calendar
Current behaviour:
- Wizard Popup with a timezone warning
- If the same thing is done with the 'New Time Off' button, the
warning is not present
Behaviour after PR:
- No Warning
- `request_unit_custom` should be False if `holiday_status_id` is
set which might happen in default_values.
opw-2828936
closesodoo/odoo#90357
X-original-commit: 5565eb9f3dc4259f1304373eff83f7d54a0db7be
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Having a value of 0 for `maximum_leave` means 'no limit', but it was
considered as a limit of 0 - thus no days were accrued.
closesodoo/odoo#90173
Taskid: 2832160
X-original-commit: 59a319a90a4232f869811ffca62cb356a50a3acf
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In hr_holidays, when creating a time off, set the default time off type based
on the sequence of the time off type
task-2832674
closesodoo/odoo#89623
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when the user cancels his validated time off planned
in the future, the timesheets generated for this time off are not
deleted. The problem is since the timesheets are not removed we could
have duplicated timesheets if the user adds a new time off in the same days
for instance, because the newest timesheets are generated and thus we have
duplicated timesheets generated instead of having only timesheets generated
for the newest time off.
This commit removes the timesheets generated for the time off when this
time off is canceled (=archived). Also, It also prevent the user to
manually unarchive the time off since this operation is not really
managed and could introduced eventual problems.
Related PR: #76722
Part of task-2791386
closesodoo/odoo#89246
X-original-commit: a9e63ebe32079e2215acafcd4bca15b371ee9bc2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
Steps to reproduce:
- Go to time off - >New Time Off-> in the list you will see the all the times that are possible to take(that require allocation and not)
- Go to time off->My time off->create
- Select Sick Time Off
Issue:
If you want to select "Paid Time Off" it won't be displayed anymore
Cause:
When selecting a leave_type that does not require allocation the "default_date_from" is False. And so the get(key, default) does not return the default.
opw-2813263
closesodoo/odoo#89196
X-original-commit: ee6e6cb26528f42de9652b88fe022ebae2cfacfc
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
- The dashboard list view is replaced by a kanban view.
- When you have a time off with a joined document when you click on it, the attachment view is now kanban and not list. The dropdown in the kanban card allows to download the file.
taskID #2658415 [Time Off] Mobile experience
closesodoo/odoo#84667
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps :
Install modules hr_holidays and google_calendar;
Log into Odoo with two different users, one manager and one employee (subordinated): f.e. Admin e Demo;
Set Google Client ID and Google Secret with a OAuth2.0;
Check if in Odoo's Calendar the Synched with Google tag compares on the right (with manager);
From employee user, go to Time Off -> My Time Off -> My Time Off Requests and Create with a date;
From manager user, go to Time Off -> Managers -> Time Off and accept the time off created;
Go to manager's Google Calendar.
Current behavior:
Google event is created and visible for manager, employee has an event since is an attendee of the first.
Expected behavior:
Google event is created and visible for employee, manager is not involved.
Fix:
Group the leaves with user and create events with this user.
We could not modify easily the behavior of the calendar sync modules.
The following approach was tested: odoo/odoo#86385
But it has some side effects on recurring events, oultier events
(events not following the recurrence) and could bring performance issues.
The solution of this fix was chosen because it is less intrusive.
opw-2761158
closesodoo/odoo#88607
X-original-commit: ce96dd4f7488ce66d3fda5fd09a4566424c52bd2
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Steps :
Create a Time Off Type T.
Create 2 Allocations :
> Type : T
> Start date : monday D
> End date : /
> Number of days : resp 4 and 1
> Employee : Admin
Create 2 Time Off Requests :
> Type : T
> Dates : resp monday D to thursday and friday to friday.
Validate both.
Issue :
Allocation's days taken are resp 5.0/4.0 and 0.0/1.0.
Cause :
We set allocation to leave before validating.
To do so, we take the alloc with max allocated days.
Fix :
Take the alloc with max days left = allocated - taken.
Recompute the allocation before validating,
to check that enough days are left.
opw-2812534
closesodoo/odoo#88773
X-original-commit: b0bace129e3f9a4876c2cefb2c24cbcb76d8b0c6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
This is the optimal way to add a user on a group, to avoid calling the
contraint method _check_one_user_type on all the users from the group
closesodoo/odoo#87998
Related: odoo/enterprise#25908
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In hr_holidays_attendance, the model that inherits from res.users adds a request_overtime field.
This field is used to allow the user to request overtime based on the total overtime.
The domain for the time off type includes has_valid_allocation. If the user doesn't have any allocation,
he won't be able to deduct extra hours
task-2701128
closesodoo/odoo#87845
X-original-commit: b6d186d7b46df1e0f4e0af3eb7c8e7b07909a040
Related: odoo/enterprise#25843
Signed-off-by: Kevin Baptiste <kba@odoo.com>
https://github.com/odoo/odoo/pull/86101 introduced a check of the number of days
of the allocation when a time off is taken.
The _compute_from_holiday_status_id method search for allocations based on employee_id.
If a holiday has multiple employees, no allocation will be found and the validation error
message asking to split the request to fit in their number of days will appear
task-2812415
closesodoo/odoo#87818
X-original-commit: 2c4f4e4ec6b6b8a0f5233b589369e4aff70a3ca7
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Adds a new option on accrual levels to limit the days that can be
post-poned year by year.
TaskId-2768674
closesodoo/odoo#85281
Related: odoo/upgrade#3279
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps :
Create, confirm and validate 2 overlapping leave allocations :
> Type : T
> Duration : 5 days
Create, confirm and approve a time off request in the overlapping period :
> Type : T
> Duration : 10 days
Go to the allocations.
Issue :
They have respectively 0 and 10 days taken.
Cause :
hr_leave.holiday_allocation_id is m2o, so 2 allocations cannot be
attributed to the same leave request.
_compute_from_holiday_status_id() sets the first valid (in terms of
validity dates) allocation to this field, without comparing the
number of leave days of the allocation and the request.
Fix :
Compare it. If no allocation has sufficient number of days, but their
sum is enough, ask the user to split them.
opw-2781530
closesodoo/odoo#87468
X-original-commit: a0ff3fc5888d8b6a794d40d32b2a546761dfa791
Signed-off-by: Kevin Baptiste <kba@odoo.com>
methods for others to extend functionality
1. _prepare_resource_leave_vals_list() that will prepare value for
creation
later in _create_resource_leave()
2. _create_resource_leave() now calls the
_prepare_resource_leave_vals_list()
instead of having done the job itself
closesodoo/odoo#87081
X-original-commit: 6040670f24da60b1f1b2f1814423c473cc060c8c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
To reproduce
============
- In a belgian company, set legal time type as no need approval
- as admin, take a day in the future with this time off
- in the time off form, a cancel appears (near refuse)
- Cancel the time off
The day of the time off, the flight icon is set on the employee
Purpose
=======
When cancelling a time off, we set it's `active` field to False, but its state remains `validate`,
but when fetching for users on leave, there is no check on the `active` field.
Specification
=============
To solve the issue a check on `active` field was added to the query.
opw-2784173
closesodoo/odoo#87183
X-original-commit: 5d80d7c91fe05716602e2182515a4e26ea957e41
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Step to reproduce:
- Create leave type approved by the employee manager (and no limit
allocation)
- Set User A with user B as his manager
- Set User C as a time off Officer
- As user A request leaves of the before-mentionned type
- As user C, try to approve A's leave request
Current behaviour:
- Leave is accepted
Since V15, the groups have change and `is_officer` no longer
represent time_off all approver but time_off officer.
All approver are now timeoff Administrator and so the right
of time off officer should be limited.
Behaviour after PR:
- Error is shown to the current user explaining that he need to
be the current employee manager.
opw-2753845
closesodoo/odoo#86867
X-original-commit: e34e466970cab5a3774c24ac6380d0691cc773d2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Step to reproduce:
- Create an accrual plan with the option "at the end of the year,
unused accruals will be lost" and that can be allocated every year
(in this example, 3 days)
- Create an allocation for Marc Demo based on that accrual plan
and starting in 2020.
- Run scheduled action
"Accrual Time Off: updates the number of time off"
- Connect as Marc Demo
Current behaviour:
- Marc Demo has receive a 6 day allocation
- While loop over the elapsed period doesn't take lost time into account
Behaviour after PR:
- Marc Demo receive 3 day allocation
opw-2769066
closesodoo/odoo#86369
X-original-commit: fc18355158b6724aeb3f900cae50cdab3e6d707b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit, the multi company rules were bypassed due implicit
sudos (compute_sudo and self.env.user).
The function computing the number of days will now make sure to include
the right domain.
TaskId-2791030
closesodoo/odoo#86361
X-original-commit: dbcb37ec80bb0fef0115c879c15bdc7073894290
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Small changes in the layout of the hr_leave form view,
mainly for the manager's view point
Task : #2734842 [Time Off] ux changes
closesodoo/odoo#82976
Related: odoo/enterprise#23896
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Step to reproduce:
- Create a time off type T with approval 'time off officer'
- As user U create a time off request of type T
- Login as the manager of U (which should not be a time off
officer)
- Approve the time off of U
Current Behaviour:
- Time off is approved
Behaviour after PR:
- Time off is not approved and an error is raised
opw-2753845
closesodoo/odoo#85622
X-original-commit: 8a0564369baf9de7797a58ab0cd5cae870b910cf
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Since 15.0, the time off type can have different types of approval:
- No validation neededd
- Approved by Time Off Officer
- Set by Time Off Officer
This commit adds a tooltip on the allocation_validation_type to improve usability
task-2681288
closesodoo/odoo#85265
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Prior to this commit the next call date for the first level would not
take the second level into account, as such it could be that the first
level would be completely skipped instead of being prorated properly.
TaskId-2768435
closesodoo/odoo#84899
X-original-commit: 791b801c7b96a94353031a06dd5da4eeb20ee08b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Add "Stress Days", days where employees are *not* allowed to request
a time off. Time Off officers are still allowed to request holidays on
those dates.
closesodoo/odoo#79280
Taskid: 2679873
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
When we made the b2b on Time Off, we designed the allocation settings to be like this :
1. Allow Allocation : NO (stop here)
2. If YES
Can the Employee requests Allocation himself ?
2.1. NO (stop here, cause the HR will create the allocation and it will be automatically accepted)
2.2. If YES
Who will approve the Allocation made by the Employee ?
2.2.1. Nobody, it's directly approved
2.2.2. The time off officer must approve
2.2.3. It's SET by the time off officer.
In the day to day live, the case 2.2.3. never happen. It's the same settings as 2.1. "the employee will not make an allocaiton request, it will be the HR officer"
In fact, nobody understand what is behind that settings and the technical code behind it seems obsolete.
SPECIFICATION
1. Remove the "set by time off officer"
2. If Employee Requests is set on "Not Allowed", don't display Approval : https://tinyurl.com/yxwwql83 if an allocation is created, it will be done by the HR officer and automatically approved.
task-2705150
closesodoo/odoo#81914
Related: odoo/upgrade#3247
Related: odoo/enterprise#23105
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Observed behavior
When logged in as another employee than Mitchell Admin (or equivalent
employee who has an ID of 1 in the database), the number of days
allocated and displayed in the time off type name when creating a time
off from the dashboard is by default the one of Mitchell Admin.
Expected behavior
The allocation in the time off type should reflect the allocation of the
employee
Steps to reproduce
1) Create a new user and an employee for this user
2) With the credentials of this user, create a new time off from the
dashboard calendar
3) The default time off type has the allocations of Mitchell Admin (or
equivalent employee who has an ID of 1 in the database)
task-2712193
closesodoo/odoo#81213
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Only show the leaves taken by the current employee when using the Leaves
stat button on an employee's form.
closesodoo/odoo#84609
Taskid: 2764912
X-original-commit: 7413e7c5834713381870073db02019c7dd8ea6c4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
The existing resource.calendar.leaves are unlinked when refusing the
time off, but it could still be the case with python code changing
states without calling "action_refuse".
Make sure that the resource calendar leaves are always unlinked
on stage change for validated time off.
closesodoo/odoo#84269
X-original-commit: 83c283cb4256195975ec6dfb6096172d38393217
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps :
Create a Leave Allocation :
Mode : "By Company" (just to give it to every employee).
Duration : 6 days
Create a Leave for 2 Employees A and B for week W.
Approve it.
Create a Leave for another Employee C for week W and next moday.
Issue:
Duration is 1. As a side effect, employee C still has 5 days left.
Cause:
At validation, requests with multpile employee create one leave per employee.
Then, a resource.calendar.leave is created fro eachone, including the firstone.
When creating the next request, _leave_intervals_batch looks for resource.calendar.leaves
with resource_id = C or False (which means several resources), that has been taken.
It finds the leaves taken by A and B, so it considers C is off too.
Fix:
We don't create a resource.calendar.leave for the multiple employee request.
opw:2739324
closesodoo/odoo#84078
X-original-commit: 4e3af83cdd455ae6cb82439d9e260c3f9ff0b564
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Step to reproduce:
Change the validation type of the hr.leave.type with id 1 (hlt1) to no_validation
Create a new time off request with a time off type different from hlt1
Current Behaviour:
Time off state is 'draft'
Behaviour After PR:
Default time off state is correctly computated.
opw-2713600
closesodoo/odoo#84007
X-original-commit: 5a26f3402d5760f7860897f2c64d359c7af7d14b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
William Braeckman