Currently, modifying a loaded order (e.g., changing product quantity) does not save the changes, and the old order without modifications is shown on the ticket screen.

### **Steps to Reproduce:**
1) Install the POS Restaurant app with demo data.
2) Open a Restaurant Session.
3) Click on 'Register' to create a Direct Sale.
4) Add a product (e.g., Water with Qty 2) and a customer (e.g., 'Billy Fox'). 
5) Click on 'Orders' from the navbar and load the recently created order. 
6) Update the quantity of Water from 2 to 5 and click on 'Orders' again.

### **Error:**
The quantity of Water is not updated, the order line still shows a quantity of 2.

Ref video: https://drive.google.com/file/d/1XR5W5Klyyll3KujirKb3UuAELjMcA7yD/view

### **Root Cause:**
Clicking on 'Orders' calls `syncAllOrders` (see [1]), which is responsible for updating the orders. However, `this.getPendingOrder()` returns null in this scenario, causing the orders array to be empty and the function to return early without syncing.

### **Fix:**
Override `updateSelectedOrderline` in `OrderSummary`. This method is
invoked whenever the Numpad modifies an orderline. By calling
`addPendingOrder` within this method, we ensure that Numpad modifications
are correctly registered. This allows `syncAllOrders` to properly sync
the updated order with the server when navigating away.

[1]- https://github.com/odoo/odoo/blob/7fd5f90fe8fce4de49ec10c683f92e7a3557981a/addons/point_of_sale/static/src/app/services/pos_store.js#L1485-L1512

opw-5405402

Forward-Port-Of: odoo/odoo#240366

In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior.

The dashboard query for payments to check was executed with the default `bypass_access=False`, causing record rules to be applied. This introduced extra joins (e.g. on `res_company`) and resulted in ambiguous column errors during aggregation.

```py
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 414, in _get_journal_dashboard_data_batched
    self._fill_sale_purchase_dashboard_data(dashboard_data)
   File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 600, in _fill_sale_purchase_dashboard_data
    self.env.cr.execute(sql)
   File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
    self._obj.execute(query, params)
 psycopg2.errors.AmbiguousColumn: column reference "currency_id" is ambiguous
LINE 1: SELECT journal_id, company_id, currency_id AS currency, invo...
                                       ^
```

Set `bypass_access=True` to match the original `_where_calc` behavior and avoid unnecessary joins.

opw-5951694
upg-3902613

[^1]: https://github.com/odoo/odoo/commit/6f95152b00df75f503f445e3b77b891b5f83c055





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

Forward-Port-Of: odoo/odoo#250003

## Short functional explanation of the error
When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B.

## Reproduction Steps
1. Create a second company to your database. Let's call these companies Company A and Company B.
2. Select Company A as your main company, but make sure Company B is also selected.
3. Create an Employee A.
4. Select Company B as tour main company; but make sure Company A is also selected.
5. Create an Employee B who has A as manager.
6. Create Employee C who has B as manager.
7. With a user only having access to Company B, log in and try to access Employee C's page.

### Expected behavior
Employee's C page loads correctly.

### Unexpected behavior
An access error occurs.

## Origin of the issue
A sudo() was missing.
__
opw-5910036





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

Forward-Port-Of: odoo/odoo#247817

Steps to reproduce
-----
- Enable locations & by products
- Create 4 locations
	- View A of type view (parent: Stock)
	- View B of type view (parent: Stock)
	- Storage A of type internal location (parent: View A)
	- Storage B of type internal location (parent: View B)
- Create a "Manufacture to A" route
	- Rule 1: Manufacture, Stock -> Stock
	- Rule 2: Push To, Internal Transfer, Stock -> View A
- Create a "By Products to B" route
	- Rule 1: Push To, Internal Transfer, Stock -> View B
- Create a "Bonus" product with route "By Products to B"
- Create a "Finished" product with route "Manufacture to A"
	- BoM with "Bonus" as by product
- Create a MO for Finished, and produce it
- Open the linked transfers' list view
- Open the "Bonus" transfer

> "Destination Location" states View B

- Open the line's details (hamburger button)

> "Store To" states View A/Storage A

Cause
-----
When retrieving the location in

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282

we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260

This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371

which might not be a child of the location.

Solution
-----
By removing the context key, locations get populated as such

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330

This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location.

-----
Ticket:
opw-5359945

Forward-Port-Of: odoo/odoo#249708
Forward-Port-Of: odoo/odoo#247403

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty the Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record
  is not a field service task.
* Field service tasks should always keep the sale order linked so materials can
  still be added to the existing sale order, even when the task is non-billable
  (i.e., no sale order line is linked). This logic is handled by the compute
  override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935
[2]:
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487

opw-5215989

Forward-Port-Of: odoo/odoo#249574
Forward-Port-Of: odoo/odoo#241446

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

Forward-Port-Of: odoo/enterprise#107990
Forward-Port-Of: odoo/enterprise#103487

**Issue**:
The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled.

**Steps to reproduce**:
- Create a rental product tracked in stock with a quantity of 5
- Enable "continue selling" and "show available quantity below 10"
- Go to the ecommerce page of this product
- Rent 3 units for a given period, confirm and pay
- Return to the ecommerce product page
-> Whatever the selected renting period, the displayed quantity is always 2

**Cause**:
The website displays `free_qty`:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15

`free_qty` is computed in:
https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36

which leads to:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10

and ultimately relies on:
https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213

This computation does not take the selected renting period into account.

There is a period-aware computation here:
https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1

but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled).

opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task)

Forward-Port-Of: odoo/enterprise#104686
Forward-Port-Of: odoo/enterprise#103333

With an `l10n_it` company:
- Create an invoice in a foreign currency and export the XML.

In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency.
`ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document:
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b

> L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che
> “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”.
> Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>`
> deve essere obbligatoriamente “EUR”.

> Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that
> “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.”
> Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>`
> field must mandatorily be “EUR”.

As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field
(assuming the company currency is always EUR for `l10n_it`).

Ticket [link](https://www.odoo.com/odoo/project.task/5913088)
opw-5913088

Forward-Port-Of: odoo/odoo#249272
Forward-Port-Of: odoo/odoo#247537

Versions
--------
- 19.0+

Steps
-----
1. Enable click and collect
2. Add a product with tracked inventory
3. Set the quantity on hand
4. Uncheck "Sell when Out-of-stock"
5. Try to add to cart more than the quantity on hand on the product page
    - note that you are only allowed to add up to the quantity on hand
6. Try to add to cart more than the quantity on hand from the shop page by hovering over the product and clicking the cart icon
    - note that you can add to cart more than the quantity on hand
7. Try to go to the cart page and adjust the quantity of the product
    - note that it is reset to the quantity on hand and you're prevented from exceeding it

Issue
-----
You shouldn't be able to add to cart more than the quantity on hand of a product when you have "Sell when Out-of-stock" disabled. Especially since you can't do that from the product or cart page, and adjusting the extra quantity from the cart page leads it to reset.

Cause
-----
When you enable click and collect, it disables the check for quantity when adding items to cart. This was originally done because otherwise you had no way of adding items to cart in case there was a quantity available for pickup from shop but not available for delivery. This has changed since the introduction of the widget on the product page that allows you to select a store to pickup from in that case.

Solution
--------
Remove the code that disables checking for quantity when adding to cart when click to collect is installed.

opw-5449451

Forward-Port-Of: odoo/odoo#242864

Steps to reproduce
------------------
1. Install `pos_settle_due`
2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc).
3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0
4. Select the invoice(s)
5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom.

-> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method.

Why the issue
-------------
If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created.

That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions.

After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places:
1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation.
2. On the products screen, when using fast payment, that is fast validation.

For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation.

However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation.

The fix
-------
Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation.

Notes
-----
- We keep the methods in `payment_screen` for backward compatibility, they will be removed in master.
- We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so  it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`.

opw-5488587

Forward-Port-Of: odoo/enterprise#105660

Steps to reproduce:
- Have facturae modules installed
- Generate invoice with any amount
- Send to Facturae

Issue:
Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost.

When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)."

According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places.
This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies.

[1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844
Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf)


opw-5927356

Forward-Port-Of: odoo/odoo#249674
Forward-Port-Of: odoo/odoo#248882

A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both after the lock date. Related: PR #222169

When validating a `stock.picking` record, the constraint `_check_backdate_allowed()` can fail on a different `stock.picking` record. This is confusing for the end user and makes finding the erroneous `stock.picking` difficult.

## Steps to reproduce.
**setup**:
1. install stock, sale, purchase. Use the demo data.
2. Navigate to Inventory > Configuration > Warehouse and click into the Warehouse for the active company.
3. Select the Routes smart button, then select the Buy route. Ensure that the "Product" option is selected for the Buy route. 
4. Navigate to Inventory > Product > Product.
5. Create a test product that is:
    1. tracked by quantity (General Information tab)
    2. Has a vendor listed (in the Purchases tab)
    3. Uses the "buy" route (in the Inventory tab)
    4. Has a reordering rule for the Buy route (reordering rules smart button)
6. Do not add any stock for this product.

**reproduction**:
1. Navigate to Sale > Orders.
2. Create and confirm a sale order for the configured product, such that more products will need to be created.
3. Navigate into the delivery order for the sale and set its scheduled date to be December 1st.
4. In Accounting > Accounting > lock dates, set all the lock dates to be December 3rd.
5. Navigate back to the sales order, then use the Purchase order smart button to view the purchase order.
7. Use the Deliveries smart button to view the purchase delivery.
8. Validate the delivery - > Validation error thrown

> You cannot modify the scheduled date of this operation because it falls within a locked fiscal period.

**Solution**: add the name of the stock.picking to the error message & only check the lock date when `date_done` is altered, not `scheduled_date`.


[opw-5428179](https://www.odoo.com/odoo/unassigned-tasks/5428179)

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

Forward-Port-Of: odoo/odoo#247474

### Steps to reproduce the bug:
- Install mrp
- Go to manufacturing app
- Go to products -> bills of materials
- Create a new bill of material for a product
- Go to the operations tab
- No 'copy existing operations' button appears if at least one operation
 is already created

### The problem:
In version 19.0, the "Copy Existing Operations" button is missing from
the BoM operations tab when no operations have been defined yet for the
current BoM. While this feature was fully functional in version 18.4,
it became inaccessible in 19.0 to users due to a UI reorganization
introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy
Existing Operations" button. Currently, users are forced to manually
create at least one operation before they can see the option to copy
from other BoMs.

### The reason to introduce the fix:
The ability to copy operations is useful also when starting with an
empty BoM if operations in other BoM's have been already created. Since
this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4,
this PR backports that changes to 19.0 to restore feature parity and
improve the user experience.

opw-5906667

Forward-Port-Of: odoo/odoo#248225

An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]).

This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues.

The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them.

This reverts the whole accent sanitization saga:

- Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d.
- Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4.

This also removes the unused frozendict import to make "Check Style" happy.

opw-5915515

[1] https://github.com/odoo/enterprise/pull/95207
[2] https://github.com/odoo/enterprise/pull/107960
[3] https://github.com/odoo/enterprise/pull/96043
[4] https://github.com/odoo/enterprise/pull/106557
[5] https://github.com/odoo/enterprise/pull/107677

Closes odoo/enterprise#107960

Forward-Port-Of: odoo/enterprise#108425
Forward-Port-Of: odoo/enterprise#108189

*: account,sale,stock_delivery

Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access.

Here is a list of examples (each performed with every other access rights disabled):
- With a `stock user`, open the delivery list or form view
 #### > Access error
- With a `purchase user` create and confirm a PO > Upload Bill
####  > the Bill will be created but an access error will prevent the draft bill from opening.
- With a `sale user` create and confrim an SO > Create invoice
####  > the invoice will be created but an access error will prevent the draft invoice from opening.

## Solutions:

### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user:

1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model.

Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view.

#### Note for master:

IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here:
https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52

2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53

### Use case: Open a `stock.picking` views as basic stock user:

3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496

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

opw-5461135
opw-5417749

Forward-Port-Of: odoo/odoo#247531

*: account_asset, sale_lazada

Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access.

Here is a list of examples (each performed with every other access rights disabled):
- With a `stock user`, open the delivery list or form view
 #### > Access error
- With a `purchase user` create and confirm a PO > Upload Bill
####  > the Bill will be created but an access error will prevent the draft bill from opening.
- With a `sale user` create and confrim an SO > Create invoice
####  > the invoice will be created but an access error will prevent the draft invoice from opening.

## Solutions:

### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user:

1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model.

Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view.

#### Note for master:

IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here:
https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52

2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53

### Use case: Open a `stock.picking` views as basic stock user:

3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view:
https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here:
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496

opw-5461135
opw-5417749

Forward-Port-Of: odoo/enterprise#106694