Monday, September 1, 2025
19 changes · saas-18.3
Enhancements to existing features
This update allows tax return period calculations to be adjusted when needed, instead of always relying on the current configured period. This helps migration processes accurately recreate older returns whose dates may not match today's settings.
Original PR description
The method _get_period_boundaries not allow to override the targetted period and start_date. This is used for the migration script to recreate old returns that not always has the same period as the one configured. See: https://github.com/odoo/upgrade/pull/8288
Resolved issues and error corrections
This fix avoids checking empty PDF documents for encryption in the sales PDF quote builder. It prevents unnecessary errors when empty documents are encountered, helping sales quote setup and data loading complete reliably.
Original PR description
If the document is empty we don't need to check for encryption. Otherwise we risk getting an error. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line…
If the document is empty we don't need to check for encryption. Otherwise we risk getting an error.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 544, in _tag_root
f(rec)
File "/home/odoo/src/odoo/18.0/odoo/tools/convert.py", line 444, in _tag_record
record = model._load_records([data], self.mode == 'update')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5500, in _load_records
data['record']._load_records_write(data['values'])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5418, in _load_records_write
self.write(values)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4827, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
check(self)
File "/home/odoo/src/odoo/18.0/addons/sale_pdf_quote_builder/models/product_document.py", line 46, in _check_attached_on_and_datas_compatibility
utils._ensure_document_not_encrypted(base64.b64decode(doc.datas))
File "/home/odoo/src/odoo/18.0/addons/sale_pdf_quote_builder/utils.py", line 12, in _ensure_document_not_encrypted
if pdf.PdfFileReader(io.BytesIO(document), strict=False).isEncrypted:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/tools/pdf/__init__.py", line 91, in __init__
super().__init__(stream, strict)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 317, in __init__
self.read(stream)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 1408, in read
self._basic_validation(stream)
File "/home/odoo/.local/lib/python3.12/site-packages/PyPDF2/_reader.py", line 1449, in _basic_validation
raise EmptyFileError("Cannot read an empty file")
PyPDF2.errors.EmptyFileError: Cannot read an empty file
```
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
Forward-Port-Of: odoo/odoo#224674Miscellaneous changes
**Issue** Credit notes submitted to TicketBAI incorrectly include a positive ImporteTotalFactura in the generated XML, instead of a negative value. **Steps to Reproduce** 1. Install Accounting and TicketBAI modules. 2. Create, confirm, and send an invoice. 3. Reverse the invoice to create a credit note. 4. Confirm and send the credit note. 5. Download the generated XML and observe the total amount. **Root Cause** The _get_importe_desglose_foreign_partner method did not account for w
Original PR description
**Issue** Credit notes submitted to TicketBAI incorrectly include a positive ImporteTotalFactura in the generated XML, instead of a negative value. **Steps to Reproduce** 1. Install Accounting and TicketBAI modules. 2. Create, confirm, and send an invoice. 3. Reverse the invoice to create a credit note. 4. Confirm and send the credit note. 5. Download the generated XML and observe the total amount. **Root Cause** The _get_importe_desglose_foreign_partner method did not account for whether the move is a credit note or an invoice. As a result, the total amount (ImporteTotalFactura) is always positive **Fix** Use the existing is_refund parameter to correctly apply the sign to the total amount based on the document type. Opw-4814241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212954
This fixes an issue where applying a gift card in Point of Sale could create an extra gift card line with a zero amount. Orders now avoid confusing duplicate discount lines, making checkout totals clearer for cashiers and customers.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358 Forward-Port-Of: odoo/odoo#224777 Forward-Port-Of: odoo/odoo#223948
This fixes an internal automated test so its expected results no longer vary depending on cached routing data. It helps keep quality checks reliable and reduces false alarms during development, with no direct change for end users.
Original PR description
runbot-231489
Fixed an issue where the calendar's 'show more' link could not be clicked on non-working days with many events. Users can now open the full event list instead of accidentally triggering the event creation popup.
Original PR description
**PROBLEM** If you add a lot of daily event on a off-day, the "show more" link to show all events is not clickable. Clicking bring the event creation popover. **REPRO STEPS** 1. install calendar and hr. 2. on a off day (grey background) in the week or day view, add events until the "show more" link shows up. 3. click on it, and notice the event creation popover pops up instead of the event list popover. **CAUSE** FullCalendar css class fc-non-business have a zindex of 1, a div with this class is "above" the link. **FIX** Removing a line that removed the css class fc-daygrid-more-link to the "more-link" element. Modifying css to keep the style consistent even with this new class. opw-4844719 Forward-Port-Of: odoo/odoo#221007
Purchase order lines now consistently display both the vendor-specific product name and the internal product name across all pages. This helps buyers avoid confusion when reviewing multi-page purchase orders with vendor product naming.
Original PR description
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the…
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the settings. If you can't disable it, you can disable the view `purchase.order.form.inherit.matrix` to trigger the bug. - Create a product - Go to the purchase sheet - Add a vendor - Add the field "Vendor Product Name" and "Vendor Product Code" and fill them - Create a purchase order - Add your product - Add your product a second time (on a second line) - Confirm the PO - Activate debug mode - Go to the view and add a limit to have only 1 POL per page - Return to your PO - Go to the second page #### Current behavior: - Only the vendor name is displayed #### Expected behavior: - The vendor name should appear at the top, while the db name should be displayed under as in the first page. #### Cause of the issue: On the first page, POLs data are fetch through a `web_read` on the PO, while on other pages data are fetch through `web_read` on the POLs of the page. While fetching POL data with a `web_read` the client ask for several informations including: `name` and `product_id.display_name`. If both return the same, the client show only one, else it shows the `display_name` on top and the `name` below. - `name` return the vendor name - `product_id` is fetch with the context `partner_id` which transform the `display_name` from the db_name to the Vendor name Therefore it fetches twice the vendor name and don't have the name from the db. #### Solution: - remove the `partner_id` from the context. #### Consequence: - When adding a product to the PO, the name of the product displayed in the dropdown list will be the name from the db instead of the name of the vendor. PO confirmed that consequence is OK as long as it's still possible to search for product using vendor code, which is still possible. opw-4737337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223250
The Saudi localization now hides the “THIS IS NOT A LEGAL DOCUMENT” warning on vendor bills, vendor credit/debit notes, purchase receipts, and sales receipts. This keeps the warning limited to customer documents that need it when a QR code is missing, reducing confusion for accounting users.
Original PR description
Before this commit: - The message "THIS IS NOT A LEGAL DOCUMENT" was also displayed on Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. - The warning should only appear on Customer Invoices, Credit Notes, and Debit Notes when the QR code is missing After this commit: - The warning message is no longer displayed on all Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. Task-5044870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224473
Kit products now follow quantity-on-hand filters based on their actual computed availability from component stock. This prevents kits from appearing in product lists when they do not truly match the selected stock range, improving inventory search accuracy.
Original PR description
#### Issue: - When filtering products on "Quantity on hand", kits may appear when they shouldn't #### Step to reproduce: - with MRP - create a new product - create a BoM for this product as kit - make sure you have product of the BoM on hand - go to product - add filters: - "Quantity on hand" > 1 - "Quantity on hand" < *less_than_you_have* #### Current behavior: - kit appears #### Expected behavior: - kit doesn't show #### Cause: - kit were filtered has having both 0 quantity (as unstored product) and their quantity (computed from stock of BoM products). Therefore they were compliant with both filter. #### Solution: - remove kits from products compliant with the filter if they don't comply with the filter with their computed quantity opw-4967763 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224681 Forward-Port-Of: odoo/odoo#221224
This fix ensures the Point of Sale loyalty setup always has the pricing information it needs during testing and operation. It prevents loyalty points from being calculated or shown incorrectly when a price list setting was missing.
Original PR description
Task: [#4974071](https://www.odoo.com/odoo/my-tasks/4974071)
Runbot build error: [#182003](https://runbot.odoo.com/odoo/runbot.build.error/182003)
## Error
FAILED: [9/16] Tour PosLoyaltyTour6 → Step .loyalty-points-won:contains("26.5"). Element (.loyalty-points-won:contains("26.5")) has not been found.
## Qualifiers
{
"module": "pos_loyalty",
"test_path": "/pos_loyalty/tests/test_frontend.py", "tour_name": "PosLoyaltyTour6",
"tour_step": ".loyalty-points-won:contains("26.5")", "test_class": "TestUi",
"test_method": "test_point_per_money_spent",
"test_module": "pos_loyalty"
}
## Fix
In some cases, the POS config's pricelist_id was not available in the frontend, causing some issues. By explicitly setting use_pricelist to True on the POS config, we ensure that config.pricelist_id is properly loaded.Point of Sale now correctly reflects changes to extra prices for product options that do not create separate variants. This prevents outdated prices from appearing during sales and helps ensure customers are charged the intended amount.
Original PR description
Before this commit, when changing the extra price of a ptav with the no variant creation mode, the updated price was not loaded. After this commit, the updated extra price is correctly loaded. opw-5015868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224091
The leave statistics view has been adjusted to prevent information from visually overlapping. This makes time off data easier for employees and managers to read in the calendar and leave reporting areas.
Original PR description
This commit addresses an overlapping styling issue in the leave stats task-4945729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes self-order checkout so every selected product option is saved on the order line, matching the regular Point of Sale behavior. It helps ensure orders with configurable products are recorded accurately and can be processed consistently.
Original PR description
Before this commit, the ptav of attributes configured to create variants was not saved in the order lines. This was inconsistent with the behavior in Point of Sale, where all ptav values are saved in the order lines. opw-5020130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224080
This fix prevents accounting demo data loading from failing when a currency value is unexpectedly empty. It uses the company currency as a safe fallback, making setup and testing environments more reliable.
Original PR description
While loading demo data, there is a possibility of error from this line [1]. According to [2], the currency may come as a null recordset. And if then it causes the error [3]. [1]…
While loading demo data, there is a possibility of error from this line [1]. According to [2], the currency may come as a null recordset. And if then it causes the error [3].
[1]
https://github.com/odoo/odoo/blob/f33451af032453746ccd662580f2cf26b85031d6/addons/account/models/account_move.py#L1183
[2]
https://github.com/odoo/odoo/blob/f33451af032453746ccd662580f2cf26b85031d6/addons/account/models/account_move.py#L1174
[3] - **Traceback:-**
```ValueError: not enough values to unpack (expected 1, got 0)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 5623, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.currency()
File "/home/odoo/src/odoo/saas-18.3/odoo/http.py", line 2467, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/saas-18.3/odoo/http.py", line 1970, in _serve_db
return self._transactioning(
File "/home/odoo/src/odoo/saas-18.3/odoo/http.py", line 2034, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/src/odoo/saas-18.3/odoo/service/model.py", line 166, in retrying
env.cr.flush() # submit the changes to the database
File "/home/odoo/src/odoo/saas-18.3/odoo/sql_db.py", line 179, in flush
self.transaction.flush()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/environments.py", line 545, in flush
self.default_env.flush_all()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/environments.py", line 366, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/environments.py", line 362, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 6746, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1639, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1612, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 1661, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.3/addons/mail/models/mail_thread.py", line 467, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 4623, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields.py", line 73, in determine
return needle(*args)
File "/home/odoo/src/odoo/saas-18.3/addons/account/models/account_move.py", line 1182, in _compute_payment_state
if invoice.state == 'posted' or (invoice.state == 'draft' and not currency.is_zero(invoice.amount_total)):
File "/home/odoo/src/odoo/saas-18.3/odoo/addons/base/models/res_currency.py", line 261, in is_zero
self.ensure_one()
File "/home/odoo/src/odoo/saas-18.3/odoo/orm/models.py", line 5626, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
**Solution:-**
- This commit adds a fallback to `self.env.company.currency_id` to ensure a valid currency is always available.
**Sentry - 6427055389**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents an error that could occur in Discuss calls when someone leaves or crashes just as another participant joins. It makes calls more reliable by safely handling timing conflicts during connection events.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/200981, a race condition could occur where the call is over when the the rtc session matching a track event is obtained. This could occur if you crash or leave at the moment another user arrives. You could get a track event from the SFU, wait for the rtc session record from Odoo, leave te call, finally get the rtc session from odoo. This would lead to a traceback as this handler expected that the call was still ongoing. Forward-Port-Of: odoo/odoo#224658 Forward-Port-Of: odoo/odoo#224588
The Chilean electronic invoicing demo setup now includes the required certificate serial number. This prevents errors when users test sending invoices to the Chilean tax authority in demo environments, without affecting real production certificates.
Original PR description
**Issue** When installing l10n_cl_ed, the `subject_serial_number` field is left empty. This causes an error when attempting to send an invoice to the SII. **Steps to Reproduce** 1. Install Accounting and l10n_cl_edi 2. Create and confirm an invoice 3. Click "Send Now to SII" 4. Error: Invalid Operation **Root Cause** The `subject_serial_number` is not set during installation, and this field is required for electronic document generation. **Fix** Restore the behavior from version 17.0 by setting a default `subject_serial_number` if it's missing and the certificate is available. This ensures the demo data is functional and allows users to test the SII integration out-of-the-box. Opw-4961801 Forward-Port-Of: odoo/enterprise#90636
Gantt popover cards now show standard labels such as Name, Start, and Stop in the user's selected language. This fixes an issue where custom Studio menus using Gantt views displayed these labels in English even for non-English users.
Original PR description
Steps to Reproduce: - Change the language to something other than English. - Create a new menu in the Appointment module using Studio. - Link that menu with the existing model (Resource Time of…
Steps to Reproduce: - Change the language to something other than English. - Create a new menu in the Appointment module using Studio. - Link that menu with the existing model (Resource Time of Detail). - Save the changes and add the Gantt view - Save the changes and close Studio. - View this new menu in the Gantt view Issue: - When clicking onto the kanban popover card for any record, the labels will remain as "Name" , "Start" , and "Stop" in English, and it will not translate. Reason: - [1] changed the rendering of default kanban card templates from XML to JS. This changed the default template to be static. Fix: - Add a call to the translation core tool "_t" on the three labels upon their generation in _getKanbanViewParams(). This ensures that the arch template that is generated is translated correctly into the user's set language. [1] : b2e31239041e6b7850888a3ae070c3f8a40ea5ee [opw-4861899](https://www.odoo.com/odoo/my-tasks/4861899) Forward-Port-Of: odoo/enterprise#90605
The French VAT report preparation now handles missing setup information more safely, avoiding crashes in certain payroll accounting configurations. This improves reliability when the system calculates VAT amounts before all required report dates or report details are available.
Original PR description
steps to reproduce the issue : 1- install l10n_fr_hr_payroll_account without demo data 2- and run this test .test_computed_fields_without_dependencies Added a dependencies using…
steps to reproduce the issue :
1- install l10n_fr_hr_payroll_account without demo data
2- and run this test .test_computed_fields_without_dependencies
Added a dependencies using @api.depends('report_id', 'date_from', 'date_to') on the _compute_vat_amount method to ensure automatic re-evaluation when any of these fields change.
In test_computed_fields_without_dependencies, the record is created using model.new(), which means required fields like report_id, date_from, and date_to may not be set yet. This caused a crash due to ensure_one() on an empty report_id.
Even though these fields are required, they are not automatically filled when using model.new() (unlike saved records).
Also introduced early exits by setting default values (vat_amount = 0.0, is_vat_due = False) and skipping computation when any of the required fields (report_id, date_from, date_to) or result VAT lines are missing because of ensure_one() in options.
These safeguards prevent errors in the test
build_error-115299
Forward-Port-Of: odoo/enterprise#87608This fix updates French VAT reporting so reimbursement entries use the proper account. It helps ensure VAT reimbursement accounting is posted correctly and reduces the risk of manual corrections.
Original PR description
This commit will change the account used for the reimbursement move. task-4932427 Forward-Port-Of: odoo/enterprise#91212