Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This traceback arises when the user changes the 'end_date' without the employee
value, while creating a new 'Work Entry'.
To reproduce this issue:
1) Install 'hr_work_entry_contract'
2) Open 'payroll' and create a new 'Work Entry'
3) Select 'Work Entry Type' as 'Unpaid' and change the 'To' date
Error:- 'KeyError: False'
On the '_get_duration_batch' method, when the user is not given employee value,
there will be no 'contract_id' as it is getting value from 'employee_id'.
It leads to the above traceback as 'result[work_entry.id]' is getting value
through 'employee.id'.
See:- https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112
Will resolve this issue by calculating duration without employee
sentry-4514970596
closesodoo/odoo#138033
X-original-commit: cc3898ad109e9dfdb220a7245936693197ed79b1
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- Install Attendances app and Employee app
- Setup an employee with a contract which work entry source is from
attendance
- Change the working schedule to different timezone, for example
Asia/Hong_Kong
- By default the working schedule should be start to work from 0800 to 1700
- Now create an attendance in the first day of the contract, i.e.
1st May 2023, check in time 0700, check out time 2000
- The total work hours should be 13
- However, in the work entry, the genearted work entry is 0800-2000, only
12 work hours.
Current behaviour:
The generated work entry mismatches the value of the attendance
Expected behaviour:
The work entry should match the attendance
Explanation:
This issue is casued by the timezone issue. When the system generate
the work entry, it will calculate the date_from datetime and date_to datetime.
Then it will compare between the attendance and the date_from datetime to choose
the larger datetime to put inside the work entry as start time.
However, the date_from datetime didn't consider the timezone of the working schedule.
In the above example, Asia/Hong Kong time is UTC+8 time. Therefore if we convert
the attendance time back to UTC time. It is check in time 30 April 2023, 2300 to
check out time 1 May 2023, 1200. In the mean time, if we compare between the date_from
datetime (1 May 2023, 0000) and the attendance check in time (30 April 2023, 2300).
The system will take the date_from time and therefore the generated work entry time
is incorrect.
task-3468012
closesodoo/odoo#134533
X-original-commit: 2baf4e3ebcd9ce3beb47ee2881aa3e8bd8a74cbf
Related: odoo/enterprise#47007
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
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
Xavier Morel