Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1".

In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed.

Solution: we should never have considered anything else than left-button actions anyways.

[1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb
[2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185
[3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28
[4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3

task-6055182

Forward-Port-Of: odoo/enterprise#111490

Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point.

## Steps to replicate:
- Install Quality, Purchase, IoT
- Quality > Quality Control > Control points
- Create a new Control point with
   - Type: Take A Picture
   - Operations: My Company: Receipts
- Create and confirm a purchase order for a test product
- Receipts > Quality Checks > Take A picture

## Observed behavior:
TypeError: Cannot read properties of undefined (reading '0')

## Root cause:
This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined.

These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined.
[1]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 
[2]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 
[3]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 
[4]:
https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32

## Solution:
Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4]

opw-6010095

Forward-Port-Of: odoo/enterprise#110615

**Behavior:**
Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number.

The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner.

**Steps to reproduce:**
- Log to a Belgian company
- Create a contact that is a person
- Add the 281.50 tag to them
- Create a credit note for any positive amount for that person and set the date to the previous year
- Make sure the account used in the credit note has any 281.50 x tag assigned
- Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note
- When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact

opw-5930339

Forward-Port-Of: odoo/enterprise#111310

1. **Date Sync: mail.activity & sign.request**
      **Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline. This led to a discrepancy where a document might expire in 2 days, but the user's to-do list still showed a deadline from a week ago.
      
      **Expected Behavior:** The activity deadline should always reflect the current validity of the document to ensure signers are aware of the actual remaining time.
      
      **Fix:** Overrode the write method on sign.request. When the validity_date is modified, the system now automatically updates the date_deadline of all associated records in sign_activity_ids.

2. **Activity Cleanup on Cancel**
    **Before Fix:** Canceling a sign.request changed the document state but left "Signature Request" activities sitting in users' to-do lists. This resulted in "orphan" activities that pointed to canceled documents, cluttering the chatter and the activity bin.
    
    **Expected Behavior:** Canceling a request should globally clean up any pending tasks related to that specific request.
    
    **Fix:** Updated the cancel method to unlink associated activities.
  
    **Note on Conflict Prevention:** To avoid a UserError/MissingRecord when canceling directly from the activity widget (where the interface attempts to delete the activity immediately after calling the cancel method), a context flag skip_sign_activity_unlink was introduced. This ensures that if the activity is already handling its own deletion, the backend doesn't "double-delete" it.

Task: 5989542

Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed.

**Steps to Reproduce:**
 - Install `l10n_sa_hr_payroll` with demo data.
 - Switch to `Saudi Arabian` company.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`.
 - Delete all records related to the Saudi Arabian company.
 - Go to `Scheduled Actions` and run `"Payroll: Update Data"`.

`ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision`

After [this commit], the category_id field becomes non-required, allowing users to delete 
a rule category record even if it is linked to a salary rule. When updating the data file [1], 
this causes an error due to the missing rule category [2].

This commit ensures that, when updating the salary rule data, the rule category data is updated 
beforehand, as shown here [3].

[this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e

[1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165

[2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249

[3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18

sentry-7349905716

Forward-Port-Of: odoo/enterprise#111438

The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.

This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.

In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.

For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.

Task: 6043957

Forward-Port-Of: odoo/enterprise#111140

It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM.

Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply.

In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request to 512 and try again. 512 tokens were chosen completely arbitrarily - anecdotally, the model should use around 300 thinking tokens for its tasks so 512 should be enough. After 3 unsuccessful tries, we send a failure response to the user.

Task-5959805

Forward-Port-Of: odoo/enterprise#111228
Forward-Port-Of: odoo/enterprise#108755

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed.

Solution:
- In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day.
- In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors.
- In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.

opw-5931665

Forward-Port-Of: odoo/enterprise#111075
Forward-Port-Of: odoo/enterprise#109419

Step to reproduce:
- install spreadsheet_dashboard_sale and pos_sale
- create a order in pos , invoice it too
- open sale dashboard

Observation:
- the order fulfilled in pos, does not reflect in dashboard

Cause:
- sale has 4 status i.e ["draft", "sent", "sale", "cancel"]
- when pos_sale is installed, new status oders are added i.e ['paid', 'invoiced', 'done']
- sale dashboard pivot relies on sale defined status only, which so not consider orders that have status in  ['paid', 'invoiced', 'done']

Fix:
- fix the domain of pivots such that, it will now accept other orders too

**Before:**

<img width="1058" height="277" alt="image" src="https://github.com/user-attachments/assets/e58c88fa-5ad3-4194-9f9c-ddf41f2f73de" />

<img width="1116" height="190" alt="image" src="https://github.com/user-attachments/assets/259e0347-5d5b-4d5c-9aeb-74102aa4becd" />
<br/>


**After**
<br/>

<img width="1137" height="232" alt="image" src="https://github.com/user-attachments/assets/406b71a5-1dd8-4164-9d4e-4f0bca34c9e8" />

<img width="1125" height="235" alt="image" src="https://github.com/user-attachments/assets/fded3203-7d72-45ea-b5aa-142ebcd52136" />


opw-5487654

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

Forward-Port-Of: odoo/odoo#248142

BUG 1:
-----------

**Steps to reproduce:**
1. Install Time Off and Timesheets with demo data.
2. Create a time off for an employee and approve it.
3. Check the related timesheet entry for that employee.
4. Delete the approved time off.
5. Check the timesheet entries again.

**Issue:**
The timesheet entry remains even after the related time off record is deleted.

**Cause:**
Following commit 944c11e, admins can delete [approved time off ](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L956-L959)records. 
The relationship between the leave and the analytic line (timesheet) did not
have a deletion policy defined. When the leave was [unlinked](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L961-L964), the analytic
line remained without its parent reference.

**Solution:**
Explicitly remove related timesheet entries before deleting the leave record.


BUG 2:
-----------


Currently, refusing/cancelling a time off record can lead to orphan 
timesheets/duplicated hours (16h instead of 8h) if a public holiday 
exists on the same day.

**Root cause:**
The issue comes from this write method:
https://github.com/odoo/odoo/blob/79ff1d63caed2c1058aa338947b9af90ebb6cd20/addons/project_timesheet_holidays/models/hr_leave.py#L128-L130
The method first unlinks the holiday_id from the timesheets
and then attempts to delete them.

However, once the holiday_id is set to False, the timesheets are
no longer linked to the leave. As a result, leave.timesheet_ids becomes empty,
and nothing is deleted. This leads to orphan timesheet records.

When the leave is later refused or cancelled, a new public holiday timesheet
entry is generated (if applicable), resulting in duplicated timesheet entries
for the same day.

**Steps to reproduce:**
1. Create a time off for one day and validate it (8h timesheet generated).
2. Create a public holiday for the same day.
3. Observe that leave duration becomes 0, but the timesheet remains.
4. Refuse or cancel the time off.
5. Observe two timesheet entries for the same day (16h total).

opw-5384428





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

Forward-Port-Of: odoo/odoo#247155

## Issue before this commit:

Creating an invoice from a POS order with **Cash Rounding enabled only for cash payment methods** raised an unexpected validation error:

> *"The operation cannot be completed: Missing required account on accountable line."*

This happened when the order was paid using a **non-cash payment method**, but rounding logic was still applied.

## Steps to Reproduce:

1. Install the `point_of_sale` module.
2. Go to POS Configuration → Settings:

   * Enable **Cash Rounding**
   * Set a **Rounding Method**
   * Enable **Only on cash methods**
3. Create a product:

   * Sale Price: 260
   * Tax: 6%
4. Open a POS session.
5. Add the product to an order.
6. Apply a discount (e.g., 1.123).
7. Pay using a **non-cash payment method** (journal not marked as cash).
8. Enable **Invoice** and validate the order
   *(or create the invoice later from the Orders menu)*

## Cause of the Issue:

While `_prepare_invoice_vals` correctly avoids setting `invoice_cash_rounding_id` for non-cash payments, `_create_invoice` still executes rounding logic whenever cash rounding is enabled on the POS configuration.

This leads to a mismatch where:

* No rounding configuration is set on the invoice
* Rounding logic still attempts to create/update rounding lines
* Required accounts (profit/loss) cannot be determined
* A validation error is raised due to missing account on the generated line

## With This Commit:

The rounding logic in `_create_invoice` is now guarded by checking the presence of `invoice_cash_rounding_id`.

This ensures rounding is only applied when properly configured and avoids unexpected validation errors for non-cash payment invoices.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10ticlUW5i5pbu_oDDPqR-jg0hVcNWf3Z/view?usp=sharing)

opw-6005320
opw-5951991
opw-6036870

Forward-Port-Of: odoo/odoo#254844

This commit resolves a performance bottleneck that occurred when handling very
large sale orders (e.g., ~200 order lines). Previously, the util function
`getParentSectionRecord` determined the parent (sub)section of an order line by
iterating over all preceding order lines. Since this logic was executed for each
order line, the overall complexity became O(n²).

Moreover, this function was invoked inside the `shouldCollapse` method, which is
used in multiple UI flows during rendering. As a result, large sale orders could
cause noticeable UI slowdowns and block the main JavaScript thread.

To address this, we now build a parent–child section mapping once per render
in O(n) time. Subsequent lookups simply read from this mapping instead of
recomputing the parent by scanning previous lines.

This significantly reduces the computational cost and prevents UI blocking when
working with large orders, leading to a much smoother rendering experience.

opw-5865167

Benchmark:

| No. records | Before      | After        |
|----------------|---------------|--------------|
|       150      |   1300ms  |   ~850ms |


| Before      | After        |
|---------------|--------------|
|   <img width="287" height="284" alt="image" src="https://github.com/user-attachments/assets/dd73ab18-3c53-4958-99b7-083dd5cd9e64" />  |   <img width="311" height="277" alt="image" src="https://github.com/user-attachments/assets/b6e90fa3-85eb-4d72-b616-28aff9a938e8" />|
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#255180
Forward-Port-Of: odoo/odoo#252991

Before this commit, if the user configured the sales journal to be locked by a hash, then a cancellation in ticketbai would 1/ send the cancel request to ticketBAI. This would be processed successfully 2/ try to reset the invoice to draft inside of Odoo, then cancel it. This would fail with an error since account moves protected by a hash cannot be reset to draft.

The result is a blocked database where the invoice cannot be altered in Odoo while its status doesn't match the status in ticketBAI.

In this commit, we propose to check for the secure hash before sending the invoice over to ticketBAI. The invoice is not altered yet at that stage to account for potential ticketBAI errors in the normal flow.

While this option is not great from a usability perspective (preventing secure hashes with ticketBAI is probably best), we believe the current solution offers the best compromise in the context of a bugfix.

The issue does not seem to be reproducible outside of production as the core of the problem is a mismatch in state between ticketBAIand Odoo.

opw-5912848

Forward-Port-Of: odoo/odoo#250886

# How to reproduce
- Have atleast one product published on the website. The more products published, the more noticable the issue is
- Edit the website
- Add a table block to a page (Search for table in the "Insert block" popup and pick the first one)
- Add a catalog block to the table. This catalog block needs to be the one with the title "Our latest content".
- Add any other block in the table block to update the table of content

# The problem
The table of contents display the names of the different products. If there are a lot of products, it fills the whole table of content

# Why
The TableOfContentPlugin scans for ```<h2>``` tags to use them in the table of content.
```js
updateTableOfContentNavbar(tableOfContentMain) {
        const tableOfContent = tableOfContentMain.closest(".s_table_of_content");
        const tableOfContentNavbar = tableOfContent.querySelector(".s_table_of_content_navbar");
        const currentNavbarItems = [...tableOfContentNavbar.children].map((el) => ({
            title: el.textContent,
            href: el.getAttribute("href"),
        }));

        if (tableOfContentMain.children.length === 0) {
            // Remove the table of content if empty content.
            this.dependencies.remove.removeElement(tableOfContent);
            return;
        }

        const targetedElements = "h1, h2";
        const currentHeadingItems = [...tableOfContentMain.querySelectorAll(targetedElements)]
            .filter((el) => !el.closest(".o_snippet_desktop_invisible"))
            .map((el) => ({ title: el.textContent, id: `#${el.id}`, el }));
```

The product snippet template uses ```<h2>``` for their product title dispite having the h6 CSS class.

Note that the reason you need to add another block to the table to see the issue is that the table of content is updated before the products are loaded in the catalog.

opw-5992937

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

Forward-Port-Of: odoo/odoo#253002

Currently when the user creates an invoice the delivery date is set incorrectly.

<h2>Steps to produce:</h2>

* Set system timezone to Asia/Kolkata and time to 5:00
* Install Sales, Inventory
* Create and confirm a sale order
* Go to Delivery and Validate the delivery
* Go back to the Sale order and create an invoice.


<h2>Observed Behavior:</h2>
The delivery date on the customer invoice is set to one day before the current date, even though the effective date for the delivery correctly reflects the system date and time.

<h2>Root cause:</h2>

This issue occurs because, when a delivery is validated, the `date_done` field is set using the current time in UTC at [1], because odoo operates in UTC by default. This value is then used to compute the effective date on the
sales order at [2], which in turn is used to determine the delivery date on the invoice at [3] and [4].

Users see the effective date on the delivery in their own timezone because `Datetime` fields are converted from UTC to the user’s timezone on the client side as stated in [5]. However problem arises from a type mismatch. The delivery date field is of type `Date`, while the effective date is a `Datetime`. As a result, when the value is assigned at [3] or at [4], only the date portion is passed.

Because a Date field does not carry any timezone information, no timezone conversion occurs, leading to the observed discrepancy.

[1]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/stock/models/stock_picking.py#L1274
[2]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L87-L88
[3]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/account_move.py#L122
[4]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/addons/sale_stock/models/sale_order.py#L301
[5]-
https://github.com/odoo/odoo/blob/ebb2b2ef02bbffeac4d11c1acdd7e6b4dc151bf9/odoo/orm/fields_temporal.py#L214-L217

## **Solution:**
Using the `context_timestamp` function makes it possible to work with the `Datetime` in the client’s timezone, which can then be used to correctly assign the delivery date on the invoice.


opw-5391189

Forward-Port-Of: odoo/odoo#255404
Forward-Port-Of: odoo/odoo#247122

An error is raised when we try to acces the inventory valuation if a move has been returned and the quantity set on the original move is changed to 0

Steps to reproduce:
1. Install Accounting and Inventory
2. Create a product called "Product" and set the Category to "Goods"
3. Go to Inventory > Configuration > Categories, open category "Goods" and change the costing method to "Average Cost (AVCO)"
4. Go to Inventory > Operations > Deliveries and create a new delivery for any customer with one of product "Product"
5. Validate the delivery, click on "Return" then on "Return All"
6. Validate the return
7. Go back to the original delivery and in Actions, click on "Lock/Unlock"
8. Set the quantity to 0 and save
9. Go to Accounting > Review > Inventory valuation
10. Change the day to any day after today
11. An error is raised

Issue:
Trying to get the inventory valuation at another day then today will replay the history
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/stock_account/models/product.py#L444-L450
Which will call `_get_value()` on the moves related to the product
https://github.com/odoo/odoo/blob/88df50bc96448dfaff28bd37e970ffd18bf8d554/addons/stock_account/models/stock_move.py#L388-L391
A ZeroDivisionError will then be raised when trying to get the value of a return move and the original move's quantity is 0
https://github.com/odoo/odoo/blob/873d4d262ed3e85362aa677b5a782d6e7fa00f09/addons/stock_account/models/stock_move.py#L457

Solution:
If the original move's quantity is 0, set the value to 0
This ensures the move is valued at 0 if the move has no quantity. In other words, a move that has no quantity shouldn't be considered to have any value as there really is nothing to value.

opw-5980600

Forward-Port-Of: odoo/odoo#253392

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Additionally, `_get_localized_times` called `.astimezone()` on naive UTC datetimes without first localizing them, producing incorrect local times for the same reason.

Solution:
- In `_get_overtimes_to_update_domain`, localize check_in/check_out to the employee's timezone before computing the overtime search date range (with a ±1 day buffer) so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.
- Fix `_get_localized_times` to call `utc.localize()` on naive UTC datetimes before converting to the employee's timezone.

opw-5931665

Forward-Port-Of: odoo/odoo#254543
Forward-Port-Of: odoo/odoo#251812

Previously, we created a contrast-adjusted color for the `btn-outline` classes to ensure readability. This was also applied to manual colors selected via Theme tab, which made some inconsistencies with standard `btn`.

This commit fixes that by providing the contrast-adjusted color only on default palettes, and use the manual color as is when selected in the Theme tab.

task-5392258

| State | Before | After |
|--------|--------|--------|
| Normal | <img width="261" height="122" alt="image" src="https://github.com/user-attachments/assets/482ed97f-303c-4332-a748-1130a9ee5db7" /> | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/5e0b14ba-677a-480e-8aad-85c13f3a5f6e" /> | 
| Hover | <img width="261" height="124" alt="image" src="https://github.com/user-attachments/assets/87cec4fc-521c-4b36-84d3-81460cefa68c" /> | <img width="259" height="123" alt="image" src="https://github.com/user-attachments/assets/b17c309d-2b64-4dc2-a33b-e576831647e0" /> | 

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

Forward-Port-Of: odoo/odoo#239584

Purpose
=======
Fix the "This question requires an answer" alert which is displayed under the question even if it's the first time the user sees it.

Specification
=============
Following odoo/odoo#215237 conditional questions can now be displayed in the post-submit flow. The purpose was to give the user the chance to see and answer the conditional questions that are triggered by a mandatory question that was skipped.

However the condition to display this error alert was only relying on the fact that the question was considered post-submit or not. But now that the post-submit questions also includes the conditional questions that are waiting for answer, this condition is not enough anymore.

Making the condition more precise to be sure that the error is displayed only if the questions is considered post-submit AND it's already the post-submit flow or it's the pre-submit flow and the question was effectively skipped by the user.

Task-6048598


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

Forward-Port-Of: odoo/odoo#254848

### Steps to reproduce:

- Impersonate a user with only Inventory user access rights
- Inventory > Operations > Adjustments> Physical Inventory
- Select any quant in the list > Print > Count Sheet
#### > Access Error: You are not allowed to access 'System Parameter' (ir.config_parameter) records.

### Cause of the issue:

The template of the count sheet relies on the `get_param` methods of the `ir.config_parameter` model which requires read access rights on the model:
https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/addons/stock/report/report_stockinventory.xml#L36-L39 https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/models/ir_config_parameter.py#L59-L69 This access right is limited to the the `base.group_system` (admin) user group:
https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/security/ir.model.access.csv#L118

opw-5959200

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

Forward-Port-Of: odoo/odoo#254294
Forward-Port-Of: odoo/odoo#253251

# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component

*Component Product*
- Storable
- Tracked By Lot

# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"

# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned

# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.

This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.

In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
            moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
            if moves_to_update:
                moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```

This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
    def _compute_picked(self):
        for move in self:
            if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
                move.picked = True
            else:
                move.picked = False
```

If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.

opw-5937171

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

Forward-Port-Of: odoo/odoo#253607

PR #212726 removed a Many2One field and used an existing binary field, `l10n_it_edi_attachment_file`, to store E-invoice files as XMLs. This change was made for security reasons.

However, this PR also stores attachments embedded in the `<Allegati>` element of the XML in this same field. This results in three issues when importing invoices from the SDI:

1. The first embedded attachment will overwrite the XML file's contents, corrupting it.
2. Subsequent embedded attachments will continue to overwrite the previous attachment.
3. All embedded attachments are linked to the `account.move` record by the Many2one field `attachment_ids`, which is contrary to the stated goal of PR #212726.

These behaviors cannot be replicated in a runbot environment, as there is no way to test the SDI import process in runbot at the time of writing.

Localhost environments can replicate this issue by receiving an XML from the test l10n_it API server, or by passing similarly encrypted data to the method `_l10n_it_edi_process_downloads()`. See the method `test_decrypt_invoice_from_IAP()` from PR #250439 for an example of the encryption process.

**Solution**: Do not overwrite the field `l10n_it_edi_attachment_file`. Add stored field(s) to master for attachment(s) within an XML's `<<Allegati>` element.

This PR also improves how Allegati attachments are named, as my previous PR #246220 could result in files with two extensions (e.g. "filename.txt.TXT").

Ticket [link](https://www.odoo.com/odoo/project.task/5800658)
opw-5800658

Forward-Port-Of: odoo/odoo#252806