Odoo Changelog — 2026-05-15

Friday, May 15, 2026

28 changes · saas-19.1

Bug Fixes(28)

Resolved issues and error corrections

[FIX] l10n_ar: Fiscal Position csv translation

Coresaas-19.1l10n_ar

This update fixes a translation error in the Argentine localization (l10n_ar) module, ensuring fiscal position names accurately reflect their purpose. Previously, a confusing duplicate translation was used, now all domestic fiscal positions are correctly labeled, avoiding confusion and improving data accuracy.

Original PR description

### Description of the issue/feature this PR addresses:

Fix fiscal position spanish translation to match with its real purpose.

### Current behavior before PR:

* We have a fiscal position name that does not match with its purpose: Represent the local operations inside argentina (country: Argentina) but the name is " Purchases / Sales abroad"
* Two fiscal positions have the same translation value and this is confusing

### Desired behavior after PR is merged:

* we do not have duplicated fiscal position anymore
* Domestic fiscal position is taged with the correct name



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

Forward-Port-Of: odoo/odoo#248462

#localization#Argentina#fiscal position

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

PR #117333

Enterprisesaas-19.1l10n_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 report accuracy.

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: prevent recurring invoice creation on unreconcile

PR #264190

Coresaas-19.1accountMEDIUM

This update fixes an issue where unreconciling payments from recurring invoices would incorrectly generate a new draft invoice for the following month. The change adds a context flag to prevent this automatic invoice creation, ensuring accurate invoice generation and reducing potential accounting errors. This improves the reliability of recurring invoice processing.

Original PR description

Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated Steps to reproduce: 1. Create and confirm a monthly…

Issue:
Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated

Steps to reproduce:
1. Create and confirm a monthly recurring invoice
2. Create a payment for the invoice
3. Create a batch payment and add the payment created in step 2 then validate it
4. Create a bank statement line and reconcile it with the batch payment created in step 3
5. Unreconcile the payment from the invoice from the invoice form view
6. Notice that a draft invoice for the next month’s recurring invoice is created

Cause:
When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period

Solution:
Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line”

opw-6158881

Forward-Port-Of: odoo/odoo#263991

#recurring invoices#payments#accounting

[FIX] account_accountant_batch_payment: prevent recurring invoice creation on unreconcile

PR #117140

Enterprisesaas-19.1account

This update fixes an issue where unreconciling payments from recurring invoices would incorrectly generate a new draft invoice for the next month. The change adds a context flag to prevent this behavior, ensuring invoices are created accurately and avoiding unnecessary invoice generation. This improves invoice management efficiency.

Original PR description

Issue: Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice > Steps to reproduce: 1. Create and confirm a monthly recurring invoice 2. Create a payment for the…

Issue:
Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice >

Steps to reproduce:
1. Create and confirm a monthly recurring invoice
2. Create a payment for the invoice
3. Create a batch payment and add the payment created in step 2 then validate it
4. Create a bank statement line and reconcile it with the batch payment created in step 3
5. Unreconcile the payment from the invoice from the invoice form view
6. Notice that a draft invoice for the next month’s recurring invoice is created

Cause:
When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period

Solution:
Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line”

opw-6158881

Forward-Port-Of: odoo/enterprise#117011

#invoice#recurring#payment#batch

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

PR #264246

Coresaas-19.1accountMEDIUM

This update fixes an issue where early payment discounts on invoices with cash rounding (using 'Modify tax amount') resulted in incorrect tax calculations in payment journal entries. The fix ensures that tax amounts are accurately added during payment creation, resolving discrepancies caused by how the system handled cash rounding lines.

Original PR description

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…

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

#accounting#early payment discount#cash rounding

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

PR #264393

Coresaas-19.1webMEDIUM

This fix resolves an issue where Kanban progress bars for date/datetime grouped tasks appeared as a uniform grey color. The problem stemmed from a mismatch in how the server and client formatted date/time keys. By standardizing the key formatting process, the progress bars now accurately reflect the actual state distribution of tasks within each group.

Original PR description

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

#kanban#progress bar#grouping

[FIX] hr_payroll: Clear Payslip Warning After Cancelling

PR #117289

Enterprisesaas-19.1hr_payroll

This update corrects a misleading warning message that appeared when a payslip was cancelled in the HR payroll module. The change ensures users receive accurate information and a smoother cancellation process. This improves the overall user experience and data integrity.

Original PR description

. Clear payslip warning after cancelling the payslip
. Add corresponding tests

task-6199148

Forward-Port-Of: odoo/enterprise#116859

#payroll#hr#user experience

[FIX] survey: impossible to submit after network loss

PR #264340

Coresaas-19.1survey

This update resolves an issue where surveys would freeze after a network loss during submission. The fix ensures the submission lock is released, allowing users to retry submitting their answers after reconnecting. This improves the survey experience and prevents data loss.

Original PR description

Issue: When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even…

Issue:
When a user takes a survey and loses their internet connection just as the form attempts to submit (e.g., during a timed survey's auto-submit), the survey becomes completely unresponsive. Even if the user reconnects, they are unable to submit their answers.

Steps to reproduce:
1. Start a survey that includes a time limit.
2. Disconnect your device from the internet just before the timer runs out.
3. Wait for the timer to reach zero, triggering the auto-submit.
4. Reconnect to the internet and attempt to click "Submit" manually.
5. The action is ignored and the form remains stuck.

Cause:
To prevent duplicate submissions, the form applies a "submitting" lock the moment a submission begins. If a network failure interrupts the process, the code execution halts abruptly. Because the process crashes before reaching the end of its routine, the lock is never removed, leaving the form permanently frozen.

Solution:
Guarantee that the submission lock is released regardless of the network request's outcome. By safely wrapping the submission sequence, the form will now always unlock itself even if an error interrupts the process. This allows the user to simply try submitting again once their connection is restored, while still letting the system report the initial network failure.

Task-5787410

Forward-Port-Of: odoo/odoo#249514

#survey#form#submission#network

[FIX] im_livechat: fix non-deterministic LFH sidebar timer test

PR #257048

Coresaas-19.1im_livechat

This update resolves a test failure caused by a timing issue in the Live Chat sidebar. The fix ensures the system fully processes data before the timer is checked, making the test reliable. This improves the overall stability of the Live Chat feature.

Original PR description

Since this [PR](https://github.com/odoo/odoo/pull/252738), The test `show looking for help duration in the sidebar` was failing due to a race condition. With the following error: ``` expected at…

Since this [PR](https://github.com/odoo/odoo/pull/252738),
The test `show looking for help duration in the sidebar` was failing due to 
a race condition.

With the following error:
```
expected at least 1 element after 200ms and found 0 elements: 5 matching 
:text(Visitor #1) (1 element containing selector :text(Visitor #1) > 0 text 
elements)
```

The test was going through the join flow, which triggers `discuss.channel/joined`
and then `fetchChannel()`. Since `fetchStoreData()` is debounced, the resulting
`/mail/data` fetch could race with the later `/im_livechat/session/update_status`
call and the corresponding bus/store updates. Because the test was asserting the
timer while those async updates were still settling, it could sometimes
observe an intermediate client state and fail.

This commit fixes the race condition to wait for the `/mail/data` RPC
to fully complete, before clicking the `Looking for help` button.
This ensures the store is fully settled before the LFH timer assertion,
making the test deterministic.

runbot-[242278](https://runbot.odoo.com/odoo/error/242278)

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

#live chat#stability#test

[FIX] discuss: fix sortChannels comparison logic

PR #264398

Coresaas-19.1discuss

This update resolves a technical bug that could cause sorting issues within the Discuss channels feature. The fix ensures a consistent and reliable comparison of channel data, preventing potential infinite loops and improving overall stability. This change focuses on the core sorting logic.

Original PR description

In order to work properly, a comparison function must be anti-symmetric, that is, if `compareFn(a, b)` gives `-1`, then `compareFn(b, a)` should give `1`.

In the case of `sortChannels`, whenever `c1.displayName` is undefined, it falls back to comparing ids, but no such behavior is implemented when `c2.displayName` is missing, breaking the antisymmetry property. This flaw in the comparison function can potentially lead to infinite loops.

This commit solves the issue, explicitly handling both `c1.displayName` and `c2.displayName`, in an antisymmetric fashion.

#sorting#stability#discuss

[IMP] point_of_sale: make the "Save Order" button permanently visible

PR #261809

Coresaas-19.1point_of_sale

This update ensures the "Save Order" button is consistently displayed for users. This allows them to seamlessly save their order progress and resume it later, regardless of which device they're using within the same session. This improves the user experience and workflow for point-of-sale transactions.

Original PR description

The "Save Order" button is now always available, allowing users to easily save and resume their orders on different devices within the same session.

task-id: 5966678

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

Forward-Port-Of: odoo/odoo#250405

#pos#workflow#user experience

[FIX] auth_totp: fix `_totp_enable_search`

PR #264412

Coresaas-19.1auth_totp

A bug was preventing the 'Two-factor authentication Disabled' filter from working correctly in user lists. This update corrects a technical issue within the Odoo system's database filtering logic, ensuring the filter accurately displays users without two-factor authentication. The fix includes new tests to verify the functionality.

Original PR description

Issue: In the user view list, the "Two-factor authentication Disabled" filter doesn't work (return the same result than the "Two-factor authentication Enabled").

Explanation: The ORM normalises `=`/`!=` to `in`/`not in` with list values (commit odoo/odoo#191549 - 92301a5b300d). `_totp_enable_search` only handled the legacy scalar form: `value` is now always a list of boolean then always truthy then `[('totp_enabled', '=', False)]` returned users *with* a totp secret, the opposite of what was asked.

Fix it and add tests for it.

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

Forward-Port-Of: odoo/odoo#264027

#authentication#security#filter

[FIX] stock_account: Ensure that archived locations still counts as valued

PR #263354

Coresaas-19.1stock_accountMEDIUM

This update fixes an issue where archived warehouse locations were not being properly accounted for when calculating the total value and average cost of inventory. Previously, the system didn't consider movements to or from these archived locations, leading to inaccurate valuation reports. This change ensures that all stock movements, including those to archived locations, are correctly factored into valuation calculations.

Original PR description

When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date. OPW-6099192 --- ### Test…

When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date.

OPW-6099192

---

### Test result without fix

```
2026-04-23 06:30:34,016 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: Starting TestStockValuation.test_archived_location_valuation ... 
2026-04-23 06:30:34,255 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: ====================================================================== 
2026-04-23 06:30:34,255 10516 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_archived_location_valuation
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3326, in test_archived_location_valuation
    self.assertEqual(self.product_avco.with_context(to_date=date_1).avg_cost, 10)
AssertionError: 20.0 != 10
 ```

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

Forward-Port-Of: odoo/odoo#260922

#inventory#valuation#archiving

[FIX] sale_stock: Fix COGS computation scoped to its SaleOrderLine

PR #260495

Coresaas-19.1sale_stockstock_accountMEDIUM

This update fixes an issue where COGS calculations were inaccurate, particularly with customer returns. It ensures that quantity conversions are applied correctly and prevents incorrect monetary values from being copied to stock moves during return processing, leading to more reliable financial reporting.

Original PR description

[FIX] sale_stock: convert quantity using correct UoM

The quantity unit conversion was applied to an already
summed value, ignoring the fact that individual COGS lines may have
different UoMs.

---

[FIX] stock_account: Do not copy field 'value' of StockMove

When a customer return is split into multiple steps (e.g., Customer -> Input -> Stock),
the `value` field of the stock move was being copied from the first step to the second.
This caused the second step (which should not be valued) to inherit the monetary value,
leading to incorrect COGS entries when the invoice was posted.

The value should only be set when the move is Done, not during a copy.

---

OPW-6076350

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

Forward-Port-Of: odoo/odoo#257543

#COGS#returns#accounting

[FIX] point_of_sale: allow cash in/out without invoicing access rights

PR #264469

Coresaas-19.1point_of_sale

This update allows all Point of Sale users to record cash inflows and outflows, regardless of their invoicing access rights. Previously, this functionality was restricted, which created a bottleneck. This change simplifies the cash management process within Point of Sale and ensures consistent operation.

Original PR description

Cash In/Out was gating on `account.group_account_invoice` even though the backend operation (`account.bank.statement.line` creation) is no different from what session closing already does under sudo(). Lower `_has_cash_move_perm` to `point_of_sale.group_pos_manager`, add `sudo()` to the create call.

opw-6192176

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

Forward-Port-Of: odoo/odoo#263580

#pos#cash#transactions

[FIX] website_event_sale: hide original price for fixed price rules

PR #264470

Coresaas-19.1website_event_sale

This update fixes an issue where event tickets with fixed prices were incorrectly showing a struck-through original price, making them appear as discounts. The change ensures that fixed price rules are displayed accurately, aligning with how discounts are shown in the eCommerce shop. This improves the user experience and prevents confusion regarding pricing.

Original PR description

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.…

Event tickets show a struck-through original price even when a "Fixed Price" pricelist rule is applied, making it incorrectly appear as a discount. This is inconsistent with eCommerce shop behavior.

### Steps to reproduce

1. Create an event with a paid ticket (e.g., 100 EUR).
2. Create a pricelist with a "Fixed Price" rule for that ticket (e.g., 80 EUR).
3. Open the event registration page.
4. The 100 EUR appears struck-through next to 80 EUR.

### Cause

Odoo's website only shows a struck-through original price for discount rules, not fixed price rules. By design, a fixed price replaces the original rather than reducing it. However, the event registration page used a simplified check: it compared the final price to the original and assumed any difference was a discount. This ignored the rule type, incorrectly flagging fixed price rules as discounts.

### Fix Rationale

A new helper method on the event ticket model now queries the applied pricelist rule to determine if it qualifies as a discount.

opw-5993477

Forward-Port-Of: odoo/odoo#264240
Forward-Port-Of: odoo/odoo#263586

#pricing#event tickets#fixed price

[16.0][FIX] product_margin: sale_avg_price tax excluded

PR #264155

Coresaas-19.1product_margin

This update fixes an issue where the sale average price calculation was inaccurate due to handling tax inclusion/exclusion. Now, the sale average price uses the net price (price_subtotal) from the invoice line, ensuring accurate calculations regardless of whether taxes are included or excluded. This improves the reliability of sales reporting.

Original PR description

The price_unit of a account.move.line can be with or without tax. The sale_avg_price should be either incl. or excl. tax.  
To ensure the avg price is always excl. tax the price_subtotal can be used.

Forward-Port-Of: odoo/odoo#263671
Forward-Port-Of: odoo/odoo#199209

#accounting#sales#tax

[FIX] spreadsheet: update o_spreadsheet to latest version

PR #264647

Coresaas-19.1spreadsheet

This pull request updates the core spreadsheet component used in Odoo. It includes several bug fixes and improvements to the underlying infrastructure, ensuring a more stable and reliable spreadsheet experience for users. The changes also optimize the component's performance and dependency management.

Original PR description

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/b6a68b89c1 [REL] 19.1.20 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9087d404c4 [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/6255eb07a6 [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/aea4a8c55f [REL] 19.1.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/addcd227d8 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5e333513e4 [FIX] package: update package-lock [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/dedcb6a12c [FIX] package: package install is broken [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/a8493394cc [REL] 19.1.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e267f5db92 [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/1d4311e3d2 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dfff07841c [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/2e87404919 [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] im_livechat: non-deterministic lfh duration test

PR #264666

Coresaas-19.1im_livechat

A recent test for live chat duration was unreliable due to a race condition in how the system handles agent state transitions. This fix addresses this issue by splitting the test to avoid the problematic rapid state changes, ensuring the test is consistently reliable. This improves the overall stability of the live chat feature.

Original PR description

The `show looking for help duration in the sidebar` test has been flaky since [1]. The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately…

The `show looking for help duration in the sidebar` test has been flaky since [1].

The root cause is that the agent joins at the final step, resetting the state to in_progress, then immediately switches it back to `looking_for_help`.

 This creates several race conditions:
- Bus notifications from `join_livechat_need_help`, new message events, and any other notification carrying stale state data.
- Channel state fetched after the user joins via `/mail/data`.

The mock server makes these races hard to guard against: notifications arrive one by one, and there's no UI signal that guarantees all stale data has been processed.

This commit splits the test to preserve coverage while avoiding the problematic rapid state transition.

runbot-242278

[1]: https://github.com/odoo/odoo/pull/252738

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

#live chat#test stability

[FIX] pos_stripe: allow cancellation on terminal

PR #264665

Coresaas-19.1pos_stripeMEDIUM

This update now allows users to cancel Stripe payments directly from the payment terminal, both on the standard POS interface and the self-order kiosk. Previously, cancellations could only be made through the POS interface, creating a frustrating experience for customers. This change improves payment processing and customer satisfaction.

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#kiosk

[FIX] website_sale: fix confirmation message styling in Treehouse theme

PR #263857

Coresaas-19.1website_sale

This update fixes an issue where the payment confirmation message appeared incorrectly in the Treehouse theme. The message was compressed and misaligned, impacting the user experience. This change ensures consistent and proper display of the confirmation message across all themes, improving the checkout process.

Original PR description

Steps to reproduce:
1) Select the Treehouse theme from the website editor 
2) Add a product to the cart and proceed to payment 
3) Complete the payment and reach the confirmation page

Issue:
- The payment success alert message is not displayed properly and appears slightly below the alignment.
- Also this particular issue is coming in this Treehouse theme only in rest of the themes the alert message is coming correctly.

opw-5976602

Forward-Port-Of: odoo/odoo#257768

#website#checkout#theme#appearance

[FIX] html_editor: apply color to list marker with trailing empty line

PR #264586

Coresaas-19.1html_editor

This update fixes issues where list markers weren't consistently applying text and font sizes, particularly when list items had trailing empty lines or complex formatting. The changes ensure that font sizes and colors are correctly applied to list items regardless of their content or formatting, improving the overall user experience.

Original PR description

### Steps to reproduce: **Issue 1:** - Create a list with multiple items and leave the last item empty. - Press Ctrl + A to select all content. - Apply a text color from the toolbar. - The list…

### Steps to reproduce:

**Issue 1:**
- Create a list with multiple items and leave the last item empty.
- Press Ctrl + A to select all content.
- Apply a text color from the toolbar.
- The list marker of the last item does not receive the color.

**Issue 2:**
- Create a list and type some text.
- Press Ctrl+A to select all.
- Apply a font size via the font-size input (inline style=`font-size: ...`).
- Then apply a font size via the font-size dropdown (class-based).
- Font size from the dropdown is not applied.

**Issue 3:**
- Create a list item and type some text.
- Convert the text into a link.
- Copy the link.
- Press Enter and paste the link.
- Select the entire list using the mouse.
- Apply font size & observe that font size is not applied to some list items.

**Issue 4:**
- Go to Todo and create a list.
- Select all items (Ctrl + A).
- Apply a background color class from the toolbar.
- Apply a font color using inline styling.
- Observe that the font color is not visible.

### Description of the issue/feature this PR addresses:

- Full-selection detection relied on Range.isPointInRange() checks on list item leaf nodes. When a list item ended with a trailing empty line, the selection often stopped on the `<li>` element and did not include the `<br>` placeholder. As a result, such list items were not considered fully selected when applying text color, and their markers remained unstyled.
- Applying a font-size class on a fully-selected list item could leave existing inline font-size on list item, so new class didn’t take effect.
- Creating links inside list items & repeated copy-paste operations left empty text nodes (feff cleanup). Manual selection doesn't include these nodes, `areNodeContentsFullySelected` reports that list item is not fully selected. As a result, some list items were not considered fully selected, and font size was not applied.
- Background color `(bg-*)` classes also define a color property. When a font color is applied, the color is set on the `<li>`, but the nested `font.bg-*` element’s color takes precedence, causing the applied font color to be overridden.

### Desired behavior after PR is merged:

- List items with trailing empty line are now treated as fully selected, even when selection ends before the `<br>` placeholder.
- Clear any existing font-size styles on the list item before applying the new font-size class, so the dropdown font size applies correctly.
- Empty text nodes are removed before applying font size, ensuring full list item selection and consistent font-size application.
- When a list item (li) has a text color (inline style or text-* class), and nested font element has only a background color class then font element now inherits the color from the li.

task - 5454639

Forward-Port-Of: odoo/odoo#264381
Forward-Port-Of: odoo/odoo#241827

#formatting#list#styling

[FIX] documents: fix access error linking to composer

PR #117317

Enterprisesaas-19.1documents

This update resolves a problem where users couldn't link invoices to the chatter feature in Odoo Enterprise. The fix prevents an access error that occurred when copying attachments, ensuring users with appropriate permissions can now successfully link documents to the composer.

Original PR description

**Steps to reproduce:** 1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator. 2. Create a SO, create invoice, confirm, and send. 3. Now…

**Steps to reproduce:**
1. Create user with role: User. Sales: Administrator, Accounting: Administrator and Documents: System Administrator.
2. Create a SO, create invoice, confirm, and send.
3. Now go back to the SO, and try to link the INV document to the chatter.

**Cause:**
When linking an existing document to the composer, the underlying attachment is copied. If the source attachment is bound to a specific field (e.g., `res_field = 'invoice_pdf_report_file'`), the `copy()` operation duplicates this field reference. Odoo's native security checks then attempt to verify access to that specific field on the target model (`mail.compose.message`). Because the composer does not have this field, the check fails and throws an AccessError, even if the user has full rights to the source document.

**Solution:**
Explicitly set `"res_field": False` during the copy operation. This strips the original field binding, cleanly converting the file into a standard, generic chatter attachment for the composer without bypassing the standard security framework.

opw-5916364

Forward-Port-Of: odoo/enterprise#107723

#attachments#chatter#invoice

[FIX] sale_subscription: raise warning when import changes recurrence

PR #117318

Enterprisesaas-19.1sale_subscriptionMEDIUM

This update corrects a bug where importing a product with a changed subscription type could bypass a necessary warning. Previously, the system processed the import without alerting the user, leading to incorrect subscription settings. Now, a warning is raised to prevent accidental changes to sold subscription products.

Original PR description

__ ## Short functional explanation of the error When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription…

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117111
Forward-Port-Of: odoo/enterprise#115046

#subscriptions#import#product settings

[FIX] point_of_sale: reflection of backend cancelled order

PR #240725

Coresaas-19.1point_of_saleMEDIUM

This update fixes an issue where cancelled orders placed from the backend weren't immediately visible in the Point of Sale (POS) frontend. The system now automatically updates the POS interface when a backend order is cancelled, ensuring consistent order management across all channels. This improves accuracy and reduces the risk of discrepancies.

Original PR description

Step:
---------
- Install point_of_sale.
- Open a POS session with presets configured.
- Add an order line and select the takeout order preset.
- Cancel the order from the backend.

Issue:
---------
- The cancelled order is not reflected in the frontend.

Cause:
---------
- The frontend is not notified when the order is cancelled from the backend.

Fix:
---------
- Notify the frontend when a backend order is cancelled.

Task-5406984

#pos#order management#frontend

[PERF] account: avoid `action_undo_reconciliation` when nothing to do

PR #264714

Coresaas-19.1account

This update streamlines the reconciliation process in the accounting module by preventing unnecessary checks. Previously, the system performed redundant queries even when no reconciliation actions were needed. This change improves performance and reduces the time it takes for reconciliation operations to complete.

Original PR description

Since `write` is often done record by record because the values written are different on all lines, the call to `action_undo_reconciliation` is actually not batched. Even if there is nothing to do, some queries are still done to make sure that there is nothing to do...

Forward-Port-Of: odoo/odoo#264476

#performance#account#reconciliation

[FIX] web_enterprise: prevent error on user creation

PR #117447

Enterprisesaas-19.1web_enterprise

This update fixes an error that prevented users from being created correctly when Studio and Livechat were installed and the user form layout was modified. The issue stemmed from incorrect handling of color scheme settings during user creation, which has now been resolved to ensure consistent user setup.

Original PR description

Steps to reproduce:
1. Install Studio and Livechat
2. In user's form view change the location of Theme field after the livechat fields.
3. Now, try to create a user from name and email only

Issue:
- It throws an error:
The operation cannot be completed: Missing required value for the field 'Color Scheme' (color_scheme).

Cause:
- During user creation after studio modification, im_livechat inverse methods access res.users.settings before it is fully initialized. then later write a falsy `color_scheme` value to that settings record, violating
  the required constraint on res.users.settings.color_scheme.

Solution:
- Ensure that when creating or updating `res.users.settings`, if `color_scheme` is empty or false,
  It is automatically set to the default value "system"


opw-5918538

Forward-Port-Of: odoo/enterprise#109062

#user creation#studio#livechat

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

PR #264745

Coresaas-19.1html_editor

This update resolves an issue where the Microsoft SwiftKey keyboard caused incorrect table cell selections and unexpected focus movement. By caching the selection state, the HTML editor now accurately reflects user input, ensuring a smoother and more reliable editing experience.

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#264618
Forward-Port-Of: odoo/odoo#259798

#html_editor#keyboard#selection