### Steps to reproduce:
- Enable developer mode
- Go to Settings > Technical > Messages
> ValueError: Cannot search, too many messages

### Cause of Issue:
The new `ir.access` model introduced through https://github.com/odoo/odoo/pull/166359 inherits from `mail.thread` and enables tracking on the `active`, `domain`, and `operation` fields. https://github.com/odoo/odoo/blob/713f68333798575d70362cbb55ca31e91e75d5fa/addons/mail/models/ir_access.py#L7-L12

In production databases, every access rule modification generates a tracking message on the corresponding `ir.access` record.

When a user opens Settings > Technical > Messages without any model filter, `_search_res_access` falls into the "enumerate all messages" path since no specific model is constrained in the domain. https://github.com/odoo/odoo/blob/713f68333798575d70362cbb55ca31e91e75d5fa/addons/mail/models/mail_message.py#L469-L473 This path calls `_filter_accessible_from_query`, which fetches messages up to `MAX_SEARCH_LIMIT` (= `PREFETCH_MAX * 10` = 10 000).
https://github.com/odoo/odoo/blob/713f68333798575d70362cbb55ca31e91e75d5fa/addons/mail/models/mail_message.py#L614-L615

Because `ir.access` tracking messages alone can exceed that limit, the guard raises:
> ValueError: Cannot search, too many messages

### Fix:
Exclude messages whose `model` is `ir.access` from the enumeration domain when fetching generic messages to ensure important information is present without exceeding the messages limit.

When the user's search domain already constrains the model to `ir.access` (e.g., when opening the chatter of a specific access rule record), `condition_values()` detects the model constraint and the per-model SQL path is taken instead — so those messages remain fully accessible in their own context.

opw-6364325

**Issue**
The package of the selected quant is not proposed as a destination package when adding stock move lines manually before the move line is saved.

**Steps to reproduce**
- Activate 'Packages' in the settings
- Create a tracked product with package
- Put 10 units in stock in package `P`.
- Create and confirm a sale for 5 units
- Open the delivery, make sure the quantity is set to 0
- Click 'Details'
- "Add a line" and select the package P
-> if you try to select a destination package, the package P is not proposed as it should
- save it and reopen 'Details' 
-> if you try to select a destination package, the package P is now proposed

**Cause**
The domain of `result_package_id` (destination package) correctly includes `package_id`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L52-L56

However, before saving, `package_id` is not yet populated into the new `stock.move.line` record. It will only be copied from `quant_id` by `_copy_quant_info()`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L1016-L1025 which will only be called in the create method, while saving: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L350

opw-6370159

Forward-Port-Of: odoo/odoo#277797

With the Shared Customer Account setting enabled, a user created in c1 cannot access the shop in the website of c2

Steps to reproduce:
1. Install eCommerce and Contacts
2. Go to Settings > Users & Companies > Companies and create two companies c1 and c2
3. Go to Website > Configuration > Websites and create two websites w1 with company c1 and w2 with company c2
4. Change the order of the websites so that w1 is at the top
5. Go to Website > eCommerce > Pricelists and create a pricelist pl1 in c1 assigned to w1 and pl2 in c2 assigned to w2
6. In an incognito tab, go to w1 and create a new account
7. As admin, go to Website > Configuration > Websites and change the order of the websites so that w2 is at the top
8. In an incognito tab, connect with the previously created account and go to the shop
9. An error is thrown
(This error only happens when geoip works, i.e. when `_get_geoip_country_code` returns something)

Issue:
When geoip returns a country code, we search through all the pricelists available for that country code but some of them can be restricted to a company which raises an access error. We need to be able to access them in order to filter the ones that are not available on the current website

Solution:
Access all pricelists with sudo, they will be filtered out with `_is_available_on_website`

opw-3574089

Forward-Port-Of: odoo/odoo#279697
Forward-Port-Of: odoo/odoo#268863

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

**Steps to reproduce:**
- Install website_forum
- Create a new post on the forum with the admin
- Subscribe to the post notifications using the bell button
- Create a new portal user and give him 5 karma
    (to give him enough rights to answer and comment)
- Connect with the portal user and go to the post
- Create an answer
- Try to comment on your own answer
- AccessError is raised

**Issue:**
Since [1] we check comodel access (in this case `res.partner`) when adding records. Here during the `message_post` the `question_followers` are added manually as `partner_ids` before sending (the logic only relies on the original post subscribers, not on the added comment/reply).

```py
question_followers = self.env['mail.followers'].sudo().search([
    ('res_model', '=', self._name),
    ('res_id', '=', self.parent_id.id),
    ('partner_id', '!=', False),
]).filtered(lambda fol: comment_subtype in fol.subtype_ids).mapped('partner_id')
partner_ids += question_followers.ids
```

As the portal user has no `read` access to the subscribers the message creation fails with a traceback.

**Fix:**
Add `sudo` to the `message_post` call of `post_comment`.

(Also fix a minor display issue in the 'Karma Error' notification)

[1] https://github.com/odoo/odoo/commit/aae732957c3c3b3590f5686cfccc0ab264d0b5c9

opw-5318757

Forward-Port-Of: odoo/odoo#279091
Forward-Port-Of: odoo/odoo#274751

**Issue**
The package of the selected quant is not proposed as a destination package when adding stock move lines manually before the move line is saved.

**Steps to reproduce**
- Activate 'Packages' in the settings
- Create a tracked product with package
- Put 10 units in stock in package `P`.
- Create and confirm a sale for 5 units
- Open the delivery, make sure the quantity is set to 0
- Click 'Details'
- "Add a line" and select the package P
-> if you try to select a destination package, the package P is not proposed as it should
- save it and reopen 'Details' 
-> if you try to select a destination package, the package P is now proposed

**Cause**
The domain of `result_package_id` (destination package) correctly includes `package_id`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L52-L56

However, before saving, `package_id` is not yet populated into the new `stock.move.line` record. It will only be copied from `quant_id` by `_copy_quant_info()`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L1016-L1025 which will only be called in the create method, while saving: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L350

opw-6370159

Forward-Port-Of: odoo/odoo#277797

**Steps to reproduce:**
1. Create a new SO and enable "Online Signature" and "Online Payment" in the "Other Info" tab
2. Click on Preview and click on "Sign & Pay" from the portal (demo payment should be enabled from the settings to proceed)
3. Once the transaction is processed and the order confirmed, check the confirmation email/PDF sent to the customer in the chatter

**Issue:**
- The order confirmation sent to the customer after paying online does not include the signature they provided when accepting the quotation
- Even if "Online Payment" is not enabled and Signing will directly confirm the order, the signature is still missing.

**Why this happens:**
- The signature block in `sale.report_saleorder_document` is gated by the `sale_include_signature` context key rather than solely by doc.signature. This was introduced by commit ef8246a4daf6146da2ed3cb78c37c7bf0937a4df to retain signature integrity.
- `portal_quote_accept` only sets this context right after the customer signs on the pdf rendered for us (company), and was not passed through `_validate_order()` when there was no online payment
- When online payment is required, `_has_to_be_paid()` defers the order confirmation which happens later, and the context is never set elsewhere

**Fix:**
- Pass the context when online payment is not required
- If online payment is required, the sale quotation can be modified after being signed. However, since the customer previews the quotation when Paying, we can say the signature integrity is retained

opw-6389733

Forward-Port-Of: odoo/odoo#278854

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

Steps to reproduce the issue easily:
- Remove the section in the footer.
- Drop enough snippets to have a scroll bar and to not see the footer when the scroll is at the top.
- Drop the "Pricelist" snippet at the bottom of the page and click on a column.
- Scroll up so the footer and the bottom of the snippet are not visible, and add a pricelist item with the "Add Product" option.
- => The page scrolls to the new item, but a big white space appears at the bottom of the screen, as if we scrolled too far.

The same issue happens with similar steps in the following cases:
- When using any option using the `addItem` action.
- When undoing/redoing a step that was done in an element not in the viewport (the screen will scroll to it and we will have the issue).
- When showing an invisible element (the screen will scroll to it if not in the viewport)
- Adding a grid item with the "Add Elements" option.
- Adding a new card in the "Floating Cards" snippet.

The common point to all these cases is that they all scroll to the added or shown element with the `scrollIntoView` built-in function, which scrolls everything, including the viewport. It also doesn't take into account the header that changes during the scroll, often ending with the element hidden by the header.

This commit fixes these issues by using the builder `scrollTo` util, which takes the header into account and only scrolls what needs to be. This function should always be preferred when scrolling in the builder.

task-6314322

Forward-Port-Of: odoo/odoo#278897
Forward-Port-Of: odoo/odoo#275686

**Problem:**
When creating a new task, the Customer does not follow the project the user selects: once a first project has filled it, selecting another project keeps the previous project's customer.

**Steps to reproduce:**
1. Create a new task and select a project that has a customer.
2. The Customer is set to that project's customer.
3. Select another project configured with a different customer.
4. Observe the Customer keeps the first project's customer.

**Current behavior:**
The Customer keeps the first selected project's customer.

**Expected behavior:**
The Customer follows the selected project and shows its customer.

**Cause of the issue:**
partner_id is filled by _compute_partner_id, which only assigns a partner while the field is empty. Once a project has filled it, selecting another project no longer refreshes the now non-empty Customer.

**Fix:**
Refresh the Customer from the project on project_id change, but only while the task is new (no _origin). An existing task's customer is left untouched, since it may already carry sale order lines, timesheets, materials or worksheets that must not be reset when the project changes.

opw-6315902

Forward-Port-Of: odoo/odoo#278526
Forward-Port-Of: odoo/odoo#276211

Steps to reproduce:
Use the real testing credentials
Make sure the invoice sequence is not generated on the real testing credentials

1. Create an invoice with overseas partner
2. Create ewaybill

Error from the portal:
`[372] Invalid or Blank Consignee Ship-to State Code`

It is currently a flaw in the government portal because in Government portal there is no option for the Other country (99) for Ship to state code and only option for Other Teritory(97)

It is because in reality, it should the port ship to state code but there cases where goods can be transfered to nearby country i.e. Bangladesh, Nepal where good can taken by road from India

In that case the state code should be 97

task-6431082

**Second Commit**
- [FIX] l10n_in_ewaybill: import/export GSTIN should be URP
Steps to reproduce:
Use the real testing credentials
Create a SEZ partner
Create an invoice and ewaybill
Select the type of Ewaybill as Export Tax Invoice

We get error code-450
which clearly states, `450 For outward-export ewaybill, To GSTIN has to be either URP or SEZ`


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

Forward-Port-Of: odoo/odoo#279289

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

Issue:
-------
When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor.
for ex: `#snippet-anchor` in the `Button URL` field in the settings.

Cause:
--------
This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place.

Solution:
------------
To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on.
This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside.

Steps to reproduce:
-----------------------
1. Create a db in version 18.3 with website_sale installed.
2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings.
3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button.
4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings.
5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet.

Ref PR:
----------
https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399

Attachments:
-----------------
**Before Fix:**
[vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0)


**After Fix**:
[vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5)


- OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517)


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

Forward-Port-Of: odoo/odoo#249906
Forward-Port-Of: odoo/odoo#247587

**Issue**
The height is not correctly computed in the picking form when editing product description.

**Steps to reproduce**
- Create a delivery for a product
- Add a description to it
- Click on editing the description
 -> Observe that the description is partially hidden because the widget height is incorrectly computed

**Cause**
Since commit https://github.com/odoo/odoo/commit/e4f4171e1bc838840c0bd6111cd78f348b201ac2, `useProductAndLabelAutoresize` no longer assigns a height to the widget root.

The corresponding widget is `MoveProductLabelField`, which extends `ProductNameAndDescriptionField`: https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/stock/static/src/views/picking_form/stock_move_product_label.js#L5 It uses `useProductAndLabelAutoresize`:
https://github.com/odoo/odoo/blob/91b59f285248c120fe9e3e5f6b6f086ea7be2837/addons/product/static/src/product_name_and_description/product_name_and_description.js#L54-L56 
**Solution**
Explicitly add a div around the product display and description to still use the `Autoresize`

Forward-Port-Of: odoo/odoo#271564

Steps to reproduce the bug:
- Create three storable products C1 ($10), C2 ($20), C3 ($5)
- Create a product P1 with a BoM: 1x C1 + 1x C2
- Create a Manufacturing Order for P1 and validate it
- Unlock the MO (Settings > Unlock)
- Add C3 as an extra component on the unlocked MO
- Open the MO overview

Problem:
The extra move had value=0 after creation, causing the unit_cost in the
MO overview to appear as 0. When a move is added to a done picking or MO
it is created with state='done' and quantity set immediately. This triggers
_set_quantity_done, which creates the move line and calls
_set_value(correction_quantity=delta). Inside _set_value, for outgoing
moves with a correction_quantity, the code computes:
  previous_qty = move.quantity - correction_quantity
Since the move had no prior quantity, previous_qty=0. The original code then
computed ratio=0 and applied move.value += 0, leaving value=0 instead of
computing it from scratch.

Solution:
When previous_qty=0, skip the ratio branch and fall through to the existing
from-scratch computation (standard_price * _get_valued_qty() for AVCO/standard
costing, _run_fifo() for FIFO).

opw-6377393

Forward-Port-Of: odoo/odoo#276303

Steps to reproduce the bug:
- Install point_of_sale
- Open the POS frontend and create a new product from the register
- Add it to the order, then open its product info popup and edit it
    - Rename it and change its price
- Confirm the edit dialog
- Click on the (renamed) product again to add it to the order

Problem:
On runbot the tour test_product_create_update_from_frontend (point_of_sale/tests/test_frontend.py, MobileTestUi) intermittently times out waiting for the orderline to show the edited product name/quantity/ price combination.

editProduct()'s onSave callback in pos_store.js closed the edit dialog via act_window_close right after firing this.data.read("product.template", ...) and this.data.searchRead("product.product", ...), without waiting for either call to resolve. When the dialog closes before those RPCs land, the in-memory product record used by canBeMergedWith() (pos_order_line.js) to decide how to merge/create the next orderline can still hold the stale price, so re-clicking the product right after editing produces an orderline that never matches the expected quantity/price.

Solution:
Make onSave async and await both this.data.read() and this.data.searchRead() before closing the dialog, so the reactive store is guaranteed to hold the updated product data before the user (or the tour) can interact with the product again.

runbot-223630

Forward-Port-Of: odoo/odoo#279496
Forward-Port-Of: odoo/odoo#277698

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037

When an internal recipient receives an Out of Office (OOO) notification, the resulting `mail.message` record has `partner_ids` populated with the recipient partner ID, while `outgoing_email_to` is set to `False`.

When a second internal user emails the OOO user within the 4-day window, `_notify_thread_with_out_of_office` excutes a search domain with an OR condition: `'|', ('partner_ids', 'in', recipient.ids), ('outgoing_email_to', '=', email_to)`

Because `email_to` is `False` for internal partners, `('outgoing_email_to', '=', False)` evaluated to `True` against the first recipient's message record. Consequently, the search falsely determined that the second recipient was already notified, suppressing OOO replies for all subsequent contacts across the 4-day window.

## Proposed solution:
We resolve this by dynamically constructing recipient sub-domains conditionally depending if `recipient` or `email_to` are set.
We also extend `test_routing_with_out_of_office` with a corresponding test case.

## How to reproduce:
1. Set up a DB with at least 3 users (User A, User B, User C).
2. Configure User A to be out of office (in user preferences)
3. Go to any chatter/mail.thread while logged as User B and tag User A in a log note. -> triggers OOO message
4. Log as User C, tag User A in a log note. -> BUG: no OOO message because the "4 day" check falsely believes that User C already received a OOO from User A

OPW-6110300

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

Forward-Port-Of: odoo/odoo#277880

**Issue**
The package of the selected quant is not proposed as a destination package when adding stock move lines manually before the move line is saved.

**Steps to reproduce**
- Activate 'Packages' in the settings
- Create a tracked product with package
- Put 10 units in stock in package `P`.
- Create and confirm a sale for 5 units
- Open the delivery, make sure the quantity is set to 0
- Click 'Details'
- "Add a line" and select the package P
-> if you try to select a destination package, the package P is not proposed as it should
- save it and reopen 'Details' 
-> if you try to select a destination package, the package P is now proposed

**Cause**
The domain of `result_package_id` (destination package) correctly includes `package_id`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L52-L56

However, before saving, `package_id` is not yet populated into the new `stock.move.line` record. It will only be copied from `quant_id` by `_copy_quant_info()`: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L1016-L1025 which will only be called in the create method, while saving: https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/stock/models/stock_move_line.py#L350

opw-6370159

Forward-Port-Of: odoo/odoo#277797

**Steps to reproduce:**
1. Create a new SO and enable "Online Signature" and "Online Payment" in the "Other Info" tab
2. Click on Preview and click on "Sign & Pay" from the portal (demo payment should be enabled from the settings to proceed)
3. Once the transaction is processed and the order confirmed, check the confirmation email/PDF sent to the customer in the chatter

**Issue:**
- The order confirmation sent to the customer after paying online does not include the signature they provided when accepting the quotation
- Even if "Online Payment" is not enabled and Signing will directly confirm the order, the signature is still missing.

**Why this happens:**
- The signature block in `sale.report_saleorder_document` is gated by the `sale_include_signature` context key rather than solely by doc.signature. This was introduced by commit ef8246a4daf6146da2ed3cb78c37c7bf0937a4df to retain signature integrity.
- `portal_quote_accept` only sets this context right after the customer signs on the pdf rendered for us (company), and was not passed through `_validate_order()` when there was no online payment
- When online payment is required, `_has_to_be_paid()` defers the order confirmation which happens later, and the context is never set elsewhere

**Fix:**
- Pass the context when online payment is not required
- If online payment is required, the sale quotation can be modified after being signed. However, since the customer previews the quotation when Paying, we can say the signature integrity is retained

opw-6389733

Forward-Port-Of: odoo/odoo#278854

Steps to Reproduce the Error (Odoo SaaS 19.2):
1. Install l10n_gcc_invoice localization & Accounting
2. Activate Arabic language (ar_001) and add Default Terms and Conditions in Settings > Configuration > Customer Invoices > Default Terms and Conditions
3. Create invoice with ar_001 partner
4. Confirm the invoice
5. Try to create credit note → Error: KeyError: 'en_US'

Root Cause:
The _load_narration_translation() workaround reads raw invoice_terms from DB and injects the entire JSONB dict directly into cache, bypassing ORM field conversion. When Odoo 19.2's improved ORM conversion runs, it creates nested JSON in narration instead of a flat structure.

Timeline:
- bedf1cb66fbb: Workaround added to prevent T&C duplication in preview
- 75f050b9650d: Root cause fixed in report template (conditional display) → Made _load_narration_translation() redundant
- 4e4156536bc9: Odoo 19.2 improved ORM conversion → Now conflicts with the redundant workaround, causing nested JSON

How It Breaks:
1. Invoice creation: _load_narration_translation() injects raw dict into cache
2. ORM writes: nested JSON stored: {ar_001: {en_US: ., ar_001: Arabic}}
3. Credit note creation: copy_translations() expects flat structure → Crashes: KeyError: 'en_US'

Why It's Safe to Remove:
Report template already prevents T&C duplication (commit 75f050b9650d). Removing the workaround restores proper credit note creation without breaking T&C display.

Changes:
- Remove moves._load_narration_translation() in create()
- Remove out self.filtered('id')._load_narration_translation() in _compute_narration()

opw : 6284943

Forward-Port-Of: odoo/odoo#271037