Daily updates from Odoo
Thursday, June 19, 2025
7 changes · 18.0
Enhancements to existing features
Archiving or moving folders with many large documents now avoids loading full file contents when they are not needed. This significantly reduces memory use and helps prevent failures for users managing heavy document collections.
Original PR description
## Issue When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`. ### Analysis The `write` override could unnecessarily fetch…
## Issue
When there are heavy (or a lot of) documents in a folder, the user cannot archive this folder as it would trigger a `MemoryError`.
### Analysis
The `write` override could unnecessarily fetch the `datas` field (binary file content).
This happened because a condition checking `record.datas` was evaluated before checking if `datas` or `url` was actually present in the values being written. This could lead to slowness when e.g. archiving/unarchiving documents, as the ORM would fetch the binary content even when it was not needed.
## Solution
We leverage Python's boolean short-circuiting to ensure that this behavior is avoided.
### Benchmarks
Profiling peak memory consumption when moving 8 documents (66 Mb each) to the trash:
| Before | After | % |
|------------|------------| --- |
| 1.3 GiB | 96 Mb | - ~93% |
Query count when unlinking account.move (using Runbot data):
| Before | After |
|------------|------------|
| 66 | 72 |
(we may avoid these additional queries by prefetching the fields beforehand, let me know your thoughts)
```
[0.564 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3398)
[0.713 ms] query: UPDATE "ir_attachment"
SET "res_id" = "__tmp"."res_id"::int4, "res_model" = "__tmp"."res_model"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4
FROM (VALUES (3398, 117, 'documents.document', '2025-06-17T15:24:12.867699'::timestamp, 22)) AS "__tmp"("id", "res_id", "res_model", "write_date", "write_uid")
WHERE "ir_attachment"."id" = "__tmp"."id"
[0.305 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."res_model", "ir_attachment"."res_id", "ir_attachment"."res_field", "ir_attachment"."public", "ir_attachment"."create_uid" FROM "ir_attachment" WHERE ("ir_attachment"."id" IN (3397))
[0.666 ms] query: SELECT "account_move"."id" FROM "account_move" WHERE ("account_move"."id" IN (255)) AND ("account_move"."company_id" IN (10)) ORDER BY "account_move"."date" DESC , "account_move"."name" DESC , "account_move"."invoice_date" DESC , "account_move"."id" DESC
[0.436 ms] query: SELECT "ir_attachment"."id", "ir_attachment"."name", "ir_attachment"."description", "ir_attachment"."res_model", "ir_attachment"."res_field", "ir_attachment"."res_id", "ir_attachment"."company_id", "ir_attachment"."type", "ir_attachment"."url", "ir_attachment"."public", "ir_attachment"."access_token", "ir_attachment"."store_fname", "ir_attachment"."file_size", "ir_attachment"."checksum", "ir_attachment"."mimetype", "ir_attachment"."create_uid", "ir_attachment"."create_date", "ir_attachment"."write_uid", "ir_attachment"."write_date", "ir_attachment"."original_id", "ir_attachment"."key", "ir_attachment"."website_id", "ir_attachment"."theme_template_id" FROM "ir_attachment" WHERE "ir_attachment"."id" IN (3397)
[0.436 ms] query: SELECT "documents_document"."id", "documents_document"."attachment_id", "documents_document"."active" FROM "documents_document" WHERE ("documents_document"."attachment_id" IN (3397)) ORDER BY "documents_document"."id" DESC
```
### References
opw-4552436
Memory flamegraphs available on the ticketResolved issues and error corrections
This update refreshes Odoo's spreadsheet component with fixes that reduce duplicate collaboration messages, improve performance during shared editing, and correct spreadsheet behaviors such as automatic resizing for array formulas. It also removes an invalid delete menu option, making spreadsheet use smoother and less confusing for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/55268816d [REL] 18.0.34 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/093517d5c [FIX] collaborative: don't send duplicate messages [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bbc9b0053 [PERF] collaborative: avoid useless transformations [Task: 4873461](https://www.odoo.com/odoo/2328/tasks/4873461) https://github.com/odoo/o-spreadsheet/commit/9216eee84 [FIX] sheet: autoresize didn't work for array formula [Task: 4822877](https://www.odoo.com/odoo/2328/tasks/4822877) https://github.com/odoo/o-spreadsheet/commit/8fac09350 [FIX] menus: hide invalid 'delete' option from edit menu [Task: 4854659](https://www.odoo.com/odoo/2328/tasks/4854659) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Sales orders now block line items where negative prices and quantities would create inconsistent totals. Return-style lines with a negative quantity and normal positive price remain allowed, helping teams avoid billing errors while preserving valid return workflows.
Original PR description
This commit introduces validation to sale.order.line to prevent inconsistent behavior with negative prices and quantities: - A negative price unit with a positive quantity now raises a UserError. - A negative quantity with a negative price unit now raises a UserError. - A negative quantity with a positive price unit (e.g., for returns) remains valid. New test cases have been added to test_sale_order.py to cover these scenarios. Additionally, sale_order_line.py and test_sale_order.py have undergone extensive linting and formatting to comply with Odoo coding standards. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The attendance kiosk now shows the correct number of employees per department when used for a company other than the default one. This prevents misleading zero counts in multi-company setups and helps staff identify the right department during check-in.
Original PR description
**PROBLEM** When using the kiosk on a company that's not the default company, the employee count displayed for all department is 0. **STEP TO REPRODUCE** 1.install the attendance module. 2.select another company. 3.go to the kiosk (attendance/Kiosk Mode). 4.identify manually. 5.notice the department count is incorrectly displayed as 0. **CAUSE** When entering the kiosk, the user is disconnected from their session, the user in this context is the public_user who have only access to the default company. The _compute_total_employee filter employees based on the company we have access to, so any employee from the non-default company are not taken into account. **FIX** We set the allowed_company_ids to the correct company id in the request context. opw-4647574
This fix prevents an error when users edit quantities or open products on quotation lines in mobile view. It ensures related line-item information is available to widgets, so sales workflows continue without crashes.
Original PR description
**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be…
**Note: issue discovered in saas-18.3**
**Step to reproduce:**
- In mobile view, create a quotation (version saas-18.3)
- Trying to change the quantity or view the product a traceback will be received
**Traceback**
```
Uncaught Promise > Cannot read properties of undefined (reading 'activeFields')
Occured on localhost:9000 on 2019-03-11 09:30:00 GMT
TypeError: Cannot read properties of undefined (reading 'activeFields')
at http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:82391:75
at async openRecord (http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:106172:18)
```
**Issue:**
fieldDependencies of widget are evaluated by `addFieldDependencies` function.
now if a field of type "x2many" is added as fieldDependencies, and field is not present in the form,
examples : [sol_product_many2one](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale/static/src/js/sale_product_field.js#L409) and [qty_at_date_widget](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L119)
the `related` key is not added for such fields by `addFieldDependencies` function
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/utils.js#L52-L76
which is required, when opening the subview here
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/static_list.js#L227-L233
**opw-4858035**
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prAppointment request emails now include configured CC contacts when manual confirmation is used. This ensures relevant contacts are informed as soon as a booking request is submitted, especially for resource-based appointments where otherwise no internal notification may be sent.
Original PR description
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go…
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521
Australian payroll now calculates overtime on top of the fixed wage instead of diluting the hourly rate across extra hours. Casual loading is also prevented from applying to overtime, helping payslips reflect the intended pay rules more accurately.
Original PR description
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remains 2000 and the computed hourly rate becomes 2000/44=45.45 Expected behavior: The hourly rate should remain the same 50. The total should increase to be: fixed_wage + hourly_rate * overtime hours 2000 + 50 * 4 = 2200 Fix: 1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate. 2.The casual loading rate should not apply to Overtime work entry types. task-4617681