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>
Olivier Dony