In hr_holidays, when the time off type has the following settings:
- Requires allocation: Yes
- Employee Requests: Not allowed
An allocation created with this time off type still requires to be validated.
This commit removes the need to validate an allocation created with the time off type described above.
task-3004313
closesodoo/odoo#106337
X-original-commit: c98e1280aee2f31e6dbf3f52dac47cf020c628d2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Unlinking a model during uninstallation can potentially fail when the query
removing any related mail activity types fails. This happens when such a record
is still referenced in the mail_activity table. Explicitly removing related
mail activities (as is done for the activity types and other related mail data)
resolves the issue.
Two tests are added, one that demonstrates the general flow and a regression
test triggering the behavior that caused a bug in the uninstall procedure of
the hr_holidays module.
closesodoo/odoo#104152
X-original-commit: b315f7f562fc84a09d99d6e7676567eb6f285402
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>
Prior to this fix, closest_allocation_to_expire was the upcoming allocation regardless
whether there were remaining leaves on it or not.
That lead to misleading information on the dashboard.
For example, let's say user has two allocations and used up the first allocation
and has X days left on the second allocation. Still, the user will see that they have
left X days (Valid until -- the first allocation expiration date --). Which is misleading,
Instead they should see X days (Valid until -- the second allocation expiration date --).
task - 2978789
closesodoo/odoo#103813
X-original-commit: dee3552659bec78fbbce4e8af155b3259e721dbd
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, creating a leave for multiple employees
from the manager's page allowed to create leaves regardless
of the concerned employee's allocations.
After this commit, an error message will be displayed to inform
which employee cannot take that leave.
Also removes unused imports.
task-2995120
closesodoo/odoo#103733
X-original-commit: 636a8276e6797c1d8fe43da61d2fd26b558bfa45
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
In the case a time off is created:
- In the past
- Using support documents
An invalid user error is raised in the interface, because the webclient
is sending values for the field 'supported_attachment_ids' (Example: [(6, 0, [])])
which is writing by inverse relationship on the field 'attachment_ids'.
On the other hand, it should be possible for an employee to add attachment
on the time off after it has begun.
closesodoo/odoo#103626
Taskid: 3032232
X-original-commit: c32c22ec267626322aebb7af4ee36b573c71760d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since #97888 it was possible to request a leave during a stress day that
covered multiple day due to a typo in the logic.
task-2995191
closesodoo/odoo#101171
X-original-commit: 7fdb1a9980adeb5fded58b6715c3c6a5b66099ed
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In hr_holidays, the banner disappears when the number of days taken is more than the days allocated.
Also, the count of the days is based on all existing allocations.
This commit fixes the banner by allowing to display negative days remaining when there are more days taken than days allocated.
It also fixes the count of the days by couting days only for active allocations.
task-2983188
closesodoo/odoo#100452
X-original-commit: efb351f86a3645ad292fdaaa6b223ff80096b63c
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
Since https://github.com/odoo/odoo/pull/76722, it is possible to cancel an approved time off.
However, the calendar event created when the leave is validated is not archived when the leave is cancelled.
This commit archives the calendar event when the leave is cancelled.
task-2965754
closesodoo/odoo#100413
X-original-commit: d292891997a378578e072cfb01bba612501aa82a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: phwa-odoo <phwa@odoo.com>
This commit adds the possibility to link a stress day
to specific departments. If the employee is in a
sub-department of the department subject to a stress
day, the stress day will also apply for that employee.
taskID 2946420
closesodoo/odoo#97888
Signed-off-by: Kevin Baptiste <kba@odoo.com>
To reproduce the issue, set the local timezone of the computer and the user to Pacific/Auckland.
Create a new time off from the dashboard.
The date_from and date_to are one day apart.
task-2885980
closesodoo/odoo#99072
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Create Accrual plan to add 3 days with frequency Yearly on 1 of
January and days lost at the end of the year
- Submit an Allocation request for this accrual plan starting more than
2 years ago
- Run scheduled action "Accrual Time: Updates the number of time off"
Current behavior:
Allocation request calculation time off computes 0 hours
Expected behavior:
Allocation request calculation time off computes 3 hours for the
period between the first of last year and the first of this year
Explanation:
With this modification there are two changes:
1) When the attribution day is the first of january, the nextcall
set in the _end_of_the_year_accrual is the first day of next
year meaning that no days are going to be computed for the last
year period. We change that so that if the first of the year is
the attribution day then the first of the year is the nextcall and
the last call is computed accordingly.
2) If the period to compute the attributed days is acrros two years
the begining of the period is not the first of the year anymore but
the usual lastcall, this has an impact particularly on based on
worked time accrual plans.
opw-2948216
closesodoo/odoo#99728
X-original-commit: 88ba0e68c7878ac4b45cd7103bfecf9cfb567d4f
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: im_livechat, website_livechat
Access right should be based on channel type and membership instead.
Chat always private, group always private, channel private should
disapear and be a group instead (migration needed), and other channel
always public (but they can still be further restricted with
the "allowed groups" feature)
task-2632861
closesodoo/odoo#90415
Related: odoo/enterprise#30980
Related: odoo/upgrade#3850
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* = bus, hr_holidays, test_discuss_full
- use channel member instead of partner for typing
- use channel member instead of partner for all other return values from server
- remove temporary partner hack in livechat and keep public partner
- remove some obsolete convert data
- adapt format methods accordingly
task-2664853
closesodoo/odoo#98923
Related: odoo/enterprise#30760
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prior to this commit accrual levels based on worked time did not
properly compute the number of days when the period prorata was taken
into account.
TaskId-2924364
closesodoo/odoo#99183
X-original-commit: d9000d3d883ab6fa8325692f1ac5249d6822046a
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
As part of hr_holidays B2B, the holidays allowances were moved from hr_leave_type to hr_leave_allocation.
This didn't allow to take a leave longer than the maximum duration of an allocation. Also, despite all the
allocations could have enough days for a certain leave, it was not possible to use all available days without
splitting the leaves across the different allocations.
This commit moves the holidays allowance to the hr_leave_type to remediate the issues described above.
task-2834887
closesodoo/odoo#98317
X-original-commit: 8c37d5c7cc397e517c43c1ec13a131b4b35e48b7
Signed-off-by: phwa-odoo <phwa@odoo.com>
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>
niyasraphy