## Current behaviour:
When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order.

## Expected behaviour:
If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order.

## Steps to reproduce:
1. Validate a delivery order integrated with Starshipit.
2. Trigger a label generation failure (e.g., bad address).
3. Observe that the created Starshipit order is deleted.

## Cause of the issue:
The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order.

## Fix:
Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual.

## Additional note:
The _() wrapper in the error line was removed because
the Starshipit service has no env or language context.
Since translations cannot be resolved there, Odoo raised a warning.
Removing _() avoids this warning and keeps the error clean.

opw-5306979

Forward-Port-Of: odoo/enterprise#103354
Forward-Port-Of: odoo/enterprise#101174

Situation
-----
When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054

because of the `m.location_id == move.location_final_id` part being false in

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097

This is because, during the merge, `location_final_id` is not propagated to the new MO

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424

so when the new MO's `move_finished_id` gets computed

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822

it gets the MO's `location_final_id`

https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202

which is false. This leads to to the move getting the warehouse's default stock location thanks to

https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457

This is problematic for complex use cases with multi-locations and custom routes.

It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one.

Use case example
-----
<details>
<summary>Full use case</summary>

- Enable multi-step routes
- Create location "WH/Stock/L1"
- Create location "WH/Stock/L2"

- Create Operation Type "MO child"
	- Type of Operation: Manufacturing
	- Sequence Prefix: MOCHILD
	- Source Location: L1
	- Destination Location: L2
- Create Operation Type "Push Transfer"
	- Type of Operation: Internal Transfer
	- Sequence Prefix: L2L1
	- Source Location: L2
	- Destination Location: L1
- Create Route "MO child"
	- Create Rule "Manufacture"
		- Action: Manufacture
		- Operation Type: MO child
		- Source Location: False
		- Destination Location: Stock
- Create Route "2-step"
	- Warehouse: Main WH
	- Create Rule "L1 -> Virtual/Production"
		- Action: Pull from
		- Operation Type: MO child
		- Source Location: L1
		- Destination Location: Virtual/Production
	- Create Rule "Push: L2 -> L1"
		- Action: Push To
		- Operation Type: Push Transfer
		- Source Location: L2
		- Destination Location: L1
- Unarchive MTO
- Edit MTO route
	- Create Rule "L1 -> Virtual/production (MTO)"
		- Action: Pull
		- Operation Type: "My Company: Manufacturing"
		- Source Location: L1
		- Destination Location: Virtual/Production
		- Supply Method: Trigger another rule
- Create product "Main product"
- Create product "Child product"
	- Routes: "MO child" & MTO
- Create product "Material" (consumable)
- Create BOM
	- Product: "Main product"
	- Component: "Child product"
- Create BOM
	- Product: "Child product"
	- Component: "Material"
- Create MO for "Main product"
	- Misc/Component Location set to L1
- Duplicate the MO
- Merge child MOs & produce
- Validate merged MO transfer to L1
- Go back to one of the "Main product" MO

> Component quantity is 0
</details>

-----
Ticket:
opw-5144196

Forward-Port-Of: odoo/odoo#240695

## Description of the issue/feature this PR addresses:
`compute_is_storable` is called when the `type` value is modified but the `write` function is never called when the value is set using the `is_storable` attribute. Updating `is_storable` using a `write` ensure that an exception is raised when move line exists.

But this fix addresses the symptom, not the underlying issue. So why ? Is it related to the cache or unit test environment ? 

## Current behavior before PR:
In a Unit test, If you convert a consumable and storable product to a service, no exception is raised, even with existing stock moves.
Unlike the previous version of Odoo (<15.0), where an exception was raised when the product type was changed and stock movements existed, detection now occurs if the ‘is_storable’ status is changed. However, this detection is not triggered if the value of ‘is_storable’ is defined by its attribute.

## Desired behavior after PR is merged:
An exception must be raised (like Odoo 14.0)



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

Forward-Port-Of: odoo/odoo#242514
Forward-Port-Of: odoo/odoo#239284

Putting in pack from the SML view leads to package incorrectly located

To reproduce the issue:
1. In Settings, enable "Package"
2. Confirm a delivery with 2 available products
3. Open the SML thanks to the smart button
4. Tick a line > Put in pack
5. On the second line, in "Destination Package", look for the package

Error: it is impossible to find it

When opening the SML thanks to the smart button, we also load a lot 
of default values:
https://github.com/odoo/odoo/blob/1492abd8c6bcfdbc48f730f6767b177aeff54bf7/addons/stock/models/stock_picking.py#L1203-L1221
Those are (obviously) SML specific.

However, this context is used when putting in pack. This is a 
problem since `location_id` is also the field name of a package. As 
a result, the ORM defines the location of the new package with the 
default value, i.e. the source location of the SML. This is incorrect.

One consequence of this bug is the step 5 of the above use case. 
When looking for a package, a domain checks its location:
https://github.com/odoo/odoo/blob/35feed47622b279abf8e593d8190ea36b64d32fd/addons/stock/models/stock_move_line.py#L51-L55
It must be either `False` or equal to the dest loc, which is not the 
case with the created package.

Now... About the solution. It's probably difficult to do something 
more hacky. However, it's not too invasive in the code and all user 
will take benefit from it once the commit is deployed. On master, we 
will discuss with both frameworks to negotiate/find something more 
elegant.

OPW-5215243

Forward-Port-Of: odoo/odoo#242328

[FIX] website_sale, adding website_id in portal controller

Version: 17.0+e

Steps to reproduce
------------------
The database has two different websites.

A payment provider is enabled for just one of them (website1).

When a sale order is created on the sales app and the customer accesses it in its portal on the website2, he is able to pay with the payment provider which is only enabled on website1.

The problem also occurs when previewing the customer’s portal view.

Why it's happening
------------------
When accessing an order via “/my/orders/<int:order\_id>”, the portal_order_page method calls _get_compatible_providers without passing the website_id. The overriding logic in website_payment then defaults to considering all activated payment methods as compatible, regardless of website restrictions.

As no website_id is provided, the overriding method from the payment_provider extension in website_payment module considers every activated payment methods as compatible.

The Fix
-------
We now add the current website's id to the method if none has been added before.


opw-5172444, “Payment provider visible on sales order portal"


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

Forward-Port-Of: odoo/odoo#242380
Forward-Port-Of: odoo/odoo#235954

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

Forward-Port-Of: odoo/enterprise#101911

## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1]
Steps to reproduce:
- Go to Website -> Edit Mode
- Add a Countdown snippet (size: "Small")
- Save and zoom in/out, the countdown canvas and text appears blurry

The countdown was rendered at a low resolution, which caused it to blur
when zooming. This fix updates the canvas to draw at the proper
resolution so the countdown remains sharp at any zoom level.


## [FIX] web_editor: prevent text overlap with icon [Commit 2]
Steps to reproduce:
- Go to Website -> Edit Mode
- Add a Image snippet
- Enter a long text in search bar:

Issue:
1. Text overlaps with search icon.
2. Selecting the "Photos (via Unsplash)" option causes the text to
overlap the dropdown icon.

The fix adjusts the end padding to provide sufficient spacing between
the text and the icons.

task-[4771268](https://www.odoo.com/odoo/project/974/tasks/4771268)

Forward-Port-Of: odoo/odoo#242706
Forward-Port-Of: odoo/odoo#213373