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

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/enterprise#117011

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

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

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

The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice

Steps to reproduce:
1. Install account_intrastat module
2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan
3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom
4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test"
5. Click on the three dots at the end of the section line and click on Hide Prices
6. Confirm the invoice and print it
7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes)

Issue:
When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section

Solution:
Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines`

opw-6147929

Forward-Port-Of: odoo/odoo#264118
Forward-Port-Of: odoo/odoo#263499

The content of an invoice's section lines is not aligned with the columns when the prices of the section are hidden and the country of origin is displayed in the invoice

Steps to reproduce:
1. Install account_intrastat module
2. Go to Invoicing > Customers > Products and create a new product with name "test" and in the Accounting tab, set the Country of Origin to Afghanistan
3. Go to Invoicing > Customers > Customers and change Acme Corporation's country to United Kingdom
4. Go to Invoicing > Customers > Invoices and create a new invoice for partner Acme Corporation, add a section line and in that section, add product "test"
5. Click on the three dots at the end of the section line and click on Hide Prices
6. Confirm the invoice and print it
7. The content of the section line in the invoice pdf are not aligned (the tax is in column Unit Price and the amount is in column Taxes)

Issue:
When a section is hidden, no column is added in the section to display the origin, resulting in a misalignment of the tax and the amount of the section

Solution:
Add a column for the origin country in hidden section lines and add the origin country in product lines of `_get_child_lines`

opw-6147929

Forward-Port-Of: odoo/enterprise#117092
Forward-Port-Of: odoo/enterprise#115442

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/fece642d7c [REL] 19.2.13 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/5117146ce2 [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/0f6ba0d72e [IMP] packages: rolldown is released in 1.0.0 [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5282e3c377 [REL] 19.2.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/dfb655d7b9 [FIX] packages: update odoo dependencies [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/5231677171 [FIX] package: package install is broken [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>

## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.

## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
    - Wage: $0
    - (Set the contract's status to *Running*)
    - (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
    - Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**

## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:

> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*

## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).



opw-5999856

Forward-Port-Of: odoo/enterprise#116831
Forward-Port-Of: odoo/enterprise#112724

**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

__

## Short functional explanation of the error
When we create 2 shifts for the same day for an employee, on a non-working day for their schedule. When trying to create the second one after setting the end date to midnight, we get the error:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Reproduction Steps
1. Create an Employee. In the Payroll tab, Make sure they have an active contract. Set their Working Hours to a fixed schedule, where they have saturdays as non-working days. In the Settings tab, set an Overtime Ruleset.
2. Click on the overtime ruleset. Then, for each rule, under Action, set the Work Entry Type To Use as Overtime Hours.
3. Go to Attendances. In Configuration > Settings, under Extra Hours, set the Extra Hours Validation as Approved By Manager.
4. Create an attendance for your Employee on a Saturday, from 12h to 18h.
5. Create a second attendance for your Employee on that same Saturday, from 18h to 00h00. Try to Save.
Note: the timezone of your computer, the working schedule and the employee should be set at Brussels time. 

### Expected behavior
The Overtime is registered.

### Unexpected behavior
An error occurs:
`ValueError: Expected singleton: hr.attendance.overtime.line(2, 3)`

## Origin of the issue
The end time of the overtime is defined as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L54-L56 However, in the case where our shift ends after the computed end of the day (in our case, the end time of the shift is 00:00:00 and the end of the day is set at 23:59:59), it creates some problems. The end time of the overtime is set 1 second too early. Later we compute the start time of the overtime as follows: https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L57 Thus, the time start of the overtime is also set one second too early. As our second shift starts right after the first one, after the execution of this code, we will get a second shift that starts before the end of the first one.
Then, we add these values in a list:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L59 which will contain overlapping timeframes, and with which we create an Interval:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L60 But when we create an Interval with overlapping timeframes, we obtain only one interval as the timeframes are merged.
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L173 As a result, `overtime_intervals` will contain only one time frame with 2 different corresponding overtimes, which causes a singleton error when reaching:
https://github.com/odoo/enterprise/blob/47faff7d6c9da5572e3bad3ff5a55b40c2ba81ac/hr_work_entry_attendance/models/hr_version.py#L179 __
opw-6096454

Forward-Port-Of: odoo/enterprise#117094
Forward-Port-Of: odoo/enterprise#114147

**Steps to reproduce:**
* Install the *Accounting* module with French localization (*l10n_fr_account*).
* Create a *Sales Tax* with:
  * A new tax group (e.g., 'Codifab').
  * Enable *Affect Base of Subsequent Taxes*.
* Create a *Sales Order*:
  * Add the first tax (with *Affect Base of Subsequent Taxes*).
  * Then add the second tax (eg VAT tax).
* Confirm the *Sales Order*.
* Create a *Down Payment Invoice* (percentage-based).
* Open the generated invoice and:
  * Remove the first tax (the one affecting the base).

**Observed behavior:**
* The amount of the second tax group does not update after removing the first tax, leading to incorrect tax computation.

**Cause:**
* In `_import_base_line_extra_tax_data`, the condition: `all(str(tax.id) in extra_tax_data['manual_tax_amounts'] for tax in sorted_taxes)` only ensured partial matching of taxes.
* This allowed reuse of stale `manual_tax_amounts` when taxes were removed or modified, causing incorrect base values for dependent taxes (e.g., *Affect Base of Subsequent Taxes*).

**Fix:**
* Update the condition to enforce an exact match between current taxes and cached `manual_tax_amounts` by checking both size and membership.
* Prevent reuse of outdated tax data when taxes change, ensuring proper recomputation of dependent taxes.
* Align Python logic with the JS implementation for consistency between `account_tax.py` and `account_tax.js`.

opw-6063970

Forward-Port-Of: odoo/odoo#264434
Forward-Port-Of: odoo/odoo#259566

__
## Short functional explanation of the error
When we set the departure of an employee. The version is retrieved using the dismissal date. However, employees can work after their dismissal date, until their departure (in the case of a notice, for example). Therefore, the departure date should be chosen instead.

## Reproduction Steps
1. Go to Employees and create a new employee. In the Payroll tab, set a start date for their contract. Hit save.
2. This will create a version. You can see it top right, with the contract date. Click on the '+' next to it and set a date later.
3. Click on the cog in the top left and click End of Collaboration. Set an End Reason. Set the Dismissal Date to occur during the first version and the Departure Date to occur during the second version. Then, click Schedule.

### Expected behavior
The Departure tab should appear when clicking on the second version, top right.

### Unexpected behavior
The departure tab appears on the first version.

## Origin of the issue
To select the version on which the departure occurs, we use this line of code:
https://github.com/odoo/odoo/blob/be8b1bbad757fda27df579ce36cbc97324f58f62/addons/hr/models/hr_employee_departure.py#L117 `departure_date` should be used instead.

__
opw-6079675

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#264470
Forward-Port-Of: odoo/odoo#263586

**Description of the issue this PR addresses:**
Previously, when a livechat conversation ended, it was never automatically 
marked as read. The existing `mark_as_read` mechanism depends on the 
composer being focused, but ended livechat conversations hides the composer, 
and the chat window does not focus the thread automatically 
(focus only happens on explicit click).

This made it impossible for the read state to be triggered through the normal 
path, leaving agents with persistent unread indicators on closed livechat 
conversations.

**Desired behavior after PR is merged:**
- Focus the composer when present.
- Focus the conversation otherwise.

This ensures the read state is correctly triggered when the conversation
is effectively in focus.

task-[5900038](https://www.odoo.com/odoo/project/1519/tasks/5900038)

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

Forward-Port-Of: odoo/odoo#263355
Forward-Port-Of: odoo/odoo#253609