Monday, August 11, 2025
9 changes · 18.0
Resolved issues and error corrections
Quotation PDF templates now correctly display numeric fields when their value is zero. This prevents customers from seeing blank fields where a valid zero amount or quantity should be shown.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Using Studio, add an integer or float field to the sale order form; 2. upload a PDF using forms as a quotation header[^1]; 3. add a mapping of the form field to the studio field; 4. create a quoation using the header; 5. have the studio field be 0; 6. print quotation. [^1]: e.g. `tests/files/test_forms.pdf` Issue ----- The form field where the zero should be displayed is empty. Cause ----- When formatting values, it returns an empty string for any falsy value whose field isn't of type boolean or monetary. Solution -------- If the value is falsy, only return the empty string if the field type is not integer or float, this way, the zero value will get formatted in the final `else` as a string value (same as non-zero numeric values). opw-4937052
Contacts without a name or email now show their available display name in chatter recipient and follower lists instead of appearing blank or as “false”. This prevents confusion when adding invoice-address contacts or followers to messages and makes recipient selection clearer.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter.
This fixes a calendar test setup so it uses valid default event information when checking a fallback case. The change helps keep automated validation reliable and reduces the risk of false failures during updates.
Original PR description
Use valid res_model/res_id in context defaults runbot-235289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222426
Incoming return slips now show the correct destination address instead of placeholder demo text. This prevents confusion for warehouse teams and partners when printing return documentation for receipts.
Original PR description
Issue ----- Incoming return slips have a "Demo Address and Name" text instead of the correct destination address. <img width="928" height="658" alt="image"…
Issue ----- Incoming return slips have a "Demo Address and Name" text instead of the correct destination address. <img width="928" height="658" alt="image" src="https://github.com/user-attachments/assets/6ff0a5e7-f1ee-4faa-a22b-76ec8f2f7a28" /> Steps to reproduce ----- - Create a receipt for a product - Print its return slip Cause ----- By default, the address is taken from the pickings location_id -> warehouse_id -> partner_id. For incoming pickings, the warehouse is the vendor one, with no associated partner. In such cases, the partner can be found directly on the picking itself with the partner_id field. Note ----- To render t-fields, qweb first applies a `rsplit` before evaluating the expression, see https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/odoo/addons/base/models/ir_qweb.py#L2015-L2016 With this in mind, using parentheses and moving `.partner_id` outside of them seems like the most readable way to go about it. ----- Ticket: opw-4660716 Forward-Port-Of: odoo/odoo#219011
This fixes an error when exporting Spanish VAT record books for invoices using the 0.26% or 1% equivalence surcharge purchase taxes. Businesses in Spain can now generate the VAT book XLSX report for these cases without the process failing.
Original PR description
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1%…
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1% Recargo Equivalencia Compras). a KeyError error occurs <img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" /> Steps to Reproduce this error: 1. Create a new database using Odoo version 18. 2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es). 3. Create a new company and set Spain as the country. 4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge". 5. Create a new quotation and select the company created in step 3. 6. Add a product with the following taxes: 0.26% and 2% VAT (G). 7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G). 8. Confirm the invoice generated from the quotation. 9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report". 10. Click the gear icon and select "VAT Record Books (XLSX)". OPW https://www.odoo.com/es_ES/my/tasks/4981807 @jco-odoo please review. Thank you! MT-10457 @moduon
The Web Studio test suite was updated to match a recent change in how suggested message recipients are returned. This helps keep automated checks reliable and reduces the risk of false test failures during future updates.
Original PR description
From the related community commit, the _message_add_suggested_recipient method is modified to also return display name under certain condition. This commit adapts the test inside web_studio to align with the method's change. Task-4812554
Field service users can once again access the map view for outgoing deliveries. This restores a useful planning view that was temporarily unavailable due to a dependency between community and enterprise features.
Original PR description
This commit is the continuity of the fix made in community. The issue fixed in community was the map view cannot be defined in the view mode of an action since the map view only exists in enterprise. This commit overrides the method defined in community to add the map view as before. Related PR: odoo/odoo#222003
The electronic signature reminder process now handles requests that do not have a validity date. This prevents scheduled reminder jobs from crashing and helps ensure signature follow-ups continue reliably.
Original PR description
The cron can fetch record with no validity date,
so the check request.validity < today
raise
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.3/odoo/tools/safe_eval.py", line 397, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "ir.actions.server(5136,)", line 3, in <module>
File "/home/odoo/src/enterprise/saas-18.3/sign/models/sign_request.py", line 437, in _cron_reminder
if request.validity < today:
^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```
Forward-Port-Of: odoo/enterprise#90279The Swedish SIE4 import now skips accounting entries that contain no transaction lines. This prevents empty or invalid journal entries from being created, improving data quality during imports.
Original PR description
The aim of this commit is making sure that we don't import move without transaction in it. In SIE4, we can have moves with BTRANS and RTRANS tags that we are ignoring. It means that we could have move without any move lines. It's not an expected behavior in Odoo. This commit checks that the move data are created only if we have lines for that move. no task id Forward-Port-Of: odoo/enterprise#91783