The button to regenerate work entries was no longer disabled, thus it
lead to a traceback when clicking on it.
The warning message was confusing and misleading.
task-3203225
closesodoo/odoo#114145
X-original-commit: 5325ffd8663f14532b0f43aee25cebdb9a14aec6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit acts as a setup that allows the newly converted gantt view
extensions in enterprise to work properly.
Part-of: odoo/odoo#112756
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Some changes were made to the default/demo/test data to be more
consistent:
- Duplicates of "Paid Time Off" time off types are consolidated into
one type (inluding year specific versions, ig "Paid Time Off 2019"
- Annual Time Off is renamed back to Paid Time Off (both for the
work entry type as the time off type) to be consistent everywhere.
- All mentions of years in work entry types and time off types have
been removed, as this is no longer relevant with the new allocation
rules.
- Time off types in the default data have been explicitely made
company agnostic, in order for them to be available to all companies
and not just the one company that was select when installing
hr_holidays. This was already the case for the be_payroll data, but
not for the standard hr_holidays ones.
- Various small cosmetic / functional fixes and simplifications
(eg deduplication of data)
- expense_other_input has been made country agnostic, in order for it
to be available in all countries.
task-2978513
closesodoo/odoo#112208
X-original-commit: dcc8bbf
Related: odoo/enterprise#36819
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- Add a pubic holiday record, i.e., From 6 Feb 2023 to 7 Feb 2023
- Add a leave with the date conflicting the public holiday, i.e. From
3 Feb 2023 to 8 Feb 2023
- Regenrate the work entries and check the work entry in form view.
Current behaviour:
Missing leave_id on some work entries
Expected behaviour:
It should linked to the corresponding leave for the work entries that is
created by the leave, while public holiday work entries should keep leave_id
empty.
Explanation:
After calling contract._get_interval_leave_work_entry_type, the leaves should
be filted out the not related leaves so contract._get_more_vals_leave_interval
can get the correct vals. Otherwise public holiday will always return
{'leave_id': false} in contract._get_more_vals_leave_interval which will replace
the correct leave_id value.
closesodoo/odoo#112641
X-original-commit: 66b65074671063e762e09589c3977dec311fc9b3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Automatically compute the average number of hours per day on
resource.calendar;
- Don't allow to change the working hours of an employee when they have
a current running contract;
- Seperate smart buttons on resources to distinguish Material / Human.
task-3102517
closesodoo/odoo#109768
Related: odoo/enterprise#35718
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: hr_holidays, hr_work_entry_contract
The commit introduces a new standard view component made to implement
in a consistant way the scale/select the appropriate period to display
in a view. This component is currently used by the Calendar view.
Tests have been added for this new component, as its behavior specs must
remain comprehensive. When there is no options or only one, the button is
removed from the view to keep space available, as its purpose is reduced.
This component gives the opportunity to keep the same style and behaviors
for views implementing it (eg: Calendar, Gantt) and should be used in
other views as well as soon as they are converted to Owl.
Other modules have been adapted to use the component name in xpath instead
of the span with the o_calendar_scale_buttons element. Tests have been
adapted as well.
A scss file has been modified to prevent the arrow to be misplaced on touch
devices due to a higher padding in the dropdown item element.
part of task #2867569closesodoo/odoo#109090
Related: odoo/enterprise#35435
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, the contract smartbutton on the
employee page redirected to the contract history page.
After this commit, the user will be redirected to the running
contract or any contract if there is some, or towards a new
contract form otherwise. To access the contract history view,
a new smartbutton has been added on the contract form.
Also added some hr_responsible_id to contract in demo datas
to avoid having empty required fields for employee contracts.
task-3056891
closesodoo/odoo#105416
Related: odoo/enterprise#33799
Signed-off-by: Kevin Baptiste <kba@odoo.com>
A Payroll Manager couldn't access the work entries of their own
employees as they couldn't write the work entries generation date on the
employee's contract.
task-3014915
closesodoo/odoo#104113
X-original-commit: d6a5909f988568581c2ec5b3f83271863be85fc4
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose
=======
The cron is breaking (expected singleton error) if treating contracts
from the same company at the same time.
Actually, this shouldn't be done that way to avoid mixing unrelated
resource.calendar.leave.
Handle the contracts over 2 cron execution instead.
As the hr_homeworking module will rely on hr_work_entry to designate the
homeworking location of employees, it is necessary that work entries are
generated further in advance than up until the end of the current month, so that
employees can indicate their homeworking locations a reasonable time in advance
(at least one month).
*:
hr_contract
hr_work_entry
hr_work_entry_contract
This commit changes several views and methods to improve general usability of the payroll application
TaskID #2783013closesodoo/odoo#89311
Related: odoo/enterprise#26466
Related: odoo/upgrade#3534
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The constraint is added in `hr_payroll`, checking that if `is_unforeseen`
is True, then so must be `is_leave`. To reproduce the error simply install
`hr_payroll`, edit Work Entry Type Attendance to set as unforeseen absence
and upgrade the module `hr_work_entry_contract`.
closesodoo/odoo#92358
X-original-commit: 5448ddcbec8a1058aa271206d5a8999b3e67dda5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit aims to fix an issue with work entries generation when the
requested period is completely outside of the contracts period.
In this case no work entries should be generated.
Part-of: odoo/odoo#90933
Prep work to allow work entries to be created from multiple sources when
using contracts.
The end goal is to be able to generate work entries from attendance as
well as the planning app.
After that the plan is to make sure the implementation works well with
payroll for hourly wages.
This commit contains the necessary changes for the next work_entry
modules to work.
TaskId-2466871
While investigating an error that occured on production it was noticed
that work entry batching did not happen correctly on the first batch for
contracts that started on the same date, this is due to the microseconds
being different in the `date_generated_from` and `date_generated_to`
fields.
TaskId-2466871
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When creating a global time off in one resource.calendar A , it will be
propagated on any new resource.calendar B.
However the reverse is not true, if I delete the global time off in
calendar A it will not be deleted in calendar B.
During the work entry generation this is not taken into account, a
contract using calendar A will generate leave work entries because of
the global time off in calendar B.
This is due to a change in PR odoo/enterprise#15091.
The domain is now correct and will only fetch the right leaves.
TaskId-2627378
closesodoo/odoo#88725
X-original-commit: 0bac1d33a25e37ebece69de030b9fd72caa43a02
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Purpose
=======
Both list comprehensions are quite heavy (+- 20 seconds to generate
work entries for 1000 employees over 1 month), because they are O(n²)
X-original-commit: 21fb4786b329916cdabd0a49674d93179295cd32
Purpose
=======
Writing on untracked fields like date_generated_from will fetch allt he fields
values, including non stored ones (like wage_with_holidays, which is heavy).
X-original-commit: 5145e0782b4e3246ab84e81f4a7b450d7f463efe
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Fixes a traceback when generating work entries.
How to reproduce:
- Create a contract with a working schedule with 0 attendances
- Set the contract as running
- Make sure you have another contract for another employee running on
the same period, this one must have attendances
- Go to the work entries views, this should generate working entries for
the viewable dates
- If the work entries were already generated, go to a month where they
are not generated yet, you should have the traceback
Task ID: 2654797
closesodoo/odoo#77085
X-original-commit: 13f7f8c4e066b0a2fadef95cdff4a24a4f67f95c
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <Williambraecky@users.noreply.github.com>
Purpose
=======
The work entries generation is not scaling properly
for large employee datasets. A lot of improvements
have been made to reduce the number of query to the
database. However, one of the remaining bottleneck
was the new records insertion, made 1 by 1 on the
database.
Due to the fact that the model doens't have a lot
of columns, and doens't have columns containing
too much data (HTML fields for example), we could
imagine inserting the records by batch, for example
1000 by 1000, as it is done with SELECT.
The results weren't satisfying enough, so we prefered
using the new cron triggers mechanism, to re-trigger
the same cron at the end of its execution in another
transaction, to avoid exceeding the non return point
from which posgreSQL is pedaling in the semoule.
With this commit, it takes less than 30 seconds to
generate the work entries for 1000 employees, instead
of 3 min, and allows to generate the work entries in
a linear execution time instead of a exponential one.
Create method analysis:
=======================
Note, that only the call to the create method is
tracked, not the preprocessing time to retrieve
the work entries values.
When inserting the records 1 by 1:
----------------------------------
records - Elapsed Time (s) - AVG Time per record (s)
10 - 0.0045862197875976 - 0.00045862197875976
432 - 0.1101946830749511 - 0.00025508028489572
192 - 0.0525383949279785 - 0.00027363747358322
522 - 0.1418645381927490 - 0.00027177114596312
892 - 0.2803149223327636 - 0.00031425439723404
8800 - 3.4928441047668457 - 0.00039691410281441
88000 - 188.82338452339172 - 0.00214572027867490
176000 - 1172.4313135147095 - 0.00666154155406084
We observe that from 10.000 new record, the create
method is not scaling anymore before this commit.
For a company with 1000 employees, the mean work
entries by month is 1000*2*21=42.000 work entries,
and the time to create the records is not acceptable.
When inserting the records 1000 by 1000
---------------------------------------
records - Elapsed Time (s) - AVG Time per record (s)
10 - 0.003406763076782 - 0.0003406763076782
432 - 0.075028181076049 - 0.0001736763450834
192 - 0.030718326568603 - 0.0001599912842114
522 - 0.084228038787841 - 0.0001613563961452
892 - 0.145947217941284 - 0.0001636179573332
8800 - 2.204506397247314 - 0.0002505120905962
88000 - 181.9736533164978 - 0.0020678824240511
176000 - 1146.928646564483 - 0.0065166400372981
We observe a sligh improvement, but cleary not enough
and not worth the complexity of inserting the records
in batch on the database.
Note: The following explanation is speculative and could
be validated with a real analysis, but according to the
results we obtained with the cron, this is most likely
to be true.
In fact, this is a limitation of PosgreSQL. In the
implementation that manages the transactions, the number
of inserts becomes greater than certain memory limits,
suddenly it falls on a slower alternative storage (this
is the problem with SELECT and tuples of ids ).
When we inject 100,000 ids into a query, PosgreSQL parses
the query (already there it could have some trouble), then
it stores the ids in a data structure: hash if not too
large, other (on the file system) otherwise. Then it
executes the query and uses the data structure to check
the validity (membership).
Specification
=============
Instead of inserting the record in batch in the same
transaction, it would be more interesting to split the
transaction into several transactions:
Each transaction process N employees who have not yet been
processed, until there are no more. With the new cron
trigger mechanism, it is possible to:
- When the cron runs, it processes N employees
(N to be determined)
- If there is still some, he retriggers itself at the end
of his transaction
Like that, the cron is scheduled 1x / day, but it is
retriggered as many times as necessary each month.
Regarding the number of employees to process, with 100
employees, we can expect:
100 * 2 (morning / evening) * 21 (working days) = 4200
work entries to generate, which is manageable given
the above measures.
closesodoo/odoo#76488
Taskid: 2646056
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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>
Kevin Baptiste