The query below
https://github.com/odoo/odoo/blob/81497125d8100c6bdd2dc30434232a88a419a3e3/addons/hr_work_entry/models/hr_work_entry.py#L92-L115
has bad performance without the bespoken indices on `date_start` and
`date_stop`. We can speed it up more with an index on `employee_id`.
This is not enough for DBs with many work entries (500K+), specially
during upgrades.
Here we optimize the query to take into account only the work entries
being modified.
This issue was observed during an upgrade saas~12.3->13.0 where the
payslip recomputation never ends due to the increased amount of hr work
entries created. Note how the first 1K payslips are processed in 1 hour
(~16 payslips per minute), while the latest 3 (before the upgrade
was killed) took 1 min.
```
2021-11-02 21:05:44,403 2229 INFO db_42897 odoo.modules.migration: module hr_payroll: Running migration [$saas~12.4.1.0] end-compute-amount
2021-11-02 21:06:44,577 2229 INFO db_42897 odoo.upgrade: [1.61%] 1120/69635 payslip processed in 0:01:00.036716 (total estimated time: 1:02:12.729213)
2021-11-02 21:07:44,602 2229 INFO db_42897 odoo.upgrade: [2.66%] 1853/69635 payslip processed in 0:02:00.062972 (total estimated time: 1:15:11.918540)
...
2021-11-05 09:59:46,565 2229 INFO db_42897 odoo.upgrade: [47.95%] 33390/69635 payslip processed in 2 days, 12:54:02.025479 (total estimated time: 5 days, 7:00:30.261882)
2021-11-05 10:01:04,990 2229 INFO db_42897 odoo.upgrade: [47.95%] 33393/69635 payslip processed in 2 days, 12:55:20.450549 (total estimated time: 5 days, 7:02:32.725840)
```
opw-2672031
closesodoo/odoo#80898
X-original-commit: 47b7a760c5788782c65136e529c8283fe5f0cce2
Signed-off-by: Nicolas Seinlet (nse) <nse@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>
Purpose
=======
There is no way for _error_checking() to detect conflicts in work
entries that have been introduced in concurrent transactions, because of the transaction
isolation.
So if 2 transactions create work entries in parallel it is possible to create a conflict
that will not be visible by either transaction. There is no way to detect conflicts
between different records in a safe manner unless a SQL constraint is used, e.g. via
an EXCLUSION constraint [1]. This (obscure) type of constraint allows comparing 2 rows
using special operator classes and it also supports partial WHERE clauses. Similarly to
CHECK constraints, it's backed by an index.
1: https://www.postgresql.org/docs/9.6/sql-createtable.html#SQL-CREATETABLE-EXCLUDEclosesodoo/odoo#64028
Taskid: 2357844
Related: odoo/enterprise#15546
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The `_error_checking()` context manager is used to perform validation
and cleanup after changes on work entries, and is implemented using a
try/finally clause.
This mechanism fails to take into account that the alteration operation
can fail due to a concurrent update (in another transaction). In such a
situation the db cursor becomes instantly invalid, and any attempt to
use it will fail with:
`psycopg2.InternalError: current transaction is aborted`.
This exception will be raised in the `finally` block, and will therefore
discard the original TransactionRollbackException.
The result: instead of being silently retried as expected,
the transaction fails and the user receives a cryptic error message.
Steps to repro: repeatedly click on the button to validate a leave
Solution: specifically handle PostgreSQL `OperationalError` exceptions
and do not attempt to use the cursor when they occur - just let the
exception bubble up.
closesodoo/odoo#59612
X-original-commit: 7ba47e7215df69b6556a848532e4f33ef4243e83
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Make some fields editable in multi edit.
Some onchange are tranformed in compute fields.
id=2078674
closesodoo/odoo#39711
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
When the many2xxx field relates to a model where company_id is required, set
this domain [('company_id','=',company_id.id)]
When the company_id field of the related model is not required, set this domain
['|',('company_id','=',company_id.id),('company_id','=',False)]
When setting the domain on a field which is in the treeview of a xxx2many field
evaluate against the company_id of the 'parent'.
Some constraints have been added on sereval models. Take a look at the complete
specification for more details.
TaskID: 2024446
Closes: #35266
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose
=======
We would like to re-use the work entries in the attendance module.
As hr_attendance is not dependant on hr_payroll, we move the whole
mechanism into its own module.
This could be reused too into others modules, like forecasting or whatever.
TaskID: 1904850
closesodoo/odoo#34434
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Yannick Tivisse