## [FIX] Accrual account domain
Since [1], the accrued order wizard can be open from a purchase order line view and from a sale order line view.
The wizard account field uses a domain, and this domain is different if the active model is `purchase.order`. In quoted PR, the domain wasn't adapted to work with `purchase.order.line` as active model.
This PR fixes that.

## [FIX] Correct COGS cost
#### How to reproduce the issue
- Use anglo-saxon config;
- Have a product with a cost;
- Sale this product with its unit price =/= its cost;
- Deliver;
- Create accrual entry for this product => The perpetual valuation lines are not correct, they use the SO lines' price for their debit/credit instead of the product's cost.

#### Example
If we have a product with cost of $100 and sell it for $180

We currently have:
Account			Debit		Credit
Stock Valuation		$ 0.00		$ 180.00
Cost of Goods Sold	$ 180.00	$ 0.00

But we should have:
Account			Debit		Credit
Stock Valuation		$ 0.00		$ 100.00
Cost of Goods Sold	$ 100.00	$ 0.00

## PO line price diff
#### Issue
While generating accrual entries for a PO with billed not received, if the billed price is different than the PO line price, no entries were generated for the price diff account.

#### How to reproduce
1. Create a product using "Standard Price" as its costing method and set a cost for this product and set a price  difference account (on its product category);
2. Create a purchase order for this product and confirm it;
3. Create an invoice for this PO with a different price for the product;
4. Go to Accounting > Review > Billed Not Received;
5. Select the PO and click on "Create Accrual Entries" button => Accrued entries are created but no entries are created for the price difference.

#### Expected behavior
Two more entries must be created: one for the price diff account and one for the stock valuation account.

[1]: https://github.com/odoo/odoo/pull/231510

task-[5349657](https://www.odoo.com/odoo/966/tasks/5349657)

Forward-Port-Of: odoo/odoo#249875
Forward-Port-Of: odoo/odoo#234600

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:

- Enable debug mode (to trigger a traceback rather than a silent error)
- In the settings, enable `Work Orders`
- Create an MO for a product without a BoM
- Add an operation to be performed in a workcenter
- Confirm the MO and open the Shop Floor
- Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display
- Click on `Add component` and add any valid component via the catalog

#### > Traceback: `OwlError: Got duplicate key in t-foreach`

### Cause of the issue:

The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72

Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice:
https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188

However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47

Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected.

In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error.

opw-5417887

Forward-Port-Of: odoo/enterprise#106200

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

Steps to Reproduce:
1. Generate payslips for a batch of employees (e.g., Employee A and
   Employee B).
2. Ensure the last processed payslip (Employee B) has a negative net
   wage or is uncomputed (net wage 0.0).
3. Ensure Employee A has a valid, positive net wage.
4. Open the payslip for Employee A.

Issue:
Employee A displays the warning "The net pay for this payslip is zero
or negative," even though their net wage is positive.

This occurred because the lambda filter used the `slip` variable from
the outer loop scope instead of the iterator, causing the last
record's net wage to determine the warning for the entire batch.
Additionally, uncomputed payslips (which have no lines) default to a
net wage of 0.0, which triggered the warning condition prematurely.

Expected Behavior:
The warning should only appear if the specific payslip being checked
has a negative or zero net wage. Furthermore, the warning should be
suppressed if the payslip lines have not yet been computed.

Additionally, added a test to check the message is not displayed if
we don't have net salary, and appears if the net is indeed negative.

task-5484107

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

After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language: when the backend language and the frontend language are not read in the same direction (RTL / LTR), the frontend language is taken to display the previews (see [f9c77de]). This is the right approach to show the snippets themselves, but the order of the columns should be done according to the backend language, which is the one that gives the instructions for the overall UI.

To reproduce:
- Set the admin's language to arabic
- Clear the cache and refresh your page
- Edit and open the add snippet dialog
- Navigate with Tab => The 1st focused snippet is in the wrong column compared with the rest of the UI.

[9ae02d8]: https://github.com/odoo/odoo/commit/9ae02d80894d4043e49d8e2cad068f8018e6f113
[f9c77de]: https://github.com/odoo/odoo/commit/f9c77de84aa6ea705e5d3f129328fb2199103b9a

task-5109547

Forward-Port-Of: odoo/odoo#228414

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

Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop).

Steps to reproduce the error:
- Install ``hr_work_entry_attendance`` module with demo data
- Activate developer mode
- Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset
  In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract
- Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save
- Open Employee A > Click on Work Entries smart button

Traceback:
```py
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
```

https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52
When ``stop(time_stop)`` is unset in the overtime,
``ot.time_stop`` is False,
causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback.

sentry-7169332615

Forward-Port-Of: odoo/enterprise#103764

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

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#100142

**Steps to reproduce:**
- create a storable avco automated product
- in the purchase tab, select control policy : "on invoice quantitites"
- create and confirm a purchase order for 100 qty at 1 unit price
- on the picking, unhide the description column
- change the description for the move
- go back to the purchase order and change the quantity to 105
- (because we changed the description, the new move created 
with a quantity of 5 is not merged to the existing one of 100 and 
we now have two moves on the picking)
- create and confirm the bill
- validate the picking
- select the valuation smart button

**Current behavior:**
the svl with a quantity of 100 has a total value of 105
the svl with a quantity of 5 has a total value of 105

**Expected behavior:**
the svl with a quantity of 100 should have a value of 100
the svl with a quanitty of 5 shoul have a total value of 5

**Cause of the issue:**
When the picking is validated, action_done is created on the 
two moves. 
In the stock_account override: 
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 105.
- then product_price_update_before_done is called on the two 
moves before creating the svls.
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/stock_account/models/stock_move.py#L352

Inside product_price_update_before_done, for each move, 
we call _get_price_unit.
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/stock_account/models/stock_move.py#L426

For the first move, in the purchase_stock override 
of _get_price_unit : 
- to get the received qty we call _get_qty_received_without_self()
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L50
and because the super method of action_done was already called, 
qty_received of the purchase order line is 105, so _get_qty_received_without_self
will return 5. 
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L108-L113
So received_qty is 5 and later remaining_qty will be 100
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later 
remaining_value will be 105
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L60
Therefore price_unit will be 1.05 (105/100) instead of 1
https://github.com/odoo/odoo/blob/2f00b0085574653ca1a8f734ef91893a4a1c1a7c/addons/purchase_stock/models/stock_move.py#L95

For the second move, the problem is the same and 
the price unit ends up being 21 (105/5)

**fix**
We do not take into account the move(s) for the same product
of the same picking in the remaining value (because svls are not created yet)
so we should not take them into account in the remaining quantity.

the problem is very similar to https://github.com/odoo/odoo/pull/235601
In this other PR it happend because we had multiple move for 
the same product because they were in a batch, and in this PR we 
have the issue because we have multiple move for the same product 
because they didn't merge due to the description difference. 

opw-5429501

Forward-Port-Of: odoo/odoo#247640

Prior to this commit, since DOMPurify v3.1.2 (and more precisely since usage of v3.1.5
in Odoo), the JS sanitization process aggressively removes html attributes with
`-->`, `<style` and `<title` for security reasons (see [1]).

However `html_editor` embedded components use `data-attributes`
(`data-embedded-props` and `data-embedded-state`) to store various kind of data
as a JSON string. Obviously, such JSON strings easily match the DOMPurify regex
and these attributes are therefore removed, which results in an Editor crash.

There are multiple reasons why such values are acceptable as is for the
`html_editor` usage:
- only `HTMLElement` instances are sanitized, never a string, therefore there is
  no `DOMParser` to trick with invalid HTML.
- values in these attributes are always/exclusively parsed as JSON strings, and
  the editor will crash if the value is not a legit JSON.
- values in these attributes are HTML escaped by the python sanitizer when the
  serialized html is sent to the server.
- values in the JSON parsed object are at worst rendered as plain text (never as
  HTML or other parsed formats).
- values in the JSON parsed object are never executed as JS (only serializable
  primitives are stored).

Therefore, the suggested solution is to encode the values during sanitization,
and decode just after, to keep the rest of the codebase simple and explicit.

[1]: https://mizu.re/post/exploring-the-dompurify-library-hunting-for-misconfigurations#dompurify-gt-3.1.2-safe-for-xml

task-5960707

Forward-Port-Of: odoo/odoo#250210

## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.

## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].

## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.

runbot-241028

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix archive the revoked portal user (keeping its previous non-public groups), to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

*Reapply the reverted fix properly to avoid template issues and blocking flows (https://github.com/odoo/odoo/pull/239477 and https://github.com/odoo/odoo/pull/236462)*

opw-4760550