Tuesday, August 12, 2025
17 changes · saas-18.3
Enhancements to existing features
This change streamlines internal balance sheet testing by avoiding repeated setup and cleanup of accounting entries. It should reduce test execution time without changing customer-facing accounting behavior.
Original PR description
In `test_balance_sheet_balanced`, during the balance test the case first sets a bunch of lines to `posted`, then sets them (back?) to `draft`. However this is done per report, even though in the default mode the amls involved don't change between reports. Not only that, but since f2100c2654a068fe197025aecc605fdada3a919a each CoA's test case is within a savepoint, so the AMLs get reverted implicitly. Hence rejigger the thing to activate the relevant AMLs while setting up localization if not in `IDENTIFY_INCORRECT_ACCOUNTS` mode, that way we don't even pay for the activation, let alone do so repeatedly for each report we test. Backport of odoo/enterprise#88485 Forward-Port-Of: odoo/enterprise#91640
Resolved issues and error corrections
This fixes an issue where portal users could receive incorrect read access information for document messages, especially when opening documents through shared links. The change ensures the interface receives accurate access details, helping avoid misleading options or behavior in the chatter area.
Original PR description
Before this commit, the `_thread_to_store` method would always set the `hasReadAccess` property to true. This was fine because the only flow that would add the values to the store would already check the existance and access to the thread. However after change [1] the access values would be sent in more flows, one of which being portal chatter initialization. This causes the client to have incorrect access information to the thread (i.e. hasReadAccess would be true even when accessing portal document through token). This commit fixes the issue by sending the correct access values. [1] https://github.com/odoo/odoo/pull/220774 Forward-Port-Of: odoo/odoo#222545 Forward-Port-Of: odoo/odoo#222281
Incoming return slips now show the actual destination address instead of placeholder demo text. This helps warehouse and operations teams avoid confusion when printing return documents for received products.
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#221807 Forward-Port-Of: odoo/odoo#219011
The mobile shop toolbar now stays visible above the live chat bubble, preventing overlap when no pricelist is configured. This makes the mobile shopping experience clearer and avoids customers missing key purchase controls.
Original PR description
In odoo/odoo@860dccec53cb0940212fe7d9161c7e3c805867f7 the floating toolbar layout was introduced, but there was an issue with the livechat bubble which was overlapping the floating bar on mobile when there was no priceslit (error with the calc()). This PR fixes this issue by displaying the floatingbar above the livechat bubble, taking the same style when there is a pricelist or not. task-4966406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Quotation PDFs now correctly show zero values from custom integer or decimal fields instead of leaving those fields blank. This ensures generated sales quotes accurately reflect entered data and avoids confusion for customers and sales teams.
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 Forward-Port-Of: odoo/odoo#222487
Employees on flexible working schedules will no longer have public holidays deducted from their leave balance when requesting leave on those days. This keeps leave balances accurate and avoids charging employees for company holidays.
Original PR description
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public…
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public holiday. 5) Notice that the duration of the leave is 1 instead of 0. **Issue:** Due to recent changes in the [commit](https://github.com/odoo/odoo/commit/a826f65c2d95b796f919023d560ec9f0801090d8#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R427-R433) , When a single-day flexible leave is taken, the duration is always set to the real duration. However, we do not check if the leave falls on a public holiday, which results in the leave being set to 1 day, even on holidays. https://github.com/odoo/odoo/blob/8f24da78f60529ea0b1840e48de30e15d17ddb77/addons/hr_holidays/models/hr_leave.py#L427-L433 **For example:** If Christmas is marked as a public holiday and an employee with a flexible schedule requests a one-day leave on Christmas, the leave is recorded with a duration of 1 day. **Fix:** Check for a public holiday on leave date; if yes, set leave duration to 0. opw-4963122 Forward-Port-Of: odoo/odoo#220288
Steps to reproduce: 1. Install 'l10n_it' and 'accounting' from apps. 2. Enable debug mode. 3. Activate the Italian language and set it for the current user. 4. Go to Accounting > Customers / Vendors > Invoice / Bill > Electronic Invoicing tab Observation: When the Italian language is active, the 'Electronic Invoicing' tab and the fields within it are not translated. Issue: Missing translations in the PO file. Solution: Added the missing translations for the fields in the PO file.
Original PR description
Steps to reproduce: 1. Install 'l10n_it' and 'accounting' from apps. 2. Enable debug mode. 3. Activate the Italian language and set it for the current user. 4. Go to Accounting > Customers / Vendors > Invoice / Bill > Electronic Invoicing tab Observation: When the Italian language is active, the 'Electronic Invoicing' tab and the fields within it are not translated. Issue: Missing translations in the PO file. Solution: Added the missing translations for the fields in the PO file. opw-4937464
This fix ensures calendar records use valid default references when opening or creating related items. It prevents edge cases where an invalid zero identifier could cause incorrect behavior in calendar workflows.
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
The help text for choosing a project documents folder has been corrected to match current behavior. This avoids telling users that task documents are automatically moved into that folder, reducing confusion for teams organizing documents manually.
Original PR description
Before this commit, the tooltip displayed for `documents_folder_id` defined in `project.project` model, said all documents linked to a task of a project will be automatically added inside that folder but it is no longer the case since the refactoring of Documents to simplify the implementation but also let the documents user sorts his documents as he wants since now the access rights are defined by folder. This commit updates the tooltip accordingly. PR simplifying the bridge between documents and project apps: #75214 opw-5000224 Forward-Port-Of: odoo/enterprise#92164
This update adjusts accounting report tests so they align with stricter validation rules for external report calculations. It helps prevent false test failures for complex tax reports, such as Luxembourg tax annexes, without changing day-to-day user workflows.
Original PR description
The corresponding community PR (https://github.com/odoo/odoo/pull/221407) contains a fix that requires the _validate_engine constraint to reject any groupby value for the 'external' engine. Therefore, it is now needed that the test ensuring non-stored related fields can be used in groupby is adapted in order to also exclude those expressions when changing the groupby value of the lines using a custom engine on any of their expressions. Without that, complex reports like the annexes of the Luxembourgese tax report fail the test. Forward-Port-Of: odoo/enterprise#92096
The Swedish SIE4 import now handles files that do not include previous-year information without crashing. This lets accounting users import opening balances more reliably, including files that require an alternate text encoding.
Original PR description
**Issue**: Importing a SIE4 file without previous year information causes a traceback. **Steps to reproduce**: - Go to Accounting > Settings > Import - Import SIE 4 file - Check the box "Import account opening balances" - Select the right xml and observe the traceback **Cause**: The method `_prepare_sie4_opening_balance_move` tries to directly access the previous year: https://github.com/odoo-dev/enterprise/blob/6d4919658650a006c73d4aaf1f500d67723dda0d/l10n_se_sie4_import/wizard/import_wizard.py#L376C9-L376C58 This results in a traceback when the previous year is not present. **Solution**: Make `_prepare_sie4_opening_balance_move` more permissive by falling back to the day before the first day of the current year if the `-1` section is not there. **Additional Notes**: The client file does not support `UTF8` format, retry with the `ISO-8859-1` format in case of `UnicodeDecodeError`. opw-4894495 Forward-Port-Of: odoo/enterprise#89425
Field service teams can once again open outgoing stock transfers in a map view. This restores an Enterprise-only view option that was temporarily unavailable after a related community fix.
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 Forward-Port-Of: odoo/enterprise#92032
The US payroll leave type setup screen now includes the missing view update, so the intended fields appear for users. A label was also corrected, reducing confusion when configuring leave types.
Original PR description
Before this commit, the modification of the leave type views was not introduced in the manifest, resulting in the fields being absent from the view. This commit corrects the label as well as introduces that view in the manifest Forward-Port-Of: odoo/enterprise#87423
This fix ensures stock barcode tests include an email address for the user involved in quantity update notifications. It helps confirm that notifications can be sent correctly when initial demand on stock moves changes, avoiding failures caused by missing user email data.
Original PR description
Updating the initial demand of a stock move notify the users. Without email address, the notification cannot be send. As the email address of the admin user is only fill in the demo data, this commit adds one specially for the test. runbot: 226778 Forward-Port-Of: odoo/enterprise#89722
The Spanish VAT book export now recognizes the 0.26% and 1% equivalence surcharge purchase taxes. This prevents an error when exporting VAT Record Books for invoices using these tax rates, allowing affected Spanish accounting users to generate reports normally.
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 Forward-Port-Of: odoo/enterprise#92116
This change fixes an intermittent failure in an automated barcode inventory test by making the test wait for the destination location update to appear before continuing. It improves release stability and reduces false failures in quality checks without changing business functionality.
Original PR description
A non-deterministic error has been occurring across all versions starting from 18.0 when running the `test_split_line_on_destination_scan`. problem: The issue lies in one of the steps of the tour,…
A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.
problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.
Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.
Runbot-145458
Forward-Port-Of: odoo/enterprise#92006
Forward-Port-Of: odoo/enterprise#91927Automatic currency rate updates from the UAE Central Bank now include the Sudanese Pound. This ensures businesses using SDG can receive updated exchange rates without manual corrections.
Original PR description
**Steps to reproduce**: 1. Install the `account` and `l10n_ae` modules. 2. Go to `Invoicing → Configuration → Currencies` and activate the `Sudanese Pound (SDG)` currency. 3. Navigate to `Settings → Invoicing → Currencies → Automatic Currency Rates`. 4. Select `[AE] Central Bank of the UAE` as the currency provider and manually fetch rates. <img width="463" height="181" alt="image" src="https://github.com/user-attachments/assets/31257e2e-8360-4cdb-877e-2ea41487ddea" /> 5. Return to the Currencies list. **Observed behavior**: - The rate for the `Sudanese Pound (SDG)` is not updated. **Root cause**: - The `SDG` currency is missing from the `MAP_CURRENCIES` dictionary, so the provider doesn't fetch its rate. **Solution**: - Add the missing `SDG` currency mapping to `MAP_CURRENCIES`. opw-4869204 Forward-Port-Of: odoo/enterprise#91790