When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually.

This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks.

Steps to reproduce:
1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user
2. As a user without that approval right, post a vendor bill and register a payment
3. Add the payment to a batch payment
4. Reconcile a bank statement line with the batch payment
5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line)
   - Expected: the bill stays Posted.
   - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook.

opw-6121448

Forward-Port-Of: odoo/enterprise#115579
Forward-Port-Of: odoo/enterprise#115241

This commit aims to make the invoice line tax drop-down cleaner and more
straightforward.
The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes
and `0% Not Subject to VAT` is visible with the other `0%` taxes such as
`0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT`
instead of the actual `0%` taxes according to the characteristics of the supply;
leading to non-compliance with the ZATCA rules.

Before this commit:
- `15% PH PE HS` tax was `active`.
- `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and
  distribution for refunds: `base tax grid = 3(B)`.
- `0% Not Subject to VAT` tax was `active` and had distribution for invoice:
  `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)`
- `0% IT G and 0% QT` taxes were `active`.

After this commit:
- `15% PH PE HS` tax is `inactive`.
- `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)`
  and distribution for refunds: `base tax grid = 2(B)`
- `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid
  has been removed.
- `0% IT G and 0% QT` taxes have been set to `inactive`.

task-5959979

Forward-Port-Of: odoo/odoo#253598

There is an issue with the POS since 19.3, when a tour is running, the tour service would get the tour name from the backend with 0 steps, and because the JS bundle of the tours is not loaded by the POS frontend the tour would continue with 0 steps.

Most of the time the currentActionIndex would be > 0, so the check on line 87 of `tour_interactive.js` would pass
```
if (this.currentActionIndex === this.actions.length)
```
and later run into a
```
TypeError: Cannot read properties of undefined (reading 'step')
      at TourInteractive.play (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:121705:33) (/web_tour/static/src/js/tour_interactive/tour_interactive.js:95)
      at TourInteractive.start (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:121655:14) (/web_tour/static/src/js/tour_interactive/tour_interactive.js:45)
      at TourService.resumeTour (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:123226:39) (/web_tour/static/src/js/tour_service.js:260)
```

I'm not sure what's the correct fix,
- either what I did here
- change the condition on the `play()` to `this.currentActionIndex >= this.actions.length` instead of `this.currentActionIndex === this.actions.length`
- bundle the tours inside the POS front end (although they are not used there so it seems unnecessary)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**

## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:

https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203

It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.

The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.

opw-6089990

Forward-Port-Of: odoo/enterprise#115659
Forward-Port-Of: odoo/enterprise#114895

When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body directly to the composer.

This caused two issues:
- CTRL+A would select the `(edited)` label, allowing it to be styled, repositioned, or accidentally deleted.
- CTRL+A + Backspace + retype left the body empty after saving, because the self-closing `<span class="o-mail-Message-edited"/>` in the stored HTML was parsed by browsers as an open tag (spans are not void elements), swallowing subsequent content as its children.

Fix: strip `.o-mail-Message-edited` from the body before loading it into the editor. The server always re-appends a fresh `(edited)` span at the end when saving, so removing it from the editor content is safe and correct.

Also align the mock server with the real server behavior:
- Place the span *inside* the last `div`/`p` element instead of after it.

Rename `getNonEditableMentions` → `prepareBodyForEditing` to reflect that the function now covers both making mentions non-editable and stripping the edited label.

task-6172161



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

Forward-Port-Of: odoo/odoo#261772

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

Steps to reproduce:
-------------------
1. Install account_winbooks_import, and switch to a Belgian company
2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"
3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable")
4. Confirm the import

The import fails with:
"You must select a receivable account for 'Tax Receivable Account'."

Why the issue
-------------
In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade".

This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after.

However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import.

Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again.

The fix
-------
Add back the same bypass originally introduced in 20804db6d87.

opw-6092464

This commit aims to make the invoice line tax drop-down cleaner and more
straightforward.
The tax `15% PH PE HS` is already handled through the `0% PE` and `0% PH` taxes
and `0% Not Subject to VAT` is visible with the other `0%` taxes such as
`0% EX G`, etc. The users were incorrectly selecting the `0% Not Subject to VAT`
instead of the actual `0%` taxes according to the characteristics of the supply;
leading to non-compliance with the ZATCA rules.

Before this commit:
- `15% PH PE HS` tax was `active`.
- `0% PE & 0% PH` had distribution for invoices: `base tax grid = 3(B)` and
  distribution for refunds: `base tax grid = 3(B)`.
- `0% Not Subject to VAT` tax was `active` and had distribution for invoice:
  `base tax grid = 3(B)` and distribution for refunds: `base tax grid 3(B)`
- `0% IT G and 0% QT` taxes were `active`.

After this commit:
- `15% PH PE HS` tax is `inactive`.
- `0% PE & 0% PH` taxes have distribution for invoices: `base tax grid = 2(B)`
  and distribution for refunds: `base tax grid = 2(B)`
- `0% Not Subject to VAT` tax is set to `inactive`, `sequence = 17` and tax grid
  has been removed.
- `0% IT G and 0% QT` taxes have been set to `inactive`.

task-5959979

Forward-Port-Of: odoo/odoo#253598

Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back).

Steps to reproduce:
-------------------
* Open PoS with global discount and a gift card / eWallet program.
* Add a product (e.g. $100), apply a global discount (e.g. 10%).
* Apply a gift card for part of the balance (e.g. $50).

> Observation:
Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line.

Why the fix:
------------

`pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct.

opw-6104090

Forward-Port-Of: odoo/odoo#259577

Steps to reproduce:
------------------------
1. Install the Helpdesk.
2. Go to Settings → Technical → Sequences and set the next number to 100.
3. Create a ticket and send a message using the "Helpdesk: Ticket Received"
mail template; Observe that the correct reference (100) is used.
(Open the full composer to use "Load template")
4. Now send a message using the "Helpdesk: Ticket Closed" mail template
and Observe that it displays the database ID (e.g., 1) instead of the reference.


Cause:
------
`new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly.
https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19

However, the `solved_ticket_request_email_template` uses the database ID (`object.id`)
instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references
in customer communications.

related commit: 3ed5273

Solution:
---------
Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id`

opw-6087466

Forward-Port-Of: odoo/enterprise#114852
Forward-Port-Of: odoo/enterprise#113932

Steps to reproduce:
------------------------
1. Install the Helpdesk.
2. Go to Settings → Technical → Sequences and set the next number to 100.
3. Create a ticket and send a message using the "Helpdesk: Ticket Received"
mail template; Observe that the correct reference (100) is used.
(Open the full composer to use "Load template")
4. Now send a message using the "Helpdesk: Ticket Closed" mail template
and Observe that it displays the database ID (e.g., 1) instead of the reference.


Cause:
------
`new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly.
https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19

However, the `solved_ticket_request_email_template` uses the database ID (`object.id`)
instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references
in customer communications.

related commit: 3ed5273

Solution:
---------
Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id`

opw-6087466

Forward-Port-Of: odoo/enterprise#114852
Forward-Port-Of: odoo/enterprise#113932

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#115435
Forward-Port-Of: odoo/enterprise#112879

Steps to reproduce:
------------------------
1. Install the Helpdesk.
2. Go to Settings → Technical → Sequences and set the next number to 100.
3. Create a ticket and send a message using the "Helpdesk: Ticket Received"
mail template; Observe that the correct reference (100) is used.
(Open the full composer to use "Load template")
4. Now send a message using the "Helpdesk: Ticket Closed" mail template
and Observe that it displays the database ID (e.g., 1) instead of the reference.


Cause:
------
`new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly.
https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19

However, the `solved_ticket_request_email_template` uses the database ID (`object.id`)
instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references
in customer communications.

related commit: 3ed5273

Solution:
---------
Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id`

opw-6087466

Forward-Port-Of: odoo/enterprise#114852
Forward-Port-Of: odoo/enterprise#113932

When we import bills from KSeF, the vendor (`Podmiot1`) XML tag must include a Polish `NIP` number XML tag.
The `NIP` is the base number composing a polish `vat` number, but without the prefix `PL`.
This is true even if the vendor is from another country like Luxembourg: if they have a stable organization in Poland and sells in Poland - then they have to use a polish `NIP` to use the KSeF and issue their invoices.

Two issues:
- We search the vendor by `NIP` as it was a `vat` number, but we add the `vendor_country` code as prefix instead of `PL`. I.e. we search for `LU012345678` instead of `PL012345678`.
- When we don't find the vendor in the database, we create one using the `NIP` number coming straight from the tag, as it was a `vat` number. I.e. for a partner in Luxembourg, `vat` will become `LU012345678` instead of `PL012345678`

ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf

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

Forward-Port-Of: odoo/odoo#261964

Steps to reproduce
1. Install l10n_ar (or any LATAM localization).
2. Go to Accounting > Configuration > Journals and open a Purchase journal
   that has "Use Documents?" enabled.
3. Enable "Secure Posted Entries with Hash".
4. Create and post a vendor bill with a high document number (e.g. 00001-00009999).
5. Create another vendor bill with a lower document number (e.g. 00001-00000100)
   and try to post it.

Issue
Posting the second vendor bill fails with:
"This move could not be locked either because some move with the same sequence
prefix has a higher number. You may need to resequence it."

The hashing logic in account_journal.py enforces a strict continuous sequential
chain per journal:
https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678

In LATAM countries, vendor bill document numbers are assigned by the vendor, not
by Odoo. A bill with a lower number can legitimately be entered after one with a
higher number, which breaks the sequential assumption the hash chain relies on.
Allowing it would produce a hash that no longer represents a proper chain, giving
users a false sense of security. Sales journals are unaffected because Odoo
controls their sequence.

Solution
Hide the "Secure Posted Entries with Hash" field on purchase journals that have
"Use Documents?" enabled, preventing users from enabling an option that cannot
work correctly for vendor-assigned document numbers. Sales journals keep the
option available since Odoo controls their sequence.

opw-6076673

Forward-Port-Of: odoo/odoo#259206

**Steps to reproduce:**
- create a storable product avco auto 
- make sure that a purchase tax is set in 'General Information'
- create and confirm a PO for 30 quantities with a price of 0
- receive the products
- create and validate a delivery for 10 units of the product
- from the PO create the bill 
- set a date and save
- set a price of 100
- on the Bill set the total tax at 500 (it's bellow 'untaxed amount' 
on the bottom right of the bill and should be 450 before you 
change it, if the tax is 15%)
- confirm the bill

**Current behavior:**
The total tax was reset to 450

**Expected behavior:**
It should stay 500 as it was manually set

**Cause of the issue:**
The total tax amount is computed based on the tax lines 
in Journal Items
https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171
So the problem is actually that a recomputation of the balance
of the tax account.move.line (the one with the account "tax paid" in 
journal items) is triggered when we confirm the Bill.

That's because :
When we confirm the bill, because the price is different than 
the one on the PO, _apply_price_difference does 2 things : 
(1) it creates an svl (with corresponding amls) for the quantities
that are still in stock (here 20)
(2) it adds amls on the bill (crediting stock interim received and 
debiting expense) to compensate the cogs deficit for the already 
out of stock quantities (here 10).
cf https://github.com/odoo/odoo/pull/126536 for more details

When we create those amls from (2),  the create method 
from account.move.lines calls super() inside a context manager 
calling _sync_dynamic_lines().
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635
the yield of sync_dynamic_lines() is inside a context manager
calling _sync_tax_lines.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250
Therefore, the first half of sync_tax_lines() (untill the yield) is ran 
before the call to super and the rest (from the yield) is ran 
after the call to super. 
Because we added two lines in the account.move, get_changed_lines
will return those 2 new line and because there is a tax_ids on the new lines
round_from_tax will be False.
https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041
Therefore we won't reach continue.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059
And the tax line will be recomputed using 
_prepare_tax_line()
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065

Here is why there is a tax_ids on the new lines : 
The field is precompute so if we don't set a value for 
it, _compute_tax_ids will be ran to compute it.
As the account move on which the lines are added 
is a bill, the tax_ids will the supplier_tax_id of the product.
https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901

**Fix:**
There is no need for a tax_ids on these lines as they 
are not meant to (and should'nt) impact the taxes.

opw-5413798

Forward-Port-Of: odoo/odoo#261559

# Setup
Have 2 companies : A & B

# How to reproduce
- Set your website's company to Company B
- Create product X :
	- Company : Company A
	- Published
	- Name : xyz
- Go to Users > Any User > Acces Rights > Allowed Companies => leave only Company A
- Connect as that user on the website
- Go to the Shop tab and search xyz

# The problem
The product X is displayed, even though we currently use the company B's website and the product is limited to company A. 
This causes problem later when Sales Order are created using that product.

If you set the Allowed Companies of the user to both Company A and Company B, then the product is correctly hidden

# Why
When you search something in the search bar, the server does a `_search_with_fuzzy()` that ends up calling a simple `model.search()`.
In our case, this search should not return product X because there is an `ir.rule` that hides product not in the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/product/security/product_security.xml#L34-L38

But the `website` module has some particular rule about setting the current company :
https://github.com/odoo/odoo/blob/0bb5ac6c1a87367c1ebb343ad6e6e6e56188cf13/addons/website/models/ir_http.py#L249-L261

So, in our case, since the user does not have company B in its allowed companies, then
`allowed_company_ids` = Company A. So `('company_id', 'parent_of', company_ids)` is trucy and the product is displayed

# Proposed solution
Doing the search with `with_company` raise an AccessError because the company is not present in the allowed_companies. Chaging the allowed companies logic seems risky because it
may lead to unintended side effects.

We instead enforce the website's company in the search's domain

opw-6115647

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

Forward-Port-Of: odoo/odoo#260138

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359

Forward-Port-Of: odoo/enterprise#114473

When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually.

This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks.

Steps to reproduce:
1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user
2. As a user without that approval right, post a vendor bill and register a payment
3. Add the payment to a batch payment
4. Reconcile a bank statement line with the batch payment
5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line)
   - Expected: the bill stays Posted.
   - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook.

opw-6121448

Forward-Port-Of: odoo/enterprise#115579
Forward-Port-Of: odoo/enterprise#115241

[FIX] documents: scroll to uploaded record

How to reproduce:
- install documents
- open the "All" folder and ensure there is enough folder to not see any file
- open the detail panel
- drag&drop file in that folder
The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel.

We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel.

[FIX] documents: fix icon position in thumbnail

How to reproduce:
- install documents
- open the chatter of a document
- click on log a note, and upload a file
The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border).

We fix here the position the icon/button.

[FIX] documents: fix "you" badge layout

How to reproduce:
- install documents
- change the name of Mitchell Admin to a very long name
- open the share panel owned by Mitchell Admin
The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct).

We fix here the layout of the badge in such configuration.

Task-5152517

Forward-Port-Of: odoo/enterprise#115621
Forward-Port-Of: odoo/enterprise#107686

**Problem:**
Adding a video (or image) via Extra Media on a product page in the website builder crashes with:
"TypeError: loadPromiseResolveFunction is not a function"

**Steps to reproduce:**
1. Install ai_website_sale
2. Go to a product page and enter edit mode
3. In the right panel → Images → click "Add More" (Extra Media)
4. Switch to Videos tab → paste a YouTube URL → click Add
5. Observe the crash

**Current behavior:**
A traceback dialog appears: "loadPromiseResolveFunction is not a function"

**Expected behavior:**
The video is saved as extra media on the product.

**Cause of the issue:**
The `ai_website_sale` patch for `ProductAddExtraImageAction.getMediaDialogProps` destructures the argument with key `loadResolveFunction` (renamed to `loadPromiseResolveFunction` locally), but the caller in `load()` passes `loadPromiseResolveFunction` as the key. The key mismatch means the local variable is always `undefined`, and the `save` closure in the parent's `getMediaDialogProps` closes over `undefined` instead of the Promise's `resolve` function. Calling `undefined()` throws the TypeError.

**Fix:**
Aligning the parameter key with the parent API ensures the Promise's `resolve` function is correctly captured in the `save` closure.

opw-6107097

## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**

## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:

https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203

It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.

The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.

opw-6089990

Forward-Port-Of: odoo/enterprise#115659
Forward-Port-Of: odoo/enterprise#114895

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

Steps to reproduce:
------------------------
1. Install the Helpdesk.
2. Go to Settings → Technical → Sequences and set the next number to 100.
3. Create a ticket and send a message using the "Helpdesk: Ticket Received"
mail template; Observe that the correct reference (100) is used.
(Open the full composer to use "Load template")
4. Now send a message using the "Helpdesk: Ticket Closed" mail template
and Observe that it displays the database ID (e.g., 1) instead of the reference.


Cause:
------
`new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly.
https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19

However, the `solved_ticket_request_email_template` uses the database ID (`object.id`)
instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references
in customer communications.

related commit: 3ed5273

Solution:
---------
Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id`

opw-6087466

Forward-Port-Of: odoo/enterprise#114852
Forward-Port-Of: odoo/enterprise#113932

## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**

## Cause
The condition to raise the error message does not take into account the state of the leave:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204

This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.

(related to)
opw-6089990

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359

Forward-Port-Of: odoo/enterprise#114473