### Description of the issue/feature this PR addresses:
This PR fixes an issue in the Sign module where replacing a document breaks the link between a signer and their multiple signature fields, causing Odoo to erroneously generate separate signers for each individual field.

### Current behavior before PR:
When a document with multiple signature fields assigned to the same person is replaced, the _copy_sign_items_to function duplicates the sign.item records. During this duplication process, Odoo duplicates the old responsible_ids, creating copies with new ids. These new copies overwrite the old responsible_ids, ensuring that the newly created sign_items have entirely new responsible_ids. 
Because a shared responsible_id is the primary key Odoo uses to group multiple signature items under a single signer, this change in ID causes the system to lose the grouping. As a result, Odoo treats each copied field as belonging to a completely new, separate signer. 

_Note_:
Because of the limitation mentioned before, any responsible_id that is passed through the copy function, and thereby the copy_data function, is overwritten with new ids. The only work-around then is to update the responsible_id value attached to the new_sign_item after the copy_data function has completed and the new_sign_item has been created. 

### Desired behavior after PR is merged:
The original responsible_id is explicitly carried over and assigned to the newly copied sign.item immediately after the copy operation completes. This ensures the copied signature fields retain their original role IDs and grouping, keeping them correctly assigned to the single original signer.

opw-6354334

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

Forward-Port-Of: odoo/enterprise#123628

### Issue
When AI chat is used in views where `config.viewSwitcherEntries` is not initialized, sending a message raises a `TypeError` because the code attempts to call `.map()` on an undefined value.

### Steps to Reproduce
[Video](https://drive.google.com/file/d/1i7kWDnmv4mebGtf1to12BNHCG5omBTXl/view?usp=sharing)
1. Click the **Ask AI** button.
2. Open the AI chat.
3. Keep it open and navigate to the **Shopfloor** app.
4. Send a message in the AI chat.

### Error
```text
TypeError: Cannot read properties of undefined (reading 'map')
    at WithSearch.getCurrentViewInfo
```

### Fix
Safely handle cases where `config.viewSwitcherEntries` is undefined by using optional chaining and falling back to an empty array.

**Before**
```js
result.available_view_types = config.viewSwitcherEntries.map((v) => v.type);
```

**After**
```js
result.available_view_types =
    config.viewSwitcherEntries?.map((v) => v.type) || [];
```

opw-6414684

Forward-Port-Of: odoo/enterprise#126738
Forward-Port-Of: odoo/enterprise#125821

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Forward-Port-Of: odoo/enterprise#126776
Forward-Port-Of: odoo/enterprise#121733

**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.

**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.

**Current behavior:**
The cancellation email is rendered in the organizer's language.

**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.

**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.

**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.

opw-6323179

Forward-Port-Of: odoo/enterprise#125927
Forward-Port-Of: odoo/enterprise#124116

Steps to reproduce:-
- Open any report.
- Click on a particular line to unfold more than once very fast(or throttle network to 3G)
- Once line is unfolded click again to fold that line.
- Line is not folding.

Cause:-
- When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked).
- Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold  the same line, resulting in unfolding the same line multiple times.
- In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible.

Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times.

task-6260425

Forward-Port-Of: odoo/enterprise#126765
Forward-Port-Of: odoo/enterprise#120392

Clicking a slot on an appointment type with a non-ASCII name (for example an Arabic title) puts the browser in an endless 301 loop, so the info form never opens.

### Steps to reproduce

- Create an appointment type with an Arabic name, e.g. `عنوان`.
- Open its page and pick a time slot.
- The browser keeps redirecting on `/appointment/<slug>/info` and fails with "too many redirections".

### Cause

The info URL is built from the slug `<name>-<id>`, here `عنوان-1`. We build a `URL` with `encodeURIComponent(slug)`, so `url.href` is already encoded once (`عنوان` becomes `%D8%B9...`). But we then navigate with `encodeURI(url.href)`, and `encodeURI` escapes the `%` signs a second time, so `%D8%B9...` becomes `%25D8%25B9...`. The slug is now encoded twice.

To canonicalize the URL, the server decodes the request path and the path it rebuilds from the route, once each, and redirects if they differ. For a normal URL they are equal. For ours they are not, because one side is decoded one step less than the other, so the server keeps answering 301 with the same double-encoded URL. An ASCII slug has no `%` for `encodeURI` to escape, so only non-ASCII names hit this.

### Fix

Navigate to `url.href` directly. It is already encoded, so the extra `encodeURI` only broke it. Same fix on the manual resource confirmation path.

opw-6409641

Forward-Port-Of: odoo/enterprise#125497

Currently, an error occurs when user tries to install `website_sale_subscription` after deleting the monthly subscription plan.

Steps to replicate:
- Install `sale_subscription`.
- Open Subscription > Configuration > Recurring Plans.
- Delete the plan named `monthly`.
- Install `website_sale_subscription`.

Error:
```
ValueError: External ID not found in the system: sale_subscription.subscription_plan_month

odoo.tools.convert.ParseError: while parsing /home/odoo/odoo19/enterprise/website_sale_subscription/data/donation_data.xml:16, somewhere inside
<record id="product_recurring_donation_pricing_monthly" model="product.pricelist.item">
            <field name="plan_id" ref="sale_subscription.subscription_plan_month"/>
            <field name="product_tmpl_id" ref="product_recurring_donation"/>
            <field name="fixed_price">1.0</field>
            <field name="pricelist_id" eval="False"/>
        </record>
```

Cause:
- Error is raised when assigning the `Monthly` subscription plan in the `website_sale_subscription` master data because the user has deleted the `Monthly` subscription plan.

Solution:
- As the `plan_id` is not a required field, we can skip assigning the `plan_id` if it the record is not found.

sentry-7441124574

When using the click & collect option, the available qty for renting was not taking the selected warehouse into account.

Steps to reproduce:
-------------------
* Create 2 different warehouses with 2 different adresses
* Create a product available for renting
* Setup the product to use serial numbers
* Create 2 serial number, 1 in each warehouse
* Activate the click & collect option on the website
* Create a first sale order to collect in warehouse 1
* In the backend, confirm the order and pick it up
* Go back to the website and make a second order for the second warehouse
> Observation: When clicking on the "Add to cart" you get an error
  saying that there is no quantity available

Why the fix:
------------
When computing the `product_rented_quantities` it would look for `sale.order.line` in all the warehouse. So it would find the line from the first order even if it's not linked to the selected warehouse. So we just add a new element to the domain to filter out the incorrect warehouses.

opw-6328475

Forward-Port-Of: odoo/enterprise#126817
Forward-Port-Of: odoo/enterprise#124969

**Before this change**
We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values.

This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record.

**After this change**
Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record.

Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state.

opw-6390453

Forward-Port-Of: odoo/enterprise#125374

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126402
Forward-Port-Of: odoo/enterprise#125798

Before this commit, test_chatbot_stop_when_agent_joins failed at random in nightly builds:

    FAILED: [8/13] Tour chatbot_stop_when_agent_joins_tour -> Step
    .o-livechat-root:shadow button:contains(Try again).
    Element (.o-livechat-root:shadow button:contains(Try again)) has
    not been found.
    TIMEOUT step failed to complete within 10000 ms.

This happens because the test monkeypatches the chatbot_trigger_step route to make the email step fail once, while the routing map bakes the controller endpoints in when it is built and keeps them in the "routing" ormcache. Every later request reuses that map, so when it was already built with the original method the patch is ignored: the step never fails, the chatbot posts its last step and the retry button the tour clicks never appears.

This commit fixes the issue by invalidating the "routing" ormcache inside the patch, as done for meeting_view_tour, so the request reaches the patched route.

https://runbot.odoo.com/odoo/error/945351

Steps to reproduce:

1) Install hr_holidays & hr_attendance.
2) Enable "Display Extra Hours" & "Absence Management" in the Attendance app settings.
3) Make a new employee, in the form view click the "+" button to make a new hr version record for this employee.
4) Set the date to be the first of the last month.
5) In the Attendance app -> New -> Select the new employee.
6) Select the check in and out dates to be from last month, edit the times such that the time worked is between 7 and 8 hours (ex 9:00am to 4:55pm).
7) In the Attendance app -> Reporting -> Attendances -> the test employee should have a negative value for "Worked Extra Hours"
8) Create a new time off type, enable "Deduct Extra Hours" & disable "Requires Allocation" use hours as the Unit of measure.
9) Open the time off smart button menu from the test employee's form view.

Issue) The value seen in the report from step 7 is not the same as what the user sees in the dashboard.

Notes) This issue can occur when an employee scheduled to work for 8 hours a day only clocks in for 7:55 hours leading to a negative extra time.

The back-end has the correct value stored and sends it to the browser. The issue occurs because the JavaScript function that converts the decimal number of hours into a string (9.5 -> "9:30") does not work with negative input. This PR resolves that issue. 

opw-6417543 

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

Forward-Port-Of: odoo/odoo#280491

### Issue:
A user who can modify `tax_exigibility` but does not have `account.group_account_readonly` is blocked from switching to `on_payment`
There is no way to complete the operation as the account field is not visible and cannot be filled before saving
 
### Cause:
When `tax_exigibility` is set to `on_payment`, the view expects `cash_basis_transition_account_id` to be filled before saving`_constrains_cash_basis_transition_account` then validates that the account is reconcilable
 
`cash_basis_transition_account_id` was restricted to `account.group_account_readonly`, hiding it from other users
The field is never rendered, so it cannot be filled
The `required` constraint is never evaluated client-side and `_constrains_cash_basis_transition_account` raises a `ValidationError` on save because the account is empty
 
There is no reason to restrict `cash_basis_transition_account_id` independently — if a user can modify `tax_exigibility`, they must also be able to set the linked account
 
### Steps to reproduce:
- Install `account`
- Enable Cash Basis in Settings
  (On RunBot ensure no default account is set)
- Enable Developer Mode in Settings
- Go to Settings > Users & Companies > Users
- Open the current user and disable both:
  `Show Accounting Features - Readonly` and `Show Full Accounting Features` (if set)
- Go to Invoicing > Configuration > Taxes
- Open any tax and go to Advanced Options
- Change Tax Exigibility to Based on Payment

Before the fix, the account selector is not displayed and saving raises an error
 
opw-6359173

Forward-Port-Of: odoo/odoo#274728

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#280351

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#280329

Steps to reproduce
1. Go to Manufacturing > Configuration > Settings and enable By-Products
2. Go to Inventory > Configuration > Locations, find the location with type
   Production and set the Cost of Production account
3. Go to Inventory > Configuration > Product Categories and set the costing
   method to Standard Price and Inventory Valuation to Perpetual (at invoicing)
4. Set the finished product and byproduct as Storable with a non-zero Cost
5. Create a BoM with a component and a byproduct with a Cost Share % assigned
6. Create and complete a manufacturing order
7. Check the journal entries of the MO: the byproduct entry shows $0

Issue
Standard-cost byproduct moves have no price_unit set in either code path
of _cal_price, so their journal entries always show $0.

When the finished product is standard cost, _cal_price returns early at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L66-L68
without iterating byproducts at all, so no price_unit is ever set on them.

When the finished product is FIFO/AVCO, the byproduct loop at
https://github.com/odoo/odoo/blob/55221db559cda1c61229eecf8493f5fbaee5cd50/addons/mrp_account/models/mrp_production.py#L83-L84
only sets price_unit for FIFO/AVCO byproducts. Standard byproducts are
skipped, giving them $0 even though their cost_share was already deducted
from the finished product, making value disappear from inventory entirely.

For standard-cost products the MO has no influence on their value — they
always use the standard_price from the product form, regardless of cost_share.

Solution
In the early-return branch, iterate byproducts: standard ones get
standard_price, FIFO/AVCO ones get total_cost * cost_share.
In the FIFO/AVCO branch, add the same standard_price fallback so standard
byproducts are no longer left at $0 when their cost_share is set.

opw-6020065

Forward-Port-Of: odoo/odoo#280614
Forward-Port-Of: odoo/odoo#257472

**Issue**
Confirming a SO that generates a batch of MOs from a BoM with a
batch size could lead to creating an invalid number of pickings: all the
MOs end up sharing a single picking instead of getting one each.

**Steps to reproduce**
- Use 2-step manufacturing
- Create a storable product with the MTO + Manufacture routes
- Add a BOM that has a batch size of 10 that consumes one component
- Create and confirm a SO of 100 units of that product
-> 10 MOs are created, but each one points to the same "Pick Components" transfer instead of getting its own.

**Cause**
This commit dd6ee071f949752d31497d9f975ba7fc41ebcd98 batches the confirm of productions: 
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/mrp/models/stock_rule.py#L120
thus `assign_picking` is called in batches: 
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/mrp/models/mrp_production.py#L1653
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1736-L1737
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1550-L1556
since, the `reference_ids` are the same for each MO/stock.move (they all come from the same procurement):
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1712-L1713

Consequently, all the moves end up in the same recordset `moves`:
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1527
Creating only one picking:
https://github.com/odoo/odoo/blob/b51dc298fd63d9586d0b8d7cff59764b0dee5cae/addons/stock/models/stock_move.py#L1577

opw-6403427

Forward-Port-Of: odoo/odoo#279179

Issue
-----
Branch companies can have quants of a product limited to their parent company, but they don't show in the per location report.

Steps to reproduce
-----
- Create a branch company
	- Create a WH for the branch
- Create a tracked product
	- Company set to parent only
- Switch to the branch company
	- Add a quant of the product in branch stock
- Open Inventory > Reporting > Locations

> The product is not shown although there is a quant in the branch

Cause
-----
The menu button triggers `action_view_quants`

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/views/stock_quant_views.xml#L493-L495

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L399-L402

The problem here comes from the fact that in `_get_quants_action`, we limit the products to those of only the active companies, instead of allowing to view those of parent companies aswell.

https://github.com/odoo/odoo/blob/03a3662212f094158f885ae6545009fd0a74d3cb/addons/stock/models/stock_quant.py#L1330

Such a change works because the domain is specifically for the product's (`product_id.company_id`) and not the location's.

-----
Ticket:
opw-6131525

Forward-Port-Of: odoo/odoo#280083
Forward-Port-Of: odoo/odoo#277531

A user with role Inventory/User cannot validate the dropship of a product with an Average Cost (AVCO) Costing Method

Steps to reproduce:
1. Install sale_management, stock_dropshipping and stock_landed_costs module
2. Go to Sales > Configuration > Categories and change Furniture / Office's Costing Method to Average Cost (AVCO)
3. Go to Settings > Users and set Marc Demo's role on Purchase to User
3. Log in as Marc Demo
4. Create and confirm a quotation for customer Acme Corporation with product Large Cabinet (Dropship route and AVCO costing method)
5. Go to the related purchase order and confirm it
6. Go to the related dropship and validate it
7. An access error is raised

Issue:
Validating a dropship recomputes the cost of the product and reads `stock.valuation.adjustment.lines`
https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/models/stock_move.py#L11 But only Inventory/Administrator have read access to these records https://github.com/odoo/odoo/blob/cb7b3de6cea07464bcadd1325f52533d34ce09bc/addons/stock_landed_costs/security/ir.model.access.csv#L4

Solution:
Call `_get_landed_cost` with `.sudo()` in order to update the cost even though the user has no landed costs access

opw-6366844

Forward-Port-Of: odoo/odoo#280521
Forward-Port-Of: odoo/odoo#276285

Steps to reproduce the error: (Python Version: 3.14.X)
- Install ``accounting_firm`` industry with demo data

Code for server action to generate the error:
```py
for i in [1]:
    try:
        pass
    except Exception:
        pass
    if i:
        pass
```

Traceback:
```py
ValueError: forbidden opcode(s) in'...': JUMP_BACKWARD_NO_INTERRUPT
```

https://github.com/odoo/industry/blob/701f7595453772e42ce72aa75df346a504e5bd82/accounting_firm/demo/ir_actions_server.xml#L105-L108
The server action contains a ``for`` loop with a ``try/except`` block followed by additional statements in the loop body,
this combination generates the ``JUMP_BACKWARD_NO_INTERRUPT`` opcode, which is not included in ``_SAFE_OPCODES`` at [1].
When the server action is evaluated by ``safe_eval``, it calls the ``assert_valid_codeobj`` method, which validates the compiled bytecode against ``_SAFE_OPCODES``. Since ``JUMP_BACKWARD_NO_INTERRUPT`` is not present in the allowed opcodes, ``assert_valid_codeobj()`` raises a ``ValueError`` at [2] before the server action is executed .

Solution:
``JUMP_BACKWARD_NO_INTERRUPT`` opcode is added in the ``_SAFE_OPCODES`` and it is also added in the ``_SAFE_QWEB_OPCODES``.
It was added in Python 3.11: https://docs.python.org/3/whatsnew/3.11.html#new-opcodes

``JUMP_BACKWARD_NO_INTERRUPT`` is a control-flow opcode that only changes
the interpreter's execution flow by jumping back to a previous instruction.
It is the equivalent to ``JUMP_BACKWARD`` opcode. Its only semantic difference is
that the interpreter does not perform an interrupt check at that instruction.
It does not introduce any new capabilities or perform operations such as
attribute access, imports, function calls, or object creation.
Ref: https://docs.python.org/3.12/library/dis.html#opcode-JUMP_BACKWARD_NO_INTERRUPT

Similar commit that adds some necessary opcodes: 
https://github.com/odoo/odoo/commit/86498d24946e510025add5d24ef0d4bcce8ad05f

[1]: https://github.com/odoo/odoo/blob/2ccbc4660077bd48529e9de43d4309fbfafc75ca/odoo/tools/safe_eval.py#L135
[2]: https://github.com/odoo/odoo/blob/2ccbc4660077bd48529e9de43d4309fbfafc75ca/odoo/tools/safe_eval.py#L244-L246

sentry-7614026125

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

Forward-Port-Of: odoo/odoo#277192

### Issue:
A partner with VAT set to '/' incorrectly matches a fiscal position with `VAT required`, instead of one without

The '/' value is the placeholder suggested by the UI to indicate that the partner is known to have no VAT, but it was treated as a valid VAT by the fiscal position matching logic

### Cause:
`_get_fpos_ranking_functions` uses `_get_vat_valid` to rank fiscal positions based on VAT presence
`_get_vat_valid` returned `True` for any non-empty VAT value, including '/'
The '/' case was not excluded, causing it to be treated as a valid VAT number

### Steps to reproduce:
- Install `account`
- Create two fiscal positions with auto-apply:
-- Name: FP VAT, VAT required: True, sequence: 1
-- Name: FP no VAT, VAT required: False, sequence: 2
- Create a partner with VAT: '/'
- Create an Invoice for that partner and check the Fiscal Position

Before the fix, `FP VAT` is selected instead of `FP no VAT`

opw-6204531

Forward-Port-Of: odoo/odoo#280494
Forward-Port-Of: odoo/odoo#280065

## Issue
When logging timesheet from the *Recorded* smart button on a Sale Order containing multiple service items, the recorded hours will be added to the first sale order line, regardless of the task ID set on the timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P:
    - *Product Type*: Service
    - *Create on Order*: Task
    - *Project*: Any
3. Create a SO:
    - *Customer*: Any
    - Add the product P on two different lines and give them two different descriptions D1 and D2
    - Confirm the SO, this will create two tasks with the names D1 and D2
4. On the SO, click the *Recorded* smart button and create two entries:
    1. Task D1, 2 hours spent
    2. Tsk D2, 3 hours spent
5. **Back on the SO, there are 5 hours registered for the first SOL (with the description D1), which does not match the entries we created from the smart button.**

It is worth noting that when we create the Timesheets entries from the project itself (instead of the SO's smart button), the hours are correctly distributed among the different SOLs.

## Cause
The SOL linked to the timesheet entry (`account.analytic.line`) is computed by `_compute_so_line`:

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/hr_timesheet.py#L79-L82

This method sets the correct SOL under the condition that `is_so_line_edited` is False and `_is_no_billed()` returns True.

When opening the *Recorded* smart button from a SO, the `is_so_line_edited` is set to True by default, even if no SOL was modified.

https://github.com/odoo/odoo/blob/8b102f500f5a122e99b07a08cc43814e7c6f0f75/addons/sale_timesheet/models/sale_order.py#L113-L117

As that value is never set to False, when trying to compute the SOL for the timesheet entry, the entry is skipped and the default SOL (which is the first one) is used instead.

opw-6133473

Forward-Port-Of: odoo/odoo#274759

When an invoice is created with "Invoice Overages" selected but not all delivered amounts are included, and a second invoice is then created without "Invoice Overages" selected, the system generates a credit note

Steps to reproduce:
1. Install Sales and Project
2. Go to Sales > Products and create a product "test" with Product Type: Service, Create on Order: Project & Task and Invoicing Policy: Prepaid/Fixed Price
3. Create a new quotation for any customer with one unit of product test and confirm it
4. Change the quantity delivered to 5
5. Click on Create Invoice and then Create Draft
6. Change the quantity to 3 and confirm
7. Go back to the sale order
8. Click on Create Invoice and uncheck Invoice Overages then click on Create Draft
9. A credit note is created even though there is nothing to invoice since Invoice Overages was disabled

Issue:
There is no mechanism to prevent the creation of an invoice if we set Invoice Overages to false

Solution:
Prevent invoice creation if Invoice Overages is set to False. Also had to adapt `_compute_invoice_overages` to make it consistent with its inverse method while keeping `allow_invoice_overages` as the default value.

opw-6356807

Before this commit, this test sometimes failed because it couldn't find a dialog containing "camera" within 200ms.

In the test scenario, we click to open the BarcodeDialog, which uses the BarcodeVideoScanner. The latter, in its `onMounted`, checks whether it has the necessary permission, which isn't the case as the `getUserMedia` function is mocked in the test to return a rejected promise. As a consequence, the `onError` callback given in props is called, which changes the state of the parent component, which re-renders itself so display "Unable to access camera" instead of the BarcodeVideoScanner.

To make this test more robust, we do 2 things:
1) load the zxing library before running the test, which avoids the BarcodeVideoScanner component to load it in onWillStart. 2) explicitly wait for the 2 animationFrames, as in the scenario, we must wait for the BarcodeDialog to be rendered twice, and those renderings are now synchronous.

runbot error-237933

Forward-Port-Of: odoo/odoo#280613

[FIX] html_builder: prevent crash on legacy image shapes
When the Website Editor encounters an image shape that does not exist
in the registry, it fatally crashes upon saving (`TypeError: Cannot
read properties of undefined`), blocking the user from saving the page.

While an upgrade script exists to remap these shapes
([commit https://github.com/odoo/odoo/commit/f348be018f5740a31754494c905ea2b61bb718be](https://github.com/odoo/upgrade/commit/f348be0dcbc63c1f74f742b562509f81767564c0)),
timeline gaps leave SaaS databases vulnerable. For example, if a client
upgraded their database to 17.0 in Feb 2024, they bypassed the migration
script merged in Dec 2024. This leaves the legacy shape permanently
orphaned inside their modern views.

This commit adds a `getImageShape` fallback. Instead of crashing,the
editor now defaults to standard values and renders "None" in the UI,
allowing the user to select a new shape and save their work.

Steps to Reproduce:
1. Install Website.
2. Go to Site -> HTML / CSS Editor.
3. Add `data-shape="web_editor/basic/bsc_organic_2"` to an <img> tag.
4. Click "Edit" to open the Website Builder.
5. Click the image, OR click "Save".
6. JS traceback.

[opw-6286044](https://www.odoo.com/odoo/my-support-tasks/6286044?debug=assets)
[opw-6291591](https://www.odoo.com/odoo/my-support-tasks/6291591?debug=assets)

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

Forward-Port-Of: odoo/odoo#280505
Forward-Port-Of: odoo/odoo#270356

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse deliveries in two steps
- Inventory > Operations > Tranfers > Internal > New
- Set the operation type as Pick, set a partner and add Partner: Bob
- In the sales & Purchase tab of the partner form set a customer location to be a child of the Customers location: Customers/Bob'Stock
- Confirm and validate the Pick for 1 unit of a product P
#### > A ship picking is created but the destination of the related move is still set to the default customer location.

### Note:

If the flow is performed by a sale order, the `property_stock_customer` location will appropriately be used as `location_final_id`: https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L297 https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L306-L309 https://github.com/odoo/odoo/blob/720598d0315dbb91628441078febfd43ffefb431/addons/stock/models/stock_rule.py#L263-L264 So that the bug does not occur in that case. By contrast if the pick move is created manually, we do not set its `location_final_id` and hence do not propagate the info. Even though it looks expected to be set set as location_dest_id of the ship move sas suggested by the `stock.picking.location_dest_id` compute method :
https://github.com/odoo/odoo/blob/fe3aea07a1964cd24f4c8ebf2bc93e483eca6b0b/addons/stock/models/stock_picking.py#L990-L1002

opw-6402483

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

Forward-Port-Of: odoo/odoo#279616
Forward-Port-Of: odoo/odoo#278838

[*]=website

1. Sync background shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    3. Drop any snippet.
    4. Add a background shape.
    5. Set the background shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
  
    Issue:
    The background shape color is not updated when the theme color changes.
    
    Reason:
    The background shape color is embedded in the URL of the "**background-image**" style attribute. When the theme color value changes, this URL is not updated. Additionally, the URL uses color variables rather than resolved hexadecimal color values as parameters. As a result, even when an updation occurs, the URL itself remains unchanged, preventing the background shape color from being updated.
    
2. Sync image shape color with color preset.

    Steps to reproduce:
    1. Go to the website and enter edit mode.
    2. Drop any snippet.
    4. Click on the image and add a shape.
    5. Set the image shape color to "o-color-1".
    6. Go to theme tab.
    7. Change the value of theme color 1 from theme preset.
    
    Issue:
    The image shape color is not updated when the theme color changes.
    
    Reason:
    When the theme color value changes, the SVGs are not re-fetched. Additionally, the image "**shapeColors**" dataset stores the hexadecimal value of the theme color instead of the corresponding CSS variable. As a result, there is no way to determine which theme color was selected (for example, whether `o-color-1` or `o-color-2`), since only the hex value is available.


task-5438314

Forward-Port-Of: odoo/odoo#276135
Forward-Port-Of: odoo/odoo#241968