Thursday, September 3, 2026
15 changes · 19.0
Resolved issues and error corrections
Uploading BIS3 vendor bill XML files no longer fails when the supplier country is not included in the file. The system now falls back to the country saved on the related partner record, helping Belgian companies process supplier bills more reliably.
Original PR description
Steps to reproduce: - Install accounting and create BE company - Create BIS3 xml where there's no country for AccountingSupplierParty - From BE company, upload the xml vendor bill Current behavior: Error when trying to upload xml Expected behavior: No error Cause of issue: Currently there's no check to see if a country exists in the BIS3 xml. This PR adds a check and adds a fallback to get the country attached to the partner record if there's none present in the xml opw-6498830 Forward-Port-Of: odoo/odoo#284862 Forward-Port-Of: odoo/odoo#284554
Portal users could sometimes see a “not found” page when opening a task from a project they follow, even though the task appeared in their task list. This fix checks their normal read permission for the task, making access more consistent and reducing confusion.
Original PR description
Before this commit, the portal user could have a request not found when he wants to access to a task from a project he follows even if he can access to the task in /my/tasks route. This commit makes sure the read access are checked instead of checking if the user can access to the task thanks to the token since the token if the one of the project.
Invoices that are already paid or have no remaining balance will no longer automatically include a payment QR code. This avoids wasting invoice space and reduces the chance that customers mistakenly try to pay an invoice that is already settled.
Original PR description
**Description of the issue/feature this PR addresses:** It does not make sense to provide a QR Code for payment when the invoice is already settled because this would just waste space on the invoice and might be wrongly interpreted **Current behavior before PR:** QR Code always assigned without consent (most likely by the user) **Desired behavior after PR is merged:** QR Code should only applied automatically when the invoice is unpaid Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Automated checks for financial reports were updated to wait for report lines to finish loading before continuing. This reduces random test failures and helps keep report functionality validation stable after performance-related rendering changes.
Original PR description
After https://github.com/odoo/enterprise/pull/127516 report lines that are folded or filtered are no longer kept in the DOM with d-none. They are now removed entirely to reduce the number of rendered components on large reports. This made several tours non-deterministic. The tours unfolded multiple lines in succession using positional nth-child selectors. Since unfolding now creates new rows, the next positional selector could match an existing row before the previous DOM update was completed, causing the tour to click the wrong line. The tour would then wait indefinitely for a child of the intended line to appear. We should wait for the expected child line after each unfold before continuing with the next action. Also make some positional triggers more specific by checking the expected line name. This ensures that each DOM update is completed before the following nth-child selector is evaluated. [error-946088](https://runbot.odoo.com/odoo/error/946088)
The Helpdesk SLA Status Analysis report now calculates "Hours Open" from ticket creation to ticket closing, matching the Ticket Analysis report. This gives managers consistent and accurate reporting on how long tickets stayed open, instead of confusing it with time to assignment.
Original PR description
1. Open Helpdesk > Tickets and create a ticket on the team "Customer Care", assigned to yourself 2. More than an hour later, move it to the "Solved" stage to close it 3. Open Helpdesk > Reporting > Ticket Analysis, switch to the pivot view and pick the "Hours Open" measure -> the ticket holds the hour it stayed open 4. Open Helpdesk > Reporting > SLA Status Analysis and pick the "Hours Open" measure as well -> the ticket holds nothing, as it was assigned as soon as it was created odoo/enterprise#47454 added the "Hours Open" measure of the ticket analysis to the SLA status analysis, but computes it up to the assignment date instead of the closing date. The measure therefore holds the hours until the ticket was assigned, which the report already offers as "Working Hours to Assign". With this commit, both reports count the hours from the creation of the ticket to its closing. Forward-Port-Of: odoo/enterprise#130170
The return creation wizard now checks for duplicate returns only within the relevant company. This prevents users working with multiple active companies from being incorrectly blocked by returns that belong to another company.
Original PR description
To reproduce the issue: 1) Create two companies in Belgium: A and B 2) Manually create a return for A before its opening date 3) Switch to company B, and keep A active as well 4) Try creating a return of the same type and at the same date as in 2) ===> The wizard blocks you and displays a warning saying there's already a return at this date. There is, but for another company. We fix that by properly filtering the company when searching for existing returns. Moving the _read_group inside the loop on self is okay here: we'll never compute that field for multiple wizards at once.
This fixes an internal automated test for Canadian CPA005 payment processing by ensuring expected results are checked in a consistent order. It helps keep validation reliable and prevents false test failures, with no direct change to customer-facing features.
Original PR description
Sorts the expected items in `test_cpa005` to ensure consistent ordering. runbot error: https://runbot.odoo.com/odoo/error/941567 Forward-Port-Of: odoo/enterprise#127703
This fixes internal test failures that could occur around midnight in Belgium due to a mismatch between UTC and the configured local timezone. It helps keep automated validation stable without changing business functionality for users.
Original PR description
## Issue By default in Odoo, `datetime.now()` returns the UTC time, which is two hours behind the local time in Belgium. This leads to two tests failing when executed between 00:00 and 02:00 Belgian…
## Issue By default in Odoo, `datetime.now()` returns the UTC time, which is two hours behind the local time in Belgium. This leads to two tests failing when executed between 00:00 and 02:00 Belgian time: `test_ir_sequence_interpolation_dict` and `test_ir_sequence_iso_directives`. The `_interpolate_dict` method (responsible for interpolating the prefix/suffix from the sequences) specifies the tzinfo when calling `datetime.now()`: https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/odoo/addons/base/models/ir_sequence.py#L211-L212 Since this is not the case in the tests, the tests evaluate the date using UTC. This creates a two hours difference between the time expected and the time actually used by `next_by_code`. The tests thus fail between 00:00 and 02:00 because the evaluate dates from both `datetime.now` calls differ, leading to a mismatch in the expected prefixes. ## Fix We force the `env.tz` on the `datetime.now()` call, to mimic the behavior from the `_interpolate_dict`. runbot-242662
The demo payment provider now handles refunds correctly after a manually captured payment. This prevents transactions from getting stuck with an incorrect negative authorized amount, making demo checkout and refund testing more reliable.
Original PR description
Issue: --- When using manual capture, you can refund the transaction but it will be only authorized, and you'll then be blocked with a negative authorized amount and the impossibility to refund it. This seems to be specific to demo payment provider. Steps: 1- Enable manual capture on demo provider. 2- Buy a product from shop and checkout and pay. 3- Capture the payment in backend. Then click on post process. 4- Try refund. opw-6413515 Forward-Port-Of: odoo/odoo#282315
This fixes an issue where employees with the same name could appear in an unpredictable order, causing incorrect or inconsistent leave return dates in partner data and failing automated checks. Employee records are now ordered consistently, making HR-related information more reliable.
Original PR description
Before this commit, TestPartner.test_res_partner_to_store fails on the all-modules and per-country builds: AssertionError: '2024-06-06' != '2024-06-07' : Return date is the return date of the main…
Before this commit, TestPartner.test_res_partner_to_store fails on the all-modules and per-country builds: AssertionError: '2024-06-06' != '2024-06-07' : Return date is the return date of the main user of the partner This happens because the test reads the first entry of the hr.employee list, which holds one employee per user of the partner: back on the 7th for the main user, on the 6th for the other. This comes from "[FIX] hr*: load out-of-office dates from all user employees", which added the employees of the partner to the payload, where it held those of the main user only. The problem is that the list keeps the order of employee_ids, which is 'name' with no tiebreaker, and both employees are named test1, as an employee takes the name of its user and creating the second user renames the partner. Postgres is then free to return either one first, and the failing builds get the second one. This commit fixes the issue by ordering the employees on 'name, id', so that employees sharing a name keep a stable order instead of the one the database picks. The test asserts the whole hr.employee list, one entry per user of the partner, rather than its first entry alone, and that assertion pins the order. https://runbot.odoo.com/odoo/error/945994
This update restores the correct table layout in the inventory report after a previous change caused extra columns to appear in the report body. Users should see cleaner, properly aligned inventory reports again.
Original PR description
This reverts commit 43add3f72f29c35280869010b897c3c5656f5120. It was adding too many columns in table body after columns were removed from the header in 19.0. opw-6307728
Image upload fields now apply the Android camera workaround only on Android Chromium-based browsers that need it. This keeps camera access available on affected devices while avoiding incorrect file picker options in the native app and unaffected browsers.
Original PR description
Since Android 14, Chromium sends a file input accepting only images straight to the photo picker, which has no "Camera" entry. The image fields work around it by appending `dummy/allowAndroidCamera`…
Since Android 14, Chromium sends a file input accepting only images straight to the photo picker, which has no "Camera" entry. The image fields work around it by appending `dummy/allowAndroidCamera` to their accept attribute: a mimetype which is not an image is enough to get the generic chooser, and its camera, back. https://issues.chromium.org/issues/40937303 That invalid mimetype was appended for everyone, while only the browsers based on Chromium on Android need it: - the issue is an Android one, the desktop file dialogs are not concerned - the native app builds its own file chooser out of the accept attribute, and the invalid mimetype makes it offer the document picker on a field which only accepts images - Firefox and Safari are not based on Chromium and are not affected The workaround is now limited to the browsers needing it, and the expression moved from the template to a getter, since it is no longer a simple concatenation. Code made by Claude Supervised by RFR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286074 Forward-Port-Of: odoo/odoo#285643
A rental website test was made independent of the time of day so it no longer fails late in the UTC day. This improves reliability of automated checks without changing customer-facing behavior.
Original PR description
Scenario:
- be (or switch your computer) at time between 21:01 and 23:59 UTC
- run test test_product_attribute_value_config_get_combination_info
Result:
This error is happening:
Traceback (most recent call last):
File "…/tests/test_website_sale_product_attribute_value_config.py",
line 106, in test_product_attribute_value_config_get_combination_info
self.assertEqual(combination_info['price'], price_3_hours)
AssertionError: 6.42 != 15.0
Cause: since the time range is on multiple day, we favor a weekly price
that is more interesting and the result is not the 3 hours price.
Fix: set the date for the test.
runbot-227695
Forward-Port-Of: odoo/enterprise#130062The website editor no longer shows theme-based background options for tab sections where those choices were not working reliably. This avoids confusing website editors with settings that appear available but do not apply correctly.
Original PR description
The theme background options (`o_cc` classes) on the `s_tabs` snippet's tabs doesn't work since 18.4 (html_builder refactor). It was not supported either in previous versions. We decided to fix it so it would be useable in master (20.0) but leave stable versions as is, by restraining the available tabs and removing the theme one. task-5951656 Forward-Port-Of: odoo/odoo#277528
Code cleanup and technical improvements
This change removes an unnecessary extra safeguard around final PDF uploads for Greek electronic invoicing. It lets the upload follow the standard Send & Print process, reducing complexity while still allowing safe retries if needed.
Original PR description
The final PDF endpoint is idempotent and is safe to call repeatedly with the same invoice identifiers. Remove the unnecessary PDF-specific lock and explicit commit, let the upload status follow the normal Send & Print transaction and retry the idempotent upload when needed. Related: https://github.com/odoo/odoo/pull/281739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285889