Odoo Changelog — 2026-05-15

Friday, May 15, 2026

15 changes · saas-18.3

Bug Fixes(15)

Resolved issues and error corrections

[FIX] html_editor: reset styles when splitting styled headings

Coresaas-18.3html_editor

This update corrects an issue where pressing Enter after a styled heading created a new paragraph with the same styling. The fix now ensures that newly created paragraphs are empty and without inherited styles, aligning with the expected behavior. This improves the consistency and predictability of the HTML editor.

Original PR description

Problem:
Pressing Enter at the end of a styled heading (e.g., with a color) creates a new paragraph that inherits the heading styles.

This is no longer the expected behavior. The new paragraph should be empty and without inherited styles.

Solution:
When splitting a heading at its boundaries and creating a base container, fill it with a `br` instead of carrying over styles.

Steps to reproduce:
- Add a heading.
- Apply a style (e.g., color).
- Place the caret at the end of the heading.
- Press Enter.
- Observe that the new paragraph still has the heading color.

task-6147897

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#262150

#html_editor#formatting#editing

[FIX] l10n_pe_reports: sort entires in PL report for "Other income/expenses"

PR #117218

Enterprisesaas-18.3l10n_pe_reports

This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income'. The fix ensures that depreciation entries (expenses) are now correctly classified in the 'Other Operating Expenses' section, improving the accuracy of financial reporting.

Original PR description

**Steps to reproduce:**
- Install Accounting and l10n_pe_reports
- Switch to a Peruvian company (e.g. PE Company)
- Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000)
- Post the entry
- Check "Profit and Loss" report"

**Issue:**
The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used.
The amount should be in "Other operating expenses" section.

**Cause:**
A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section.

**Solution:**
Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses".

opw-6073666

Forward-Port-Of: odoo/enterprise#114362

#reporting#Peru#accounting

[FIX] account: correct how epd interacts with cash rounding lines

PR #264187

Coresaas-18.3accountMEDIUM

This update fixes an issue where early payment discounts on invoices with cash rounding (Modify tax amount strategy) resulted in incorrect tax calculations in payment journal entries. The fix ensures that tax amounts are accurately added when cash rounding is applied, resolving discrepancies in discount line amounts.

Original PR description

Steps to reproduce:
1. Create a sales tax for 8.1%
2. Create a cash rounding record for 0.05 as the rounding precision, “Modify tax amount” as the rounding strategy, and “Nearest” as the rounding method
3. Create a payment term with early payment discount of 2% if paid within 18 days. And reduced tax on early payment. With a due term of 100% 30 days after the invoice date
4. Create an invoice on 1/1 with a subtotal of 339.60 and the tax of 8.1% and add the cash rounding method and payment term created earlier
5. Create a payment for it 9 days later on 1/10 for the full amount after the early payment discount is applied

Cause:
tax_amounts is grabbing the amount for a certain tax from the last line on the invoice with the same tax_repartition_line_id. Usually there is only one tax line representing a certain tax on an invoice. However, when a cash rounding is applied to the invoice with a strategy of “Modify tax amount”, the cash rounding line that is created will also have the same tax_repartition_line_id. In that case, it will grab the amount on the cash rounding line instead of adding the first tax amount with the cash rounding line amount

Solution:
In tax_amounts, add to the accumulating value if a tax repartition line id already exists as a key otherwise, insert it into tax_amounts

opw-5998497

Forward-Port-Of: odoo/odoo#259025

#accounting#early payment discount#cash rounding

[FIX] web: fix read_progress_bar key mismatch on date(time) group by

PR #264184

Coresaas-18.3webMEDIUM

This update resolves an issue where Kanban progress bars weren't accurately reflecting task status when grouped by dates or times. The fix ensures consistent key formatting between the server and client, allowing progress bars to correctly display the distribution of tasks within each group. This improves the clarity and usability of Kanban views.

Original PR description

Issue
Every column's progress bar renders as a uniform grey block regardless of the actual state distribution of its records. The effect is visible only when grouping by a date/datetime field; grouping by stage or assignees still works.

The kanban relies on two separate RPCs whose keys must match: formatted_read_group (used by web_read_group) returns the columns the client stores, and the client uses each column's formatted groupby value as the lookup key; read_progress_bar returns a dict mapping that same key to per-state counts.

For a datetime group by with a time granularity,
formatted_read_group goes through _web_read_group_groupby_formatter, which localizes the naive timestamp in the user's timezone and then converts it to UTC before strftime, see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/models/models.py#L698-L726. On the client, serializeDateTime also formats in UTC, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/core/l10n/dates.js#L455-L462, so group.serverValue is the UTC-shifted string the server sent, e.g. "2025-01-01 08:00:00" for a Pacific-tz user on a 2025-year group.

read_progress_bar called _read_group directly, which returns the raw naive datetime out of date_trunc, see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/odoo/orm/models.py#L1764, so its dict was keyed by str(datetime(2025, 1, 1, 0, 0)) = "2025-01-01 00:00:00". The UTC-formatted key the client looks up in _pbCounts[groupValue], see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L69, never matched, per-state counts stayed at zero, and the synthetic "Other" bucket with color "200" (grey) absorbed the whole group.count, see
https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L88, hence the uniform grey bar.

Non-date groupbys (many2one, selection, boolean) are unaffected because their keys are scalar ids / selection codes that round-trip identically on both sides. The "None" column also works because both sides emit the literal string "False".

The regression was introduced by d5a6e97abab04282c7a69093cd790b539a958241 when read_progress_bar was switched from self.read_group(...), whose output was pre-formatted the same way the client received it, to self._read_group(...)

Solution
Route read_progress_bar through formatted_read_group, the same method web_read_group uses to build groups for the client. Both sides now run through _web_read_group_groupby_formatter, so the keys are produced by the same code path and match by construction for every field type, including date/datetime granularities.

formatted_read_group wraps relational and date/datetime groupby values as (id, display_name) / (utc_str, label) tuples, so the adapt helper unwraps the first element to restore the scalar key shape the result dict expects.

opw-6148736

Forward-Port-Of: odoo/odoo#261024

#kanban#progress bar#grouping

[FIX] l10n_fr_intrastat: include quantityInSU in DEBWEB2 XML export

PR #117319

Enterprisesaas-18.3l10n_fr_intrastatMEDIUM

This update corrects an issue where the French Intrastat export reports were missing crucial quantity data for products with supplementary units. The fix ensures that all relevant information about these products is accurately included in the DEBWEB2 XML file, complying with French regulations. This prevents potential reporting discrepancies and ensures accurate Intrastat data submission.

Original PR description

Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set…

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Forward-Port-Of: odoo/enterprise#117033

#intrastat#france#reporting#export

[FIX] iot_drivers: `db_branch` on `master`

PR #264334

Coresaas-18.3hw_drivers

This update resolves an issue where automatic updates to IoT Boxes were failing due to a random error. The system now intelligently skips the update process if the previous branch is 'master', ensuring smoother and more reliable updates. This prevents disruptions to Odoo's operation on IoT devices.

Original PR description

If `git ls-remote origin <db_branch>` randomly fails, we assume `db_branch` is `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances.

We now skip upgrade if `db_branch` is `master`.

Forward-Port-Of: odoo/odoo#264215
Forward-Port-Of: odoo/odoo#264126

#iot#updates#stability

[FIX] pos_self_order: prevent already sent items in Pay-After-Meal kitchen print

PR #248218

Coresaas-18.3pos_self_orderMEDIUM

This update resolves an issue where the kitchen print was incorrectly including previously ordered items in the Pay-After-Meal self-order flow. The fix ensures that only newly added or updated order lines are sent to the kitchen, improving the accuracy and efficiency of order fulfillment. This prevents duplicate items from being printed.

Original PR description

Steps to Reproduce:
-------------------
1. Place a self-order (Mobile / Pay-After-Meal).
2. Add a second order.
3. Kitchen print shows old + new items instead of only the new ones.

Issue:
-------------
Pay-After-Meal flow, kitchen prints included previously sent items. 

Cause:
-----------
all orderlines were sent to the kitchen instead of only new changes.

Fix:
------------
Send only newly added/updated lines to the kitchen

Task-5929555
Related PR: https://github.com/odoo/enterprise/pull/107129

#pos#self-order#kitchen print#pay-after-meal

[FIX] hr_attendance: check out on employee archive

PR #264450

Coresaas-18.3hr_attendanceMEDIUM

This update fixes a problem where employees archived through the HR system wouldn't automatically check out of their attendance records. The update ensures that employees are correctly checked out during archiving, regardless of their attendance rights, and also addresses a related access error when archiving employees with planning slots. This prevents data inconsistencies and ensures accurate attendance tracking.

Original PR description

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#264101
Forward-Port-Of: odoo/odoo#260566

#attendance#archiving#employee management

[FIX] html_editor: cache selection to handle incorrect selection from SwiftKey keyboard

PR #264613

Coresaas-18.3html_editor

This update resolves an issue where the Microsoft SwiftKey keyboard caused incorrect table cell selections, leading to unexpected focus movement. The fix caches the selection to ensure accurate tracking of the user's intended selection, improving the editor's stability and usability.

Original PR description

Problem:
When using the Microsoft SwiftKey keyboard, placing the caret at the
beginning of a table cell and triggering a `beforeinput` event can
result in `getSelection()` returning an incorrect selection.

Notably, the selection immediately before the event is correct, but it
changes unexpectedly without firing a `selection_change` event.

Solution:
Cache the selection whenever a `selection_change` event fires, ensuring
we keep the last correct selection set by the user or editor.

Steps to reproduce:
- Edit a table with an empty cell.
- Place the caret inside the empty cell.
- Press Backspace.
- Observe that the focus moves to the previous cell unexpectedly.

task-6150731

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264479
Forward-Port-Of: odoo/odoo#259798

#keyboard#table#editor

[FIX] base: cron always progressing but failing

PR #258602

Coresaas-18.3baseMEDIUM

This update resolves a recurring issue where cron jobs designed for repetitive tasks would repeatedly fail and retry, leading to system instability. The fix ensures that a cron job is consistently marked as failed if it encounters an error, preventing a loop of partial progress and retries. This improves the reliability of automated processes.

Original PR description

When the issue is always the same, we should not hope that progress is going well. If we fail every time with the same exception type and make some progress, we still should consider the run as failed.

The problem solved: cron that do some action for the same set of records like 'time-based automation' cron can have one of the actions fail. If it's not the first, some progress is made resulting in a retry and a PARTIALLY_DONE state. This retrigers the cron asap resulting in a loop.

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

#automation#cron#stability

[FIX] l10n_sa_edi: correct prepaid tax calculation with global rounding

PR #264093

Coresaas-18.3l10n_sa_ediMEDIUM

This update fixes a rounding error in the calculation of prepaid taxes for Saudi Arabia (l10n_sa_edi) invoices. The previous calculation was accumulating rounding errors, leading to an incorrect tax amount. This change ensures accurate tax calculations, aligning with Odoo's global rounding standards.

Original PR description

### Steps to reproduce: - Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules - Settings > Accounting > Rounding Method > Enable global rounding - Create sale order with 8 lines at 29.7 each…

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#263915
Forward-Port-Of: odoo/odoo#261278

#tax#saudi arabia#rounding

[FIX] hr_holidays: match correct allocation stats for duplicated leave types

PR #264631

Coresaas-18.3hr_holidaysMEDIUM

This update corrects a bug where duplicated leave types (with the same name) were causing incorrect allocation statistics to be displayed in the employee time-off request system. The fix ensures that each leave type is uniquely identified by its ID, preventing data conflicts and accurate allocation calculations.

Original PR description

Steps to reproduce:
---------------------------------------
1. Go to Time Off type which has no Company
2. Allocation Smart button > New
3. Set allocation for some days (e. g, 10 Days) > Approve allocation
4. Now, click on Employee > Time Off smart button
5. On the Dashboard, you can see allocated leaves
6. Click on any day to create a Time Off Request

Observation:
---------------------------------------
The allocated Time Off Type is not available in the request wizard, even though allocation exists.

Issue:
---------------------------------------
When natively computing allocation statistics for the UI, the `_compute_leaves` loops through a pre-fetched `data_days` structure and incorrectly extracts the calculation metrics by matching the `holiday_status.name` string via a list comprehension lookup index (`item[0]`).
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294

If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list comprehension evaluates sequentially and forcefully maps the dictionary of whichever version structurally sits first in the memory sequence directly onto both overlapping identifiers simultaneously!

Solution:
---------------------------------------
Directly match records using their unique ID.
This ensures that each database record always retrieves its own correct data, preventing any mix-up or accidental sharing of values between records that may have the same name.

opw-6105759

Forward-Port-Of: odoo/odoo#264104
Forward-Port-Of: odoo/odoo#261680

#leave#allocation#time off

[FIX] pos_stripe: allow cancellation on terminal

PR #264658

Coresaas-18.3pos_stripeMEDIUM

This update now allows customers to cancel payments made through Stripe terminals, both on the standard POS interface and on self-order kiosks. Previously, cancellation was only possible through the POS, creating a frustrating customer experience. This change improves customer satisfaction and provides a more complete payment processing solution.

Original PR description

Before this commit, when making a payment on a Stripe terminal, the only way to cancel the payment was from the POS interface. In the self order kiosk, it was impossible to cancel the payment.

After this commit, a cancel button will appear on the payment terminal for both POS and kiosk Stripe payments.

task-6166789

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264437
Forward-Port-Of: odoo/odoo#264270

#payments#stripe#pos#customer experience

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #264643

Coresaas-18.3spreadsheet

This pull request updates the core spreadsheet component within Odoo. It includes several bug fixes and improvements to the underlying infrastructure, ensuring the spreadsheet functionality remains stable and reliable. These changes address issues with color selection, package installation, and workflow processes.

Original PR description

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/76bed65119 [REL] 18.3.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/76bed65119 [REL] 18.3.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/70e2c8e1f7 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050)
https://github.com/odoo/o-spreadsheet/commit/e2d2b3493f [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/8b8bc44b6a [REL] 18.3.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1a3ac11b2f [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/c970c1de54 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/d2fa06ba7f [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c2bb3c8379 [REL] 18.3.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/998f03a0d3 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5b5147ef7f [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/66808b6063 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/af50462f8c [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

#spreadsheet#performance#stability

[FIX] mrp: show kit description on kit components

PR #264690

Coresaas-18.3mrpstockMEDIUM

This update fixes an issue where kit component descriptions were missing from delivery slips. Previously, users only saw the individual components listed, not the kit they originated from. Now, when printing delivery slips, the kit name is correctly displayed, providing clearer information for order fulfillment.

Original PR description

__ ## Short functional explanation of the error When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they…

## Short functional explanation of the error
When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they come from.

## Reproduction Steps
1. Go to settings. Under Inventory, in the Operations section, enable Packages.
2. Go to Sales and create a new quotation. Select a customer and add a kit product. Click on confirm.
3. Click on the Delivery smart button. Click on Put in Pack and Validate.
4. Click on the small cog > Print > Delivery Slip.

### Expected behavior
The kit from which the components belong should be indicated somewhere on the slip.

### Unexpected behavior
The kit isn't indicated.

## Origin of the issue
When we print a delivery slip without putting in pack, we can see on the slip that the first line, in bold, corresponds to the kit name. However, after putting in pack, the first line, in bold, indicates the Package id:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L116 Thus, the lines after will correspond to the components, of which we retrieve the details with:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L125 However, in `_get_aggregated_product_quantities`, we set the description of the components to an empty string under that case: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/mrp/models/stock_move.py#L180-L181 leaving us with no description for the components, and therefore not indicating the kit to which they belong.

__
opw-6006514

Forward-Port-Of: odoo/odoo#264159
Forward-Port-Of: odoo/odoo#254200

#kit#delivery slip#reporting

Problem: Pressing Enter at the end of a styled heading (e.g., with a color) creates a new paragraph that inherits the heading styles. This is no longer the expected behavior. The new paragraph should be empty and without inherited styles. Solution: When splitting a heading at its boundaries and creating a base container, fill it with a `br` instead of carrying over styles. Steps to reproduce: - Add a heading. - Apply a style (e.g., color). - Place the caret at the end of the heading. - Press Enter. - Observe that the new paragraph still has the heading color. task-6147897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262150

**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666 Forward-Port-Of: odoo/enterprise#114362

Issue: When creating a payment with an early payment discount, on an invoice using a cash rounding with a strategy of “Modify tax amount”, the early payment discount lines on the payment journal entry will be far off from the correct amount Steps to reproduce: 1. Create a sales tax for 8.1% 2. Create a cash rounding record for 0.05 as the rounding precision, “Modify tax amount” as the rounding strategy, and “Nearest” as the rounding method 3. Create a payment term with early payment discount of 2% if paid within 18 days. And reduced tax on early payment. With a due term of 100% 30 days after the invoice date 4. Create an invoice on 1/1 with a subtotal of 339.60 and the tax of 8.1% and add the cash rounding method and payment term created earlier 5. Create a payment for it 9 days later on 1/10 for the full amount after the early payment discount is applied Cause: tax_amounts is grabbing the amount for a certain tax from the last line on the invoice with the same tax_repartition_line_id. Usually there is only one tax line representing a certain tax on an invoice. However, when a cash rounding is applied to the invoice with a strategy of “Modify tax amount”, the cash rounding line that is created will also have the same tax_repartition_line_id. In that case, it will grab the amount on the cash rounding line instead of adding the first tax amount with the cash rounding line amount Solution: In tax_amounts, add to the accumulating value if a tax repartition line id already exists as a key otherwise, insert it into tax_amounts opw-5998497 Forward-Port-Of: odoo/odoo#259025

Steps to reproduce 1. Open any kanban view declaring a <progressbar> (e.g. Project > Tasks, or Field Service > My Tasks). 2. Group by a date or datetime field with a granularity (e.g. Creation Date: Year, planned_date_begin:day). 3. Have records spread across several groups with different state values (done, in progress, canceled, ...). 4. Observe the colored progress bar at the top of each column. Issue Every column's progress bar renders as a uniform grey block regardless of the actual state distribution of its records. The effect is visible only when grouping by a date/datetime field; grouping by stage or assignees still works. The kanban relies on two separate RPCs whose keys must match: formatted_read_group (used by web_read_group) returns the columns the client stores, and the client uses each column's formatted groupby value as the lookup key; read_progress_bar returns a dict mapping that same key to per-state counts. For a datetime group by with a time granularity, formatted_read_group goes through _web_read_group_groupby_formatter, which localizes the naive timestamp in the user's timezone and then converts it to UTC before strftime, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/models/models.py#L698-L726. On the client, serializeDateTime also formats in UTC, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/core/l10n/dates.js#L455-L462, so group.serverValue is the UTC-shifted string the server sent, e.g. "2025-01-01 08:00:00" for a Pacific-tz user on a 2025-year group. read_progress_bar called _read_group directly, which returns the raw naive datetime out of date_trunc, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/odoo/orm/models.py#L1764, so its dict was keyed by str(datetime(2025, 1, 1, 0, 0)) = "2025-01-01 00:00:00". The UTC-formatted key the client looks up in _pbCounts[groupValue], see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L69, never matched, per-state counts stayed at zero, and the synthetic "Other" bucket with color "200" (grey) absorbed the whole group.count, see https://github.com/odoo/odoo/blob/8d80ed39a2b6250bc5dfbe1f0fe4c84cc1b778ce/addons/web/static/src/views/kanban/progress_bar_hook.js#L88, hence the uniform grey bar. Non-date groupbys (many2one, selection, boolean) are unaffected because their keys are scalar ids / selection codes that round-trip identically on both sides. The "None" column also works because both sides emit the literal string "False". The regression was introduced by d5a6e97abab04282c7a69093cd790b539a958241 when read_progress_bar was switched from self.read_group(...), whose output was pre-formatted the same way the client received it, to self._read_group(...) Solution Route read_progress_bar through formatted_read_group, the same method web_read_group uses to build groups for the client. Both sides now run through _web_read_group_groupby_formatter, so the keys are produced by the same code path and match by construction for every field type, including date/datetime granularities. formatted_read_group wraps relational and date/datetime groupby values as (id, display_name) / (utc_str, label) tuples, so the adapt helper unwraps the first element to restore the scalar key shape the result dict expects. opw-6148736 Forward-Port-Of: odoo/odoo#261024

Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it. 2. Post EU customer invoices for that product. 3. Export the DEBWEB2 XML from the Intrastat report. Issue The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61 opw-6139657 Forward-Port-Of: odoo/enterprise#117033

If `git ls-remote origin <db_branch>` randomly fails, we assume `db_branch` is `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances. We now skip upgrade if `db_branch` is `master`. Forward-Port-Of: odoo/odoo#264215 Forward-Port-Of: odoo/odoo#264126

Steps to Reproduce: ------------------- 1. Place a self-order (Mobile / Pay-After-Meal). 2. Add a second order. 3. Kitchen print shows old + new items instead of only the new ones. Issue: ------------- Pay-After-Meal flow, kitchen prints included previously sent items. Cause: ----------- all orderlines were sent to the kitchen instead of only new changes. Fix: ------------ Send only newly added/updated lines to the kitchen Task-5929555 Related PR: https://github.com/odoo/enterprise/pull/107129

- Attendance checkout - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance. - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving. - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance. - Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395) - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights. - Solution: using sudo method for recompute. Task: 6131692 Forward-Port-Of: odoo/odoo#264101 Forward-Port-Of: odoo/odoo#260566

Problem: When using the Microsoft SwiftKey keyboard, placing the caret at the beginning of a table cell and triggering a `beforeinput` event can result in `getSelection()` returning an incorrect selection. Notably, the selection immediately before the event is correct, but it changes unexpectedly without firing a `selection_change` event. Solution: Cache the selection whenever a `selection_change` event fires, ensuring we keep the last correct selection set by the user or editor. Steps to reproduce: - Edit a table with an empty cell. - Place the caret inside the empty cell. - Press Backspace. - Observe that the focus moves to the previous cell unexpectedly. task-6150731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264479 Forward-Port-Of: odoo/odoo#259798

When the issue is always the same, we should not hope that progress is going well. If we fail every time with the same exception type and make some progress, we still should consider the run as failed. The problem solved: cron that do some action for the same set of records like 'time-based automation' cron can have one of the actions fail. If it's not the first, some progress is made resulting in a retry and a PARTIALLY_DONE state. This retrigers the cron asap resulting in a loop. 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

### Steps to reproduce: - Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules - Settings > Accounting > Rounding Method > Enable global rounding - Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues) - Create and confirm 100% downpayment invoice - Deliver, then create final invoice with downpayment lines - Call `_l10n_sa_get_prepaid_amount()` on final invoice > Tax amount was calculated as 35.67 instead of correct 35.64 ### Cause of Issue: The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240 This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208 ### Fix: Ensure cumulative rounding errors are avoided and correct global rounding is applied. opw-5881564 Forward-Port-Of: odoo/odoo#263915 Forward-Port-Of: odoo/odoo#261278

Pre-requisite: --------------------------------------- 1. Install the Time Off module 2. Create a new company (e.g, Test Company) 3. Create New Timeoff Type: * Ensure a default company is set (e.g, YourCompany) 4. Duplicate the created Time off type: * Remove (Copy) from the name so both records share the same name * Clear the Company field on the duplicated record Steps to reproduce: --------------------------------------- 1. Go to Time Off type which has no Company 2. Allocation Smart button > New 3. Set allocation for some days (e. g, 10 Days) > Approve allocation 4. Now, click on Employee > Time Off smart button 5. On the Dashboard, you can see allocated leaves 6. Click on any day to create a Time Off Request Observation: --------------------------------------- The allocated Time Off Type is not available in the request wizard, even though allocation exists. Issue: --------------------------------------- When natively computing allocation statistics for the UI, the `_compute_leaves` loops through a pre-fetched `data_days` structure and incorrectly extracts the calculation metrics by matching the `holiday_status.name` string via a list comprehension lookup index (`item[0]`). https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/hr_holidays/models/hr_leave_type.py#L288-L294 If Time Off Type A and Time Off Type B share the name 'Generic Leave', the list comprehension evaluates sequentially and forcefully maps the dictionary of whichever version structurally sits first in the memory sequence directly onto both overlapping identifiers simultaneously! Solution: --------------------------------------- Directly match records using their unique ID. This ensures that each database record always retrieves its own correct data, preventing any mix-up or accidental sharing of values between records that may have the same name. opw-6105759 Forward-Port-Of: odoo/odoo#264104 Forward-Port-Of: odoo/odoo#261680

Before this commit, when making a payment on a Stripe terminal, the only way to cancel the payment was from the POS interface. In the self order kiosk, it was impossible to cancel the payment. After this commit, a cancel button will appear on the payment terminal for both POS and kiosk Stripe payments. task-6166789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264437 Forward-Port-Of: odoo/odoo#264270

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/76bed65119 [REL] 18.3.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/70e2c8e1f7 [FIX] color_picker: prevent gradient from opening when picking a custom color [Task: 6186050](https://www.odoo.com/odoo/2328/tasks/6186050) https://github.com/odoo/o-spreadsheet/commit/e2d2b3493f [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/8b8bc44b6a [REL] 18.3.47 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1a3ac11b2f [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/c970c1de54 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/d2fa06ba7f [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c2bb3c8379 [REL] 18.3.46 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/998f03a0d3 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5b5147ef7f [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/66808b6063 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/af50462f8c [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

__ ## Short functional explanation of the error When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they come from. ## Reproduction Steps 1. Go to settings. Under Inventory, in the Operations section, enable Packages. 2. Go to Sales and create a new quotation. Select a customer and add a kit product. Click on confirm. 3. Click on the Delivery smart button. Click on Put in Pack and Validate. 4. Click on the small cog > Print > Delivery Slip. ### Expected behavior The kit from which the components belong should be indicated somewhere on the slip. ### Unexpected behavior The kit isn't indicated. ## Origin of the issue When we print a delivery slip without putting in pack, we can see on the slip that the first line, in bold, corresponds to the kit name. However, after putting in pack, the first line, in bold, indicates the Package id: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L116 Thus, the lines after will correspond to the components, of which we retrieve the details with: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L125 However, in `_get_aggregated_product_quantities`, we set the description of the components to an empty string under that case: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/mrp/models/stock_move.py#L180-L181 leaving us with no description for the components, and therefore not indicating the kit to which they belong. __ opw-6006514 Forward-Port-Of: odoo/odoo#264159 Forward-Port-Of: odoo/odoo#254200