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>
In hr_holidays, the duration field is editable but doesn't bring any added value.
The field is errorprone and not editable if you are not HR Officer. It should be the same in every case.
The duration field should be read only on the dashboard and time off creation screens.
task-2901951
closesodoo/odoo#95534
Related: odoo/enterprise#29352
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The test was randomly failing on nightly builds as the timeoff was
considered as started, thus preventing the user from modifying it.
closesodoo/odoo#95010
X-original-commit: 95f84086d15ed0a139e4e145dc2422a949f1ae95
Signed-off-by: Kevin Baptiste <kba@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>
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>
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>
There are several instances in TestAccrualAllocations where freezetime is used on a dynamic date.
This fix freezes the time to an iconic date.
task-2853089
closesodoo/odoo#91316
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>
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>
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>
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 :
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>
In 2685472 new computed fields were added in calendar_event. This commit
updates the query counter tests that were failing.
task-2685472
closesodoo/odoo#79654
Related: odoo/upgrade#3182
Signed-off-by: Yannick Tivisse (yti) <yti@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>
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>
Purpose is to update counters according to current runbot's state. This eases
checking impact of future performance improvements done.
Task-2631088 (Appointment: profile and add performance tests)
closesodoo/odoo#85838
X-original-commit: b0c7a6397526ad2698fac0701e4323c019ea8bf6
Related: odoo/enterprise#25002
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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 is a followup to odoo/odoo#3250 where a test for this case is
missing.
TaskId-2768450
closesodoo/odoo#85076
X-original-commit: 3d1f2f2d540a97506e0238f579199116aa8646dc
Signed-off-by: Kevin Baptiste <kba@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>
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>
Update some counters at latest runbot results, just to have updated counters.
Note that some counters are somehow not deterministic, hence not updating
everything.
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
test_leave_whole_company_07 test was failing due ot the hr_leave_date_check2
constraint.
This constraint check that date_from <= date_to for a leave.
date_from and date_to were not assigned any value before and had a default value
of fields.Datetime.now. Depending on which date_from or date_to is created first,
a few second difference can exist and this violates the hr_leave_date_check2 constraint
task-2726143
closesodoo/odoo#82192
X-original-commit: c51553405b727e0187c0cf27b0ef9e0cb6023056
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In test_limited_type_days_left, a time off was created with:
- 'date_from': (datetime.today() - relativedelta(days=2)),
- 'date_to': datetime.today(),
The test fails beginning of January as the allocation created at the
beginning of the test is valid between Jan 1 and Dec 31
task-2726171
closesodoo/odoo#82179
X-original-commit: df71862e59943b83584c36b08acd9700998716e1
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In test_01_leave_request_flow_limited, a time off was created with:
- 'date_from': (datetime.today() + relativedelta(days=2)),
- 'date_to': datetime.today() + relativedelta(days=3),
The test fails during the end of December because no allocation is found.
The time is now frozen in the test
task-2726308
closesodoo/odoo#82178
X-original-commit: 1d6e736832b56a4c2bf1b9e335ed2bd8f929507a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Fixes an error happening near the end of the year with one of the test.
The error was introduced with 254d6a71e8
TaskId-2724172
closesodoo/odoo#82028
X-original-commit: 1de3a4bee7b1df4960694d0851e72ef2eecb98a9
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The test `test_unused_accrual_postponed` was expecting at least 25
holidays to be accrued, but started failing around mid-December.
closesodoo/odoo#81592
X-original-commit: c2865b7f5b654a61d4b2690133797aa39712b00d
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When Freezegun is used with the `start` and `stop` method and the test
fails before the `stop`, the time stays frozen for all the other tests.
When it happens on runbot, a lot of tests brake with a lot of noise as
they are false negatives.
X-original-commit: 048796dc125b0d494f3c2fcd12625a84ee5cd91d
Part-of: odoo/odoo#81592
An employee could not confirm an allocation request of a type that doesn't need validation
Steps to reproduce:
1. Connect as admin
2. Install and open the Time Off app
3. Create a time off type in Configuration->Time Off Types with
- Requires allocation: Yes
- Approval: No validation needed
4. Connect as demo
5. Open the Time Off app and create an allocation request of the type created just before
Solution:
Add a condition before raising the error that checks the allocation validation type
OPW-2683477
closesodoo/odoo#81143
X-original-commit: d985b96ba77f45edee8001d1063f644c99a15ffc
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Description of the issue/feature this PR addresses:
In hr_holidays, there is no information about the conflicting time off when a second time off is scheduled at the same time.
There is a validation error saying "You can not set 2 time off that overlaps on the same day for the same employee".
The validation error should display the conflicting time off
Current behavior before PR:
The validation error displays the following:
"You can not set 2 time off that overlaps on the same day for the same employee"
Desired behavior after PR is merged:
The validation error will display the following:
"You can not set 2 time off that overlaps on the same day for the same employee.
Existing time off: Mitchell Admin / Trip with Family : 24.00 hours / from 06/09/2021 to 08/09/2021 / To Approve"
task-2641682
closesodoo/odoo#76452
Related: odoo/enterprise#22490
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Improves on _attendance_intervals_batch to profit more from batching.
Resources are grouped by timezone since we know they will all have the
same result except for when there are resource assigned attendances.
Those have to be handled separately but are incoroporated in the same
routine.
TaskId-2674527
closesodoo/odoo#78741
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
A lot of counters are not up to date. Seems some optimizations were done
allowing to lessen query counters.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
We were trying to sort a list of date with potentially falsy elements in
the list, causing a crash while trying to compare a date object with a
bool. This commit just makes the check that all dates are not falsy
before attempting to sort.
closesodoo/odoo#77012
X-original-commit: 6bd2a86e37809b4d77aad4597e926e99f9d2b2ce
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Since the recent time off B2B, time off validity has been moved from the
time off type to the time off allocation. Meaning that a company may use
the same time off type every year for their yearly time off.
This means that the dashboard must display currently valid data.
Remaining leaves and taken leaves will now be computed in function of
that data aswell in the dashboard.
This commit also fixes being able to take a leave if the current
allocation does not permit it if an expired one would have made it
possible.
TaskId-2636405
closesodoo/odoo#76366
X-original-commit: eeccd682124fe83d2c2342be0d8804aa2ca21146
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <Williambraecky@users.noreply.github.com>
Purpose
=======
Time Off : New Dashboard, Accruals feature, Public holidays, New time off type configuration view.
- Review of Dashboard
- Accrual feature : Currently, when you create an allocation, it's possible to create an
Accrual, but there is no appraisal Plan. An Appraisal plan is use to define steps of accruals
for each employee.
In Belgium, we use accrual Allocation for European Leaves, or compensatory hours, it's a
simple use case. But in USA, it's possible to change the calculation mode each year.
Also, in USA, it's possible to deal your accrual plan when you arrive on the company. It's a
HR Officer task to create the right Accrual allocation for each new employee.
- Public Holidays :
Improvement of global time off feature located on Working hours calendar. Now, Time off
application have to manage Public Holidays.
- Review of Time Off type configuration
COM PR: https://github.com/odoo/odoo/pull/72511
ENT PR: https://github.com/odoo/enterprise/pull/19157
UPG PR: https://github.com/odoo/upgrade/pull/2791
TaskID:2475413
closesodoo/odoo#72511
Related: odoo/enterprise#19157
Related: odoo/upgrade#2791
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: William Braeckman <wbr@odoo.com>
Co-authored-by: Xavier BOL (xbo) <xbo@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
* = test_discuss_full
Overall less queries.
Changes:
- Batch `mail_partner_format`.
- Batch `user.employee_id` compute.
- Remove query for current leave state, use fields (and prefetch) instead.
- Move current leave state in partner format instead of channel info.
Part of task-2622462
closesodoo/odoo#73174
Related: odoo/enterprise#20186
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Fixes taking a hald day outside of working hours counting as half a day
instead of nothing.
See odoo/odoo#68977closesodoo/odoo#74147
X-original-commit: 35a7308188d069465ad624d4199ec26b6d25d651
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <Williambraecky@users.noreply.github.com>
When setting the request_date_from and request_date_to when creating a
leave that will be used to show the range of days of the leaves, we are
using the current user timezone to determine it.
eg. in UTC+2 if the leave begins at midnight on the 6th, we will see 6
and not 5 which is the day in UTC.
When creating a leave in a mode different than employee, when it is
confirmed and a leave is created for each employee, we would use the UTC
day instead which is a little unexpected.
Without the fix, the added test fails with:
AssertionError: datetime.date(2019, 5, 5) !=
datetime.date(2019, 5, 6) : Timezone should be kept between company
and employee leave
opw-2573730
closesodoo/odoo#73633
X-original-commit: eb5c4e9b8d32a10e460ac089794bf1ceb9b7b71a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose
=======
Remove the "email_send" field on the <mail.channel> (mass_mailing named
on the JS side).
This feature will be introduced with a new model (<mail.group>) in a
new module in the next commit.
Remove the email notification support on the channel, so now the mail
channels work only by chat.
Remove the "subject" on the Discuss side because this was used only on
"email" channel.
Technical
=========
In the mail channel model we can drop the usage of the blacklist as well
as the usage of the "email_to" field. Those two features were mainly
used for mailing list and have no utility for "chat like" channel.
Links
=====
Task-2510267
See odoo/odoo/pull/71599
See odoo/enterprise/pull/19296
See odoo/upgrade/pull/2600
William Braeckman