The previous domain fix 84d8bf8167
was skipping all potential leaves of type other left out for work entries
therefore properly inherit instead of overriding and add the proper domain
closesodoo/odoo#128527
X-original-commit: 076d2179ad2f19c0ff8be043e492bdc7b780baef
Signed-off-by: Kevin Baptiste <kba@odoo.com>
From 7s to 2ms for this query with 2.6M records
explain (analyze, verbose, buffers)
SELECT "hr_work_entry"."id" FROM "hr_work_entry" WHERE
(
("hr_work_entry"."active" = true) AND
(
(
("hr_work_entry"."state" in ('validated', 'draft')) AND
("hr_work_entry"."contract_id" in (548259))
)
AND
(
(
(
(("hr_work_entry"."date_start" >= '2023-05-01 00:00:00') AND (
"hr_work_entry"."date_start" < '2023-05-31 23:59:59.999999')
) AND
("hr_work_entry"."date_stop" > '2023-05-31 23:59:59.999999')
)
OR
((("hr_work_entry"."date_start" < '2023-05-01 00:00:00') AND
("hr_work_entry"."date_stop" <= '2023-05-31 23:59:59.999999')) AND
("hr_work_entry"."date_stop" > '2023-05-01 00:00:00'))
) OR
(("hr_work_entry"."date_start" < '2023-05-01 00:00:00') AND
("hr_work_entry"."date_stop" > '2023-05-01 23:59:59.999999'))
)
)
)
ORDER BY COALESCE("hr_work_entry"."conflict", false) DESC,
"hr_work_entry"."state" ,"hr_work_entry"."date_start"
;
closesodoo/odoo#124108
Signed-off-by: Yannick Tivisse (yti) <yti@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>
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).
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
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
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>
- hr_contract: Add kanban view on contract history action
- hr_contract: Display the avg wage, not the sum on aggregates
- hr_contract: Improve contract history list view
- hr_contract: Improve contract history tree view
- hr_contract: Improve contract history search view
- hr_contract: Display wage on contract kanban view
- hr_contract: Improve contract tree view
- hr_contract: Improve contract search view
- hr_contract: Make hr_responsible required
It is useful in multiple HR flows.
- hr_contract: Improve contract history form view
- hr_contract: Improve contract form view
- hr_work_entry: Improve work entry computed name
- hr_work_entry: Improve work entries tree view
- hr_work_entry: Improve work entry type form view
closesodoo/odoo#72402
Taskid: 2558171
Related: odoo/enterprise#19124
Related: odoo/upgrade#2583
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the hr_work_entry_contract contained enterprise views/features that could not be integrated in community.
These features are now provided by the hr_work_entry_contract_enterprise module.
taskid: 2222790
Before this commit, the module dependencies: hr_contract and hr_work_entry were defined in community.
As they could be integrated with some community applications, like hr_attendance or hr_holidays, it is more coherent to move them to community.
Taskid: 2222790
Wolfgang Taferner