In odoo/enterprise#106192, we have modified the function userPermissionViewOnly that was preventing the user from editing document he cannot: we have removed the condition preventing user to edit protected document (mainly folder at the company root). That was an error as even if the user has "edit" access (which is ensured in that method), the document can still be protected and the form to edit it should be in readonly then. We ensure here that the form in the details panel is in readonly in that case.

How to reproduce:
- log as demo and go to Document
- Click on Inbox folder
- Open details panel
- Change for example the contact of the document
You get an error while you shouldn't be able to edit it (as the folder is protected).

Technical note: we re-add the condition in the method userPermissionViewOnly:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY")
that we slightly modify to limit the protected document to folder only:
(!this.documentService.userIsDocumentManager
&& this.record.data?.user_folder_id === "COMPANY"
&& this.record.data?.type === "folder")

Task-5881531

Forward-Port-Of: odoo/enterprise#116709

Steps to reproduce
1. Go to Accounting → Configuration → Analytic Distribution Models
2. Create a new model, name it, and in the distribution column pick an analytic account
3. Click outside the row and reload the page

Issue
The newly created record vanishes because `web_save` received
`analytic_distribution: false`. The single click that closes the popover
also triggers the editable list's `leaveEditMode`, which calls
`record.save()`. That save runs before the widget has flushed the user's
pick into `record.data`, so the write goes out with stale/empty data.

This became reliably reproducible after [37d78a47bb20],
which moved the list renderer's outside-click listener from `document`
(bubble) to `window` (capture). Because the list is mounted before the
widget, its capture-phase listener now fires first: `leaveEditMode` →
`record.save()` is already in flight by the time the widget's own
window click handler runs, so the widget's commit loses the race.

Solution
`record.save()` awaits `_askChanges()` before writing:
https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/web/static/src/model/relational_model/record.js#L268-L271
`_askChanges()` triggers `NEED_LOCAL_CHANGES` on the model bus and
awaits any proms handlers push onto it:
https://github.com/odoo/odoo/blob/cdf8aaec82ee387c8f29b8327efbc95fd17e2cb8/addons/web/static/src/model/relational_model/relational_model.js#L249-L253
This is the framework's standard hook for widgets that hold uncommitted
local state; `ace_field` and `domain_field` already use it.

Subscribe the analytic distribution widget to the same event and, when
the dropdown is open, push a `commitChanges()` prom that awaits the
existing `save()`. Because `record.save()` awaits these proms before
running `_save`, the widget's pending distribution is guaranteed to be
on `record.data` by the time the write payload is built, regardless of
click-listener ordering.

opw-6106309

Forward-Port-Of: odoo/odoo#260421

### Issue:
When changing the delivery date (used as the Hungarian exchange rate date), some journal lines could be recomputed incorrectly, leading to unbalanced entries

### Cause:
`expected_currency_rate` was recomputed when `delivery_date` changed, but the new value was never automatically applied

In addition, after https://github.com/odoo/odoo/pull/225407, `_sync_tax_lines` partially updated the lines:
https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L3029-L3031
https://github.com/odoo/odoo/blob/f5501e5c8dcf60444077912db4c87e7a3f2654a6/addons/account/models/account_move.py#L1633-L1637
These methods reapply the previous tax rate, causing base and tax lines to be updated inconsistently
As a result, when the base amount increases, the tax amount decreases, and vice versa

### Steps to reproduce:
- Install `l10n_hu_edi` and `accountant` with demo data, then switch to the `HU company`
- Go to Currencies → USD and add two rates:
April 5: HUF per Unit = 100
April 6: HUF per Unit = 150
- Create an Invoice: (Any customer, Currency: USD, Line: Price = 1000, Tax = 27%)
- Open the Journal Items and duplicate the browser tab for comparison
- In the duplicated tab, change the Delivery Date to April 5 and save
- Change the Delivery Date back to today and compare both tabs

### Before the fix:
The values differ between both tabs because the tax lines keeps the old exchange rate

opw-5801126

Forward-Port-Of: odoo/odoo#263694
Forward-Port-Of: odoo/odoo#258310

__
## Short functional explanation of the error
When creating a Purchase Order. We add a line containing a product
that has an analytic distribution. After setting a project on this PO,
when we add another line containing the same product, the analytic
distribution of the product isn't added anymore, only leaving it with
the analytic distribution of the project.

## Reproduction Steps
1. Go to settings and enable Analytic Accounting.
2. Go to Accounting > Configuration > Analytic Distribution model.
Create a model with a product (prd) you remember, and add an analytic
distribution (ad).
3. Go to Project. On a given project (p), select the Hamburger menu and
click Settings. Then, in the Settings tab, under Analytic, make sure
the Project field is filled.
4. Create a new Purchase Order. Select a vendor and add a line with the
product (prd). On the top right of the Form, click on the view button
and select Analytic Distribution to show it on the form.
There, we should see the product (prd) with its corresponding Analytic
Distribution (ad) on the form.
5. Click on the Other Information tab and select the project (p).
Click on the Product tab. There, under Analytic Distribution field,
you should see (ad) and the Analytic Distribution of the project (p).
6. Click on save and add another line with the exact same product.


### Expected behavior
Under Analytic Distribution, we should see (ad) and the Analytic
Distribution of the project (p), as for the first order line

### Unexpected behavior
Under Analytic Distribution, we only see the Analytic  Distribution of
 the project (p).


## Origin of the issue
When we add another line, we trigger the compute method of the
Analytic Distribution. However, due to this piece of code:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/project_purchase/models/purchase_order_line.py#L14
when we create a new order line, we never compute its analytic
distribution: `self` will contain only `project_lines`, and
`empty_project_lines` is empty as well. Therefore, we call the super
 method with nothing, so when we get in the
super method:
https://github.com/odoo/odoo/blob/eed303b9926062eb71be6cf8dc95165efc413ed8/addons/purchase/models/purchase_order_line.py#L249-L259
we never compute the analytic distribution of the newly created line.

This piece of code was added in this commit:
https://github.com/odoo/odoo/commit/c1ea8446259bd3338c004e88d48ad77ded7ef2ae
to fix the issue that when a user enters manually an analytic
distribution, this entry will be lost when triggering the compute of
the analytic distribution.

However, due to the agency of the code, we cannot prevent losing *both*
manually added analytic distributions and product analytic distribution.
After consulting the product owner, we concluded that there was no perfect
solution in this case, but we'd rather keep the product analytic 
distribution, as it is much harder to add it again after its removal. 
Therefore, this commit reverts the previously mentioned commit, while
keeping the refactor it introduced.
__
opw-6063418

Forward-Port-Of: odoo/odoo#257558

## The Problem
During the initialization of `stock_account`, the logic creating `product.value` instances triggered cache misses on `product.product`, accessing fields (`company_id` and `standard_price`) inside `_create_product_value`, and field `uom_id` inside `_run_fifo_get_stack`. Due to prefetching, this loaded all product data into memory, causing significant memory usage on large databases.

## The Solution
Disabled prefetching in the full flow.

Didn't go with fetching only the needed fields instead of disabling for two main reasons:
- Field `standard_price` accessed in the loop is company dependent, so it needs to be fetched inside, which would be a bit verbose.
- Fetching `company_id` outside the loop, `standard_price` inside the loop, and `uom_id` which is accessed down the stack in the `.create` call on `product.value` won't be an explicit/robust solution for the long term.

---

## Benchmarks
*Tested on a SaaS database with 500k products:*

| | Before | After | Note |
| :--- | :--- | :--- |  :--- |
| **Memory** | 3.6GB | 1.6GB | **-55%** (fits in memory limit) |
| **Time** | 10m | 11m | **+10%** (acceptable tradeoff) |

**OPW-6173153**

Forward-Port-Of: odoo/odoo#262702

**Problem:**
On a Belgian company with the UI set to French (or any non English language), the gross line never appears in the salary configurator sidebar when opening an offer.

**Steps to reproduce:**
1. Create a Belgian company.
2. Install French and set the admin user to French.
3. Go to an applicant (e.g Laurie Poiret), create a salary offer, save.
4. Open the offer link (salary configurator).

**Cause:**
The base `_get_compute_results` uses the translated `category_id.name` ("Salaire mensuel" in french) as the dictionary key when writing entries into `resume_lines_mapped`. The payroll override function `_get_period_name`, which for monthly schedules returned the hard coded english string `"Monthly Salary"` instead of the translated category name. This caused a key mismatch: the gross line was stored under the translated key, while the override rebuilt `resume_categories` with the english key so when the template iterates over categories and looks up `lines[category]`, the whole "Monthly Salary" bucket was invisible in every non english language.

**Solution:**
We should now return the `category_id.name` directly (the translated name coming from the record itself). This keeps all keys consistent between `resume_categories` and `resume_lines_mapped` regardless of the language used.

also because in https://github.com/odoo/enterprise/blob/1845042ff388593c4cdf547d47c018f42bd02c7c/l10n_be_hr_contract_salary/controllers/main.py#L450
We use `resume = result['resume_lines_mapped']['Monthly Salary']`
We need to re-design this by using the actual translated names, and building `result` keys based on the language selected (the same should be applied for "Yearly benefits").

opw-6009711

---

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

Forward-Port-Of: odoo/enterprise#116657
Forward-Port-Of: odoo/enterprise#110676

Currently, an error occurs when a user attempts to mark a payslip as paid.

**Steps to Reproduce:**

 - Install the `hr_payroll` module without demo data.
 - Go to `Payslips` and click on `New Off-cycle`.
 - Create a record > `Compute` > `Validate`, and Pay.
 - In the wizard, enable `Include Unpaid` and select `CSV` mode.
 - Click `Mark as Paid`.

**Error:**
`UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value`

The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. 
When the wizard is created from here [1], the default unpaid payslips are empty. In this case, 
the system assigns an empty set of payslips to process [2].and the rows variable is not 
defined because there are no payslips to work on, which raises the error [3].

This commit ensures that when the wizard is created, the matched unpaid payslips are passed to 
the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, 
similar to [4]. The unpaid payslips cannot be empty, as they always include the currently 
processed payslip.
Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit 
ensures that the rows are created at the end from grouped payments.

[1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809

[2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56

[3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97

[4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288

sentry-7436885639

Forward-Port-Of: odoo/enterprise#115090

Issue
-----
Putting a max weight on a package type causes getting a rate with Sendcloud to fail.

Steps to reproduce
-----
- Setup Mondial Relay using Sendcloud
- Set a default package type with max weight 2kg
- Create a product with a 500g weight
- Create a SO with the product
- Add delivery
	- Sendcloud Mondial Relay
	- Get rate

> Impossible to get a rate

Cause
-----
When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order.

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81

However, when making the rate call, we use the value returned by `_split_shipping`

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91

which is equal to the maximum weight of the package. This is blocking in some cases, like if
- the real weight is 750g
- the package max is 2kg
- Sendcloud returns a shipping method for [500g;1kg]

Asking a rate for this method & a 2kg package will fail (rightfully so).

Solution
-----
The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one.

Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight.

-----
Ticket:
opw-5947199

Forward-Port-Of: odoo/enterprise#116415
Forward-Port-Of: odoo/enterprise#108315

### Steps to reproduce:

- In the settings Enable: "Multi-Steps Routes"
- Unarchive the MTO route
- Create a storable product with MTO enabled and a set vendor
- Create and confirm two sale orders for 1 unit of that product
- Go to the purchase order view, select both PO > Actions > Merge RFQs
#### > The un-cancelled Purchase order is  only linked to one of the 2 SOs

### Cause of the issue:

The sale orders linked to a PO in this flow are linked through the stock references:
https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase/models/purchase_order.py#L60-L61 https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase_stock/models/purchase_order.py#L14-L15 However, the references of the PO merged to the present one are not merged as well.

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

Forward-Port-Of: odoo/odoo#263371
Forward-Port-Of: odoo/odoo#261578

**Steps to reproduce:**

- Download the German language
- Set the restaurant to QR + Ordering
- Set the Service at Table, pay after each order
- Set the language to German
- Go to the Self and order something while the language is German
- Chose table 12
- Go to the kitchen display
- The title is truncated, meaning we can't see the table number

**Why the fix:**

If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in 
ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display.

We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number.

Before:
<img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" />

Afer:
<img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" />


opw-6096111

Forward-Port-Of: odoo/enterprise#114859

### Steps to reproduce:

- In the settings enable "Packages"
- Create a storable product A and put 1 unit in a package P in stock
- Inventory > Products > Packages > open your package P
- Set a parent package PP as container
- Inventory > Operations > Adjustments > Physical Inventory
- Select you product line for A > Request a count (from the control panel button)
- Enable Show Expected Quantity and confirm
- Go to the barcode app > Count Inventory (1)
- scan your parent package PP
#### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false'

### Cause of the issue:

When the Package scan is processed, we loop over all quants related to it:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617
And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423
This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627

Fix:

We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133
Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom:
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54

opw-5864591

Forward-Port-Of: odoo/enterprise#116715

**Steps to reproduce:**

Problem A)
- create a storable product avco perpetual
- add 2 unit in stock and set a cost of 10
- set the invoicing policy as "delivered quantities"
- create and confirm a SO for 2 quantities
- validate the delivery
- click on "Create Invoice" and confirm the invoice
- from the delivery, create and validate a return for 1 unit.
- from the product form, change the cost to 15
- from the sale order, click on "Create Invoice"
- confirm the Credit Note

Problem B)
- create a storable product with fifo perpetual
- confirm a PO for 1 unit at 10 and validate receive
- confirm a PO for 1 unit at 20 and validate receive
- confirm a PO for 1 unit at 60 and validate receive
- create a SO for 3 unit
- deliver 1 unit with backorder
- deliver another unit with backorder
- deliver the last unit
- create and confirm invoice
- return the second delivery
- from the invoice click on 'credit note' and validate
the credit note with a quantity of 1

**Current behavior:**

Problem A)
the cogs is 25

Problem B)
the cogs is 30

**Expected behavior:**

Problem A)
it should be 10

Problem B)
the cogs should be 20 cause the move returned
had a value of 20

**Cause of the issue:**
Inside \_get\_cogs_value(), if there is an original invoice
linked to the credit note we take the unit_price from this invoice.
But, if the credit note is not created from the invoice (via the
Credit Note button) but via the sale order (via create invoices),
the account\_move has no reverse\_entry_id so we won't
use the price_unit from the original line.
https://github.com/odoo/odoo/blob/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/stock_account/models/account_move_line.py#L56-L58
So basically what we do for now is:
If the credit note was created from invoice we use
the unit price from original invoice in all cases.
If the credit note was created from sale order we
use get\_price\_unit in all cases (which will work for
fifo because we'll use the value of the returned
move but fail for avco if the standard price has
changed cause we use the standard price)
https://github.com/odoo/odoo/blob/dccd2256660b1e211707b740074f5fbba95ae149/addons/stock_account/models/stock_move.py#L261-L265

**Fix:**
Regardless of how the credit note is created, if
it's fifo we use get\_price\_unit to adapt to the value
of the moves, if not we use the unit_price from
original invoice

opw-6097090

Forward-Port-Of: odoo/odoo#259630

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Forward-Port-Of: odoo/odoo#263917
Forward-Port-Of: odoo/odoo#256693

FIX] purchase_stock: handle missing seller during PO line update (min_qty)
**Steps to Reproduce:**

- Install Sale, Inventory, Manufacturing, and Purchase.
- Enable MTO, Units of Measure, and Routes.
- Create a product:
      Set a vendor price with min_qty = 1.0.
      Enable MTO route.
     Add a BoM with a component product.
    Set quantity to 0.1 (less than vendor min_qty).
- Create a Sale Order with the same product added twice.
- Confirm the Sale Order.

**Issue:**
During procurement:

- First procurement correctly fetches the supplier.
- On PO line update (_update_purchase_order_line), seller is recomputed.
  Due to min_qty filtering, no seller is returned when quantity is low.
  This results in: Missing seller, Missing product_uom, Invalid price
  computation, And finally causes a crash when confirming the Purchase Order,
  in _get_stock_move_price_unit: ZeroDivisionErroR

Root Cause:

- _select_seller filters suppliers using min_qty.
 During merge/update flow, recomputed quantity may not satisfy min_qty.
 Existing valid supplier (from initial procurement) is ignored.
 No fallback handling in _update_purchase_order_line.

**Solution:**

- Add fallback logic when _select_seller returns no result: Use
  _prepare_sellers() to fetch a valid supplier ignoring min_qty.
- Ensure a supplier is always available for: UoM resolution, Price computation
   Prevents crash and ensures consistent PO line updates.

**Result:**

- No traceback when quantity < vendor min_qty
  Supplier, UoM, and price are properly set

**OPW-6106487**

Forward-Port-Of: odoo/odoo#263699
Forward-Port-Of: odoo/odoo#259894

Steps
---------
1. Install Accounting, Sale and Timesheet
2. Create 2 product
    a. Product A - storable - invoiced on Ordered Quantity
    b. Product B - service - create a task on order - invoice on 
    timesheeted
3. Create an SO with 3 product A and 3 product B
4. Add a timesheet line for 1 hour of product A - can be done thanks to 
the button appearing on the SO at confirmation
5. Create Invoice
6. Don't add dates to the wizard and confirm -> Both product appear
7. Add date range that do NOT include the timesheeted lines -> Only the
storable product appear
8. Repeat step 6 -> Only the storable product appear

Problem
---------
During the creation of the invoice, the invoiceable lines would get 
computed dates where provided to the wizard
(`sale.order.line.qty_to_invoice`). When no dates were provided, we
would not manually trigger the invoiceable lines recomputation and were
relying one the data store in cache.

Solution
---------
Force the invoiceable quantity recomputation upon each invoice creation.

opw-6001094

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

Forward-Port-Of: odoo/odoo#261062