Friday, September 4, 2026
24 changes · saas-19.3
Resolved issues and error corrections
This fix makes employee records with the same name appear in a consistent order when absence information is prepared. It prevents inconsistent test/build results and helps ensure the correct return-date information is selected reliably.
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 Forward-Port-Of: odoo/odoo#286603 Forward-Port-Of: odoo/odoo#286236
This fixes outdated internal documentation about how temporary records are accessed. The documentation now reflects that standard access rights and record rules apply, reducing confusion for developers and administrators without changing product behavior.
Original PR description
Since 6d8688bb124d, TransientModel records use the regular access rights mechanisms instead of being implicitly restricted to their creator. The docstring was not updated with that change and has therefore incorrectly documented creator-only access since 14.0. Forward-Port-Of: odoo/odoo#286374 Forward-Port-Of: odoo/odoo#286251
The record selector in reference fields now shows a placeholder, making it clearer that users must choose a specific record after selecting a model. This helps prevent incomplete links from being saved and later disappearing after a page refresh.
Original PR description
Steps to reproduce: 1. Install Sign. 2. Open the form view of a document. 3. Select a model in the "Link to" (Reference) field, but leave the record empty. 4. Save and refresh the page. Issue: -…
Steps to reproduce:
1. Install Sign.
2. Open the form view of a document.
3. Select a model in the "Link to" (Reference) field, but leave the record empty.
4. Save and refresh the page.
Issue:
- After refreshing, the selected model is cleared because the reference value is invalid.
Cause:
- A reference field is only valid when it contains both a model and a record ID. However, the record selector has no placeholder, making it easy to overlook and save an incomplete value.
Solution:
- Add a default placeholder to the record selector of reference fields to make it more visible.
<table>
<tr>
<th>Before</th>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/3ba34b77-f901-4d3e-9768-5acaf2e673b8" alt="Before" width="100%">
</td>
</tr>
<tr>
<th>After</th>
</tr>
<tr>
<td>
<img src="https://github.com/user-attachments/assets/1fe54b89-221f-4d28-bd2b-0a3c706d5746" alt="After" width="100%">
</td>
</tr>
</table>
opw-6426339
Forward-Port-Of: odoo/odoo#280266Editing the spacing between products in the website builder no longer makes the product grid blink or reload with every slider change. This makes designing shop pages feel smoother and avoids distracting visual interruptions while preserving the saved layout behavior.
Original PR description
Steps to reproduce: 1. Drop a "Products" dynamic snippet (or open /shop) in edit mode. 2. Click the snippet, open the Design sliding panel. 3. Drag the "Gap" slider or change its number input. Before…
Steps to reproduce: 1. Drop a "Products" dynamic snippet (or open /shop) in edit mode. 2. Click the snippet, open the Design sliding panel. 3. Drag the "Gap" slider or change its number input. Before this commit: The dynamic snippet content re-renders on every slider/input change, causing the products grid to blink. Issue: The dataset write in `SetGapAction.apply` mutates the element's dataset, which changes `getConfigurationSnapshot()` of the DynamicSnippet interaction, causing the interactions to stop and restart on every change. That write is guarded by the `needsDbPersistence` flag of the panel, which is set from the `recordName` prop. This https://github.com/odoo/odoo/commit/f427f795c24e instantiated `ProductsDesignPanel` with `recordName` on the dynamic snippet option, so from this version on the write lands on `.s_dynamic_snippet_products`, the root element of the interaction. The dataset write was originally read by `onSave()` to persist the gap. This https://github.com/odoo/odoo/commit/728049b4597b refactored persistence to read the value directly from style property value of `--o-wsale-products-grid-gap` in `product_design_list_to_save.getData()`, leaving the dataset write without any reader. Solution: Remove the unused `dataset.gapToSave` write from `SetGapAction.apply`. Inline style alone covers rendering, persistence, and dirty tracking. Also remove the now unused `needsDbPersistence` property from the panel, as it was only consumed by the removed code. task-[6535301](https://www.odoo.com/odoo/project/974/tasks/6535301)
When a cashier or manager turns off preparation printers in Point of Sale, the linked printers are now removed automatically. This prevents outdated printer settings from staying active and helps keep order preparation workflows aligned with the chosen configuration.
Original PR description
Before, when the user was unticking the preparation printer checkbox, the preparation printers were not cleared. This fix ensure that when you set the boolean to false, the preparation printers are cleaned. task-id: 6484254 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes an older cleanup step in Point of Sale that is no longer needed because a newer fix handles the issue more precisely. It reduces the risk of removing more data than necessary while keeping stale loyalty reward lines cleaned up correctly.
Original PR description
This fix is no longer required(https://github.com/odoo/odoo/pull/202752) as this one (https://github.com/odoo/odoo/pull/257043) is cleaner and less aggressive (it will only delete stale reward lines). This is the relevant part of the new fix to delete the previous one: https://github.com/odoo/odoo/pull/257043/changes#diff-18cef42f8c39513a82387e9cb81bc732b252304cd15b5b2f7b0b4623ac20cb41R100-R104 opw-6447092 Forward-Port-Of: odoo/odoo#286072 Forward-Port-Of: odoo/odoo#285376
This fix ensures Belgian payroll correctly includes canteen-related cost codes when reading payslip data. It helps prevent inaccurate payroll accounting or validation results for companies using Belgian payroll features.
Original PR description
Previous fix 9c4acee2d324a454d12dd21388ae083f99c40416 was missing a change in the list of code to read.
This fix ensures file-related controls in the HTML editor are fully cleaned up when an editor is closed or replaced. It prevents hidden leftover event handlers from accumulating over time, reducing the risk of memory leaks and gradual performance issues for users who open editors repeatedly.
Original PR description
FilePlugin registered its click, keydown and pointerdown handlers with raw `addEventListener`, so they were never removed when the plugin was destroyed. The pointerdown one is bound to the document, which outlives the editable, leaking a handler per editor instance. Use `addDomListener` so Plugin.destroy() removes them. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286144
Fixes an issue where automated accounting-related processes could fail when generating reports with elevated permissions. This helps background tasks and localization workflows complete reliably even when the initiating user does not have accounting access rights.
Original PR description
This was spotted in a dev branch for master, where we set a default account_opening_date on every company, hence trying to directly create the returns for it. Some modules need to call reports for that (like intrastat l10n), and do it in sudo(). However, even in sudo, a user without the accounting rights still doesn't have the proper group, and it raises an exception. We hence adapt the condition.
The Appointments calendar now opens on the next upcoming booking instead of jumping to the most distant future booking. This helps users quickly review and manage imminent appointments without manually navigating back through the calendar.
Original PR description
Problem: The bookings calendar of an appointment type opens on the week of the most distant booking instead of the next one, even when a booking exists later the same day. Cause:…
Problem: The bookings calendar of an appointment type opens on the week of the most distant booking instead of the next one, even when a booking exists later the same day. Cause: `action_calendar_meetings` sets the landing date from `appointments[0].start`, where `appointments` is `self.meeting_ids.filtered_domain(domain)`. `calendar.event` is ordered on `start desc` and a one2many is read in the order of its comodel, so the first record is the furthest booking rather than the next one. The original `search([...], order='start')` was replaced by the one2many in 14b5caccc325 (odoo/enterprise#23191). Solution: Sort the filtered bookings on `start` in `action_calendar_meetings`. That method is the only place the initial date is built, and `action_calendar_event_view_request` reuses it for the gantt start date, so both entry points are covered. `calendar.event` keeps its `start desc` order, which the booking list views rely on. Steps to reproduce: - Go to Appointments. - Open the appointment type "Schedule a Demo" and click Appointments. - Click New, set the date to later today, save and go back. - Click New, set the date to one year from now, save and go back. - Go back to Appointments, reopen "Schedule a Demo" and click Appointments. - Switch to the calendar view. - Observe that the calendar opens on the week of the booking one year from now. Ticket [link](https://www.odoo.com/odoo/project.task/6480029) opw-6480029 Forward-Port-Of: odoo/enterprise#130264 Forward-Port-Of: odoo/enterprise#129000
Stripe SEPA payments will once again use the company name for the bank statement description instead of the order reference. This prevents payment failures when an order reference contains only numbers, helping customers complete SEPA payments reliably.
Original PR description
**Steps to reproduce:** 1. Install Sales, l10n_be, payment_stripe and switch to belgian company 2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium 3. Enable stripe payment provider 4. Add SEPA payment method in stripe configuration 5. Create a sale order with a name that doesn't include any characters (numbers only), confirm, click preview and attempt to make a payment using SEPA **Issue:** `The statement descriptor must contain at least one Latin character.` **Cause:** The previous fix (4fde0232b821c9a1d46d589ff14495f4e19029f4) passed the order reference directly, assuming it will contain characters. The intended behavior is to actually have the company name used in the statement descriptor field: https://support.stripe.com/questions/what-is-a-statement-descriptor-and-how-do-i-update-it This was the existing behavior before the fix, so will revert back to it. opw-6497127 Forward-Port-Of: odoo/odoo#286287
This update adds test coverage to ensure spreadsheets containing images can still be exported to Excel correctly. It helps reduce the risk of broken downloads or missing visual content when users share or export spreadsheet documents.
Original PR description
Counterpart of https://github.com/odoo/odoo/pull/279788 Task-6432724 Forward-Port-Of: odoo/enterprise#130018 Forward-Port-Of: odoo/enterprise#126384
This fix prevents electronic invoice exports from crashing when the Enterprise accounting add-on is not installed. It checks whether optional deferred billing date fields are available before using them, keeping Community Edition invoice processing reliable.
Original PR description
The fields `deferred_start_date` and `deferred_end_date` are created by the enterprise addon `account_accountant`, so not having it installed, this crashes with:
```
File "/opt/odoo/auto/addons/account_edi_ubl_cii/models/account_edi_cii.py", line 684, in <listcomp>
billing_start_dates += [move_line.deferred_start_date for move_line in invoice.invoice_line_ids if move_line.deferred_start_date]
AttributeError: 'account.move.line' object has no attribute 'deferred_start_date'
```
This PR protects the access to these fields checking first if they exist.
Bug introduced in the refactoring in #261572.
@Tecnativa TT64359
Forward-Port-Of: odoo/odoo#286245This fixes an issue where tables copied from Google Docs could keep multiple header rows after being pasted into Odoo's HTML editor. The editor now treats only the first row as the table header, making pasted tables display and behave more consistently.
Original PR description
Steps to Reproduce - Copy a table with multiple header rows from Google Docs. - Paste the table into the editor. Description of the issue: - The pasted table contains multiple header rows, but the editor supports only the first row as the table header row. Cause: - During paste, `cleanForPaste` does not handle tables with multiple header rows - As a result, header cells (`<th>`) in rows other than the first row remain as header cells instead of being converted to normal table cells (`<td>`). Solution: - Update `cleanForPaste` to handle tables with multiple header rows. - If a table contains `<th>` elements in any row other than the first row, replace those `<th>` elements with `<td>` elements. - This ensures that only the first row is treated as the table header row. task-6455248 Forward-Port-Of: odoo/odoo#283862 Forward-Port-Of: odoo/odoo#281234
The inventory report table layout has been corrected after a previous change left extra body columns that no longer matched the header. This prevents confusing or misaligned report output for users reviewing stock information.
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 Forward-Port-Of: odoo/odoo#286294
This fix prevents installation errors for restaurant point-of-sale features when related point-of-sale components have not yet been upgraded. It makes the receipt template update rely on a stable existing section, reducing manual upgrade steps and avoiding disruptions for customized deployments.
Original PR description
The template for the preparation tickets was using an xpath targeting a newly added div element. This raised an error when installing the `pos_restaurant` module while an old version of `point_of_sale` was still in place, since the customer would need to manually upgrade `point_of_sale` first to have that new div element available. We now use receipt-header as the xpath target, which was always present in the template. We also refill `pos_self_order.pos_order_change_receipt` to prevent breaks with custo. --- Report: https://github.com/odoo/odoo/pull/267161#discussion_r3758115362 Forward-Port-Of: odoo/odoo#281768
This fixes an issue in the demo payment provider where refunds after manually capturing a payment could remain only authorized, leaving a negative authorized amount and blocking further refund actions. Businesses using the demo provider for testing can now complete the capture and refund flow reliably.
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#286084 Forward-Port-Of: odoo/odoo#282315
This update fixes how the HTML builder identifies the currently selected design option when some options have lower internal priority values. It helps ensure the editor shows the right applied option, reducing confusion when configuring composite design actions.
Original PR description
The function `useSelectableComponent` looked for the selected option by searching for the option with the highest priority among the options that are applied. The search for highest priority implicitely excluded options with negative priority. This case happens with `composite` action when the inner actions have no definition of `getPriority`. This commit initialize the "highest priority found so far" as `-Infinity` instead of 0. task-5245362 Forward-Port-Of: odoo/odoo#286503
French electronic invoice exports now automatically include the due date when an invoice is marked as paid. This helps ensure paid invoices comply with the latest French validation rules and reduces rejection risk during electronic invoicing.
Original PR description
According the schematron v1.4, the cbc:DueDate is required when the move is PAID. "[BR-FR-CO-09/BT-23] : Si le cadre de facturation (BT-23) est B2, S2 ou M2, alors la date d’échéance (BT-9) doit être renseignée et correspondre à la date de paiement." no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286263
Service order lines now update remaining hours when relevant unit or availability details change. This helps sales and project teams see more reliable remaining time on timesheet-based services.
Original PR description
The dependencies of _compute_remaining_hours do not match the fields actually used for the computation: it lists analytic_line_ids, which it never uses, and omits both remaining_hours_available, and product_uom. _compute_remaining_hours_available has the same issue: it uses product_uom but only depends on product_id.service_policy. analytic_line_ids, on the other hand, can be dropped: qty_delivered already depends on it, along with its so_line, unit_amount, product_uom_id and project_id, so the timesheet flow keeps triggering the recomputation. This PR fixes the dependencies for both aforementioned compute methods. Task-4748521 Forward-Port-Of: odoo/odoo#285685 Forward-Port-Of: odoo/odoo#284750
Fixed a display issue on product pages where thumbnails could become uneven or misaligned when auto-crop was disabled. This keeps the product image gallery cleaner and makes thumbnail navigation more consistent for shoppers.
Original PR description
Steps to reproduce: =================== 1. Add several images to a product, one of them much wider than tall. 2. On the product page, set the image ratio to "Disabled". 3. Move the thumbnails below…
Steps to reproduce: =================== 1. Add several images to a product, one of them much wider than tall. 2. On the product page, set the image ratio to "Disabled". 3. Move the thumbnails below the image. => The wide thumbnail sits at the top of its slot, with blank space under it. Root cause: =========== Thumbnails are given a fixed width of 64px and take their height from `aspect-ratio: var(--o-wsale-product-image-ratio)` [1]. With cropping disabled that variable is `auto`, so each thumbnail keeps the shape of its own image and they no longer share a height. They sit in a flex row, which stretches every slot to the height of the tallest one. The image inside keeps its own height and stays at the top of the slot, so a wide image leaves the rest of its slot empty. The slots are only stretched when the images differ in height, which is why the problem needs cropping to be disabled, and why it does not appear when every image is a landscape one. - [1] sized the thumbnails from the image ratio. Fix: ==== Center the thumbnails in the row so each one keeps the height of its own image instead of being stretched to the tallest. Their width stays at 64px, so a row of wide images still takes the same space as before and none of them is pushed out of the container. [1]: 670b1daa2254 opw-6472484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283246
Financial reports no longer show the unallocated earnings or losses line when it has a zero balance across all reporting columns. This keeps reports cleaner and helps users focus on meaningful figures.
Original PR description
… zero The unallocated earnings/losses line was displayed even when its balance was zero in every column group, cluttering the report with uninformative rows. We therefore filter out lines whose balance is zero across all column groups. Forward-Port-Of: odoo/enterprise#129666 Forward-Port-Of: odoo/enterprise#129129
This fixes internal tests so they use the same timezone settings as the application logic. It prevents false test failures during a narrow overnight window, improving reliability of validation without changing customer-facing behavior.
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 Forward-Port-Of: odoo/odoo#284955
Selecting a suggested partner now correctly returns the form to its saved state after the record is updated. This prevents users from seeing misleading save or discard buttons that do not perform any action.
Original PR description
Steps to reproduce: 1) open partner form view 2) type in the name field 3) select a suggestion from the autocomplete dropdown Issue: The record is enriched and saved, but the form still displays the save/discard buttons, and clicking them does nothing. The record dirty indicator is driven by 2 signals 1) `model.root.dirty`, which is cleared by save() call earlier in the onSelect() 2) the state `fieldIsDirty` of the `FormStatusIndicator` The second indicator is set to true when the user types in an input field, and selecting an option never clears it. The `setDirty` prop no longer exists, and therefore was deadcode. This commit emits `FIELD_IS_DIRTY` bus event, which is the only way to update the second indicator. With that, the indicator goes back to saved state once the record is updated. task-6475332 Forward-Port-Of: odoo/odoo#286268 Forward-Port-Of: odoo/odoo#285897