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

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

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

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

# 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