When manually changing the tax amount of a vendor bill in the html input field (input above total price), if there is a price difference account move line created, the manual tax inputted will be ignored. This is due to the price difference and associated correcting account move lines having tax_ids. As such, both lines are considered taxable when they should not be and every time we create a price difference line, all taxes are recomputed and manually set tax lines are ignored. This is not the intended behavior because tax for price difference is already accounted for in the tax lines (computed before confirmation of bill) and the price difference lines themselves are just for account balancing and should not be considered taxable.

Steps to reproduce bug on empty DB:
1) Install account and purchase_stock
2) Turn on automatic accounting in settings
3) Create a product category. Set inventory valuation to automated and create and set a price difference account.
4) Create a product. Set the price, set to product category to the created one, and enable track inventory.
5) Create a vendor bill with the product and set a bill date. 
6) Change the price of the product in the bill lines to anything but the original price.
7) Change the tax by clicking on the input field with the pencil icon above amount total to anything but the original tax.
8) Confirm the vendor bill and notice the manually changed tax value revert back to the original value.

Behavior after bug fix:
Upon completing step 8, the manually changed tax value should stay and not be recomputed.

opw-4854669




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

Removing an attachment (coming from a mail template) in the mail
composer wrongly removes it from the template.

- Edit the "Sales: Send Quotation" mail template, add it an attachment
- Go to a draft quotation
- Click on "Send", it will open the mail composer which will use the template. You should see the file you added on the template.
- Now, remove that file from the composer. For instance, for this client you don't want to send it, or you want to replace it or whatever.
- The mail attachment has also been deleted from the template, not only from the current mail.
- Note that you don't need to send it, just deleting it in the composer is enough to have it removed on the template.

Many refactoring were made in `mail` between Odoo 17 and 18, breaking this flow.

Another solution would be to change that in JS side, somehow managing to call `delete()` and not `remove()` in `/mail/[..]/attachment_model.js`. The caller is in `unlink()` in `/mail/[..]/attachment_upload_service.js` which is itself called by `onFileRemove()` from
`/mail/[..]/mail_composer_attachment_list.js`.

That would've kept using the same attachment record as the one in the template without removing it from the template when it's removed from the composer.

The python solution seems more straightforward and since it's creating new attachment no other bugs should arise.

Finally, note that "ghost" attachment are garbage collected through the `_gc_lost_attachments()` autovacuum method, looking for attachment having `res_id=0` and `mail.compose.message` as model.

task-4748058

Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises

    ValueError: bad delimiter or lineterminator value

This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:

> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.

so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.

Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.

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

Forward-Port-Of: odoo/enterprise#109081

This reverts commit 2b2d73df420baee4fec1c51c28250666d80b48b8.

## How to reproduce (in runbot):
- Create Product P
- Create Delivery transfer from 'WH/Stock/Shelf 1'
- Open Forecast report:
=> RuntimeError: dictionary changed size during iteration

The original fix will be redone in another commit.

---

## Traceback:
```
  File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 21, in get_report_values
    'docs': self._get_report_data(product_ids=docids),
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 128, in _get_report_data
    res['lines'] = self._get_report_lines(product_template_ids, product_ids, wh_location_ids, wh_stock_location)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/addons/stock/report/stock_forecasted.py", line 359, in _get_report_lines
    for product_id, location_id in currents:
RuntimeError: dictionary changed size during iteration
```

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

Forward-Port-Of: odoo/odoo#251768

…lues landed cost sbc

**Problem:**
account move line created from a landed cost on a  subcontracted 
receipt do not take into account already out quantity.

**Steps to reproduce:**
- create a tracked product with avco auto category
- create a subcontracted bom for this product with no comp
- create and confirm a PO for 10 unit of this product 
with the same partner as the subcontractor of the bom
- validate the receipt
- create and validate a delivery for 4 unit of your product
- navigate to inventory/operations/adjustments/landed costs
- create a new landed cost
- select the receipt from the PO
- add a landed cost of 10$ and validate
- select the valuation smart button
- a 6$ svl was created (which is correct because 6 out 10 products
of the receipt are still in stock)
- click on the book widget to open the account move view

**Current behavior:**
Only two account move lines were created both with a value 
of 10
One crediting sotck interim received
On debiting stock valuation

**Expected behavior:**
4 extra account move lines (all with a value of 4) should have been 
created to compensate the out quantity like it is the case for 
non subcontracted product.
One debiting stock interim delivered
One crediting stock valuation 
One debiting expenses
One crediting stock interim delivered

**Cause of the issue:**
_is_in() will return false for the move of a subcontracted receipt
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185
This is wanted and happens because _should_be_valued()
will return true when called on the subcontracted location
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_account/models/stock_move.py#L129

As a consequence, qty_out stays 0
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L185-L186
and we do not append the values for the extra amls 
inside _create_account_move_line()
https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/stock_landed_costs/models/stock_landed_cost.py#L465-L466

**fix:**
if we make sure the the adjustment line is linked to the move 
of the MO instead of the move of the receipt, this problem does 
not happen because _is_in() returns true for the move of the MO. 
Also in this case we don't need _get_stock_valuation_layer_ids()
which was introduced by this PR https://github.com/odoo/odoo/pull/166107
to solve the same issue. 
That is because the move used in button_validate is the move linked
to the adjustment line, which will, after this fix, be the one of 
the MO, so we can directly take its stock valuation layers.

opw-5723126

Issue Before This Commit:
=======================
In the `batch transfer report`, move lines are ordered by the `picking's batch sequence` (picking_id.batch_sequence). When operators use the document to pick items, they have to scan through the report to find all lines for the same product. As a result, operators `lose time scanning the document` and `risk of missing lines`.

Steps to Reproduce:
=======================
- Install the `stock_picking_batch` module.
- Create `multiple deliveries` with several `common products`.
- Add these deliveries to a batch transfer and print the batch transfer report.
- Observe that product lines are ordered by location and then by picking.

Cause of the issue:
=======================
The batch transfer report currently sorts move lines by picking in the report `(picking_id.batch_sequence)`. When the same product exists in another picking, This causes lines for the same product to be scattered across the report instead of being grouped together, causing the product to appear in multiple places in the document.

After This Commit:
=======================
In the report, move line sorting by picking (picking_id.batch_sequence) has been replaced with sorting by product `(product_id.id)`. Move lines are now ordered by product, so similar products are displayed together in the document. This helps operators find products more quickly, reduces scanning effort, and makes the process more reliable.

TaskID-5379367

# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt

# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.

# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12

# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />

There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
    get phoneText() {
        return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
    }
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />

**Drawback:**
- The inconsistency between how the number is stored and how we view it.

# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+    get direction() {
+        return localization.direction;
+    }
```

**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
                <t t-if="props.data.company.phone">
-                    <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                    <t t-if="direction == 'ltr'">
+                        <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                   </t>
+                    <t t-elif="direction == 'rtl'">
+                       <div><t t-esc="props.data.company.phone" />Tel:</div>
                    </t>
                </t>
```

**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability


opw-5881503

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

**Issue**:
Validating a receipt with intercompany move, can lead to access right issue

**Steps to reproduce**:
- Create two different companies A and B
- Create an inter company route with two 'pull from' action defined:
	- One from Virtual Locations/Inter-company transit to A/Stock with operation type A: Receipts
	- One from B/stock to Virtual Locations/Inter-company transit with operation type B: Delivery Orders
- Create a product P accessible from both company
- Create a MO (while both company activated with company A selected) for a product that consumes 1 unit P as component and confirm it
- Go to the receipt while only company B activated
- Select a quantity of 1 and validate it 
-> A traceback is displayed

**Cause**:
While confirming the receipt (calling `button_validate`): https://github.com/odoo/odoo/blob/e9a8b81d4a972a57a8f46377864874190b04af2c/addons/stock/models/stock_picking.py#L1403 this will eventually runs:
https://github.com/odoo/odoo/blob/e9a8b81d4a972a57a8f46377864874190b04af2c/addons/stock/models/stock_move.py#L2091 https://github.com/odoo/odoo/blob/e9a8b81d4a972a57a8f46377864874190b04af2c/addons/stock/models/stock_move.py#L2036-L2039 Since self.move_dest_ids belongs to another company, accessing the associated location_id triggers an AccessError.

opw-5177369

Problem:
In Safari, pressing space sometimes can move the selection unexpectedly.

Cause:
`node.normalize()` in Safari doesn't work in the same way as in Chrome or Firefox.
When the selection is on a text node adjacent to another and we normalize, the two text nodes will be merged but the selection will move to the parent element instead of the correct position inside the new merged text node.

Example:
before normalize: `<span>"ab""c[]d"</span>`
after normalize:  `<span>"ab[]cd"</span>` (expected) vs `<span[]>"abcd"</span>` (Safari)

Solution:
Instead of using `normalize`, we manually merge adjacent text nodes and properly restore the selection by computing the absolute offset before the merge and restoring it to the correct position in the merged text node.

Steps to reproduce:
- Have two adjacent text nodes inside a `span`.
- Put the selection on the second text node in the middle.
- Press space.
- The selection will move to the end of the text.

opw-5956709

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

*: website_helpdesk_knowledge

**Steps to reproduce:**
- Install Helpdesk/Knowledge/Website apps
- Go to Knowledge
- Set up a Knowledge workspace root article with some child articles to it
- Go to Helpdesk > Configuration > Helpdesk Teams
- Open a Helpdesk team, and go to its Help Center config
- Check Knowledge and set a non-root article as main Article
- Go to Website > Help

First issue (non-root main article):
- Type a word which is present in both the article and one of its child articles
- Only the given article match the word
- If you use the root article it will match in any descendant

Second issue (in every case):
- Type a word in the search bar
- Wait for the dropdown to appear
- Click elsewhere, dropdown is properly hidden
- Try to change the search > Traceback

**Issue:**
The domain used to find the articles to match the search uses the current id as the `root_article_id`:
`['|', ('id', '=', team_article.id), ('root_article_id', '=', team_article.id)],` which was previously working in every case as it was not possible to set a non-root article in the team setting.

This was later changed to allow any article as the default website page. As a result, when a non-root article is selected, the search domain only applies to that specific article and no longer includes its descendants.

The other issue is related to the added boostrap attribute `data-bs-toggle="dropdown"` which is not properly reset when the dropdown is removed, and triggers the creation of an empty dropdown.

**Fix:**
Doesn't seem easy to fix to allow the search on all the descendants of the given article as we can't use the article `root_article_id` and filter out the unwanted results in a clean way (and it doesn't seem doable with a direct domain). Instead clarify the situation in the help of the article.

Also manually reset the attribute for `_onFocusOut`.

related: https://github.com/odoo/enterprise/commit/ed971d4d02624f8b864ab6c37c6e7db8ba3dfe11

opw-5258607