**Steps to reproduce:**
- create a storable product with a positive quantity
a cost of 10 and average perpetual category
- confirm a SO for 1 quantity, validate delivery
- confirm invoice for 1 (COGS should be 10)
- return the delivery and validate
- create a credit note from the invoice for 1 and confirm
(COGS should be 10)
- return the return and validate
- change the standard price to 100
- create an invoice from the SO for 1 and confirm

**Current behavior:**
cogs are 190

**Expected behavior:**
cogs should be 100

**Cause of the issue:**
_get_posted_cogs_value doesn't take into account 
the credit notes (only the account moves with type 
'out_invoice' are taken into account in the sum)
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/sale_stock/models/account_move.py#L185-L186
So in our case the first invoice and the credit 
note don't cancel out each other.

The same goes for _get_cogs_qty (which returns 
the total cogs past + current), in the past cogs 
it doesn't take into account the quantities of the 
credit note.
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/sale_stock/models/account_move.py#L172-L174
So the quantity of the first invoice and the one of the 
credit note don't cancel out each other.

As a result, the return value from _get_cogs_value() 
for the second invoice is : 
price unit = 100 
returned by _get_cogs_price_unit()
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/stock_account/models/account_move_line.py#L68
which returned the standard price because 
the product has an average cost method
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/stock_account/models/stock_move.py#L275-L280

cogs_qty = 2 (instead of 1 if credit was taken into account 
as -1 in the sum)
self._get_posted_cogs_value() = 10 (instead of 0 if credit note 
cogs were taken into account  in the sum as -10)
return value = (100 * 2 -10)/1 = 190
https://github.com/odoo/odoo/blob/0824dc24665de6bfa805d540e756cdcb006edba6/addons/stock_account/models/account_move_line.py#L75
**fix:**
if we take into account the credit note 
the return value will be : 
(100 * 1 - 0)/1 = 100

the mechanism of the already posted cogs value 
is there for cases where we only delivered a part of 
the quantity and then delivered the rest, but in 
the case where we delivered and then returned 
(with credit notes) it shouldn't have an impact. 
Thus the idea to include the credit note so 
that it can cancel out the first invoice

opw-6426111

Forward-Port-Of: odoo/odoo#282893

Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.

| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |

### Why it is not cosmetic

The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:

```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```

whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.

### Evidence

- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
  `Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
  depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
  to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
  XML ID (`account_group_gastos`).

### Notes

Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.

Forward-Port-Of: odoo/odoo#277426

Forward-Port-Of: odoo/odoo#277891

## Description of the issue/feature this PR addresses:

Two related Nilvera e-invoice issues affecting Turkish companies:
- The "Fetch Nilvera PDF" button appeared for every company, not just Turkish ones.
- Sending/fetching e-invoices (or fetching the PDF) as a non-admin Invoicing user raised an
  AccessError, because the company's Nilvera API key field is restricted to System/Settings users
  and several call sites read it without `.sudo()`.

## Current behavior before PR:

- The PDF-fetch button shows on both the list view and form view of `account.move` regardless of
  the company's country.
- An Invoicing-only user (no System/Settings access) gets an AccessError when sending/fetching
  e-invoices or fetching the PDF, because `_get_nilvera_client` reads
  `company.l10n_tr_nilvera_api_key` without `.sudo()`.

## Desired behavior after PR is merged:

- Both buttons are only visible for Turkish companies (the list-view button has no bound record, so
  its gate is driven by a new `l10n_tr` session_info/JS context injection instead of a direct field
  reference).
- Invoicing users can send/fetch e-invoices and fetch the PDF without hitting an AccessError.

## Things to add on forward-port

The `.sudo()` fix lives inside `_get_nilvera_client` itself (`l10n_tr_nilvera/lib/nilvera_client.py`),
so every caller that goes through it is already fixed automatically once this diff forward-ports.
Only call sites that read `company.l10n_tr_nilvera_api_key` **directly**, bypassing
`_get_nilvera_client`, still need their own `.sudo()`:

### 19.4
- [ ] Fix e-Dispatch/e-Receipt fetch gate-check access error (direct read of the API-key field,
      sudo it the same way as `_l10n_tr_nilvera_company_get_documents` in this PR)

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

Forward-Port-Of: odoo/odoo#274312

Onsite events created from the "Onsite" view or the employee resume selector do not appear immediatlely after creation

This occurs because currently the domain for onsite events requires that the event to have multiple slots as well as to have at least one employee registered to it. Therefore, newly created records often fail these criteria and remain hidden.

In further versions, this pr: https://github.com/odoo/odoo/pull/246285/ changes the domain of the event selector in the employee resume by removing the dependency on the multiple slots and filtering by the specific employee for registration.

This change is not stable to backport as it indroduces the `employee_id` field as an invisible field in the xml to be able to compare in the domain.

This commit partly changes both domains to not require the multiple slots anymore, while still showing all events for which an employee is registered. This commit also ensures that when an event is created from the Onsite view or selector, the current user's employee will be registered to it.

Steps to reproduce
- Go to employees->Learning->Onsite
- Select New and create an event
- Go back to Onsite Courses
- You will not see the created event (unless it is multi_slot and an employee was registered)

opw-5915686

Forward-Port-Of: odoo/odoo#258952

Steps to reproduce
==================
1. Configure a delivery method with free shipping above a threshold
2. Add a product to the cart above that threshold, select the delivery method and leave the cart unfinished
3. Lower the product price below the threshold
4. Recover the cart and confirm the order from /shop/checkout

=> The product prices are refreshed, but shipping stays free although
   the new total is below the threshold.

Root cause
==========
Since [1], nothing re-rates the carrier after /shop/confirm_order refreshes the cart prices: the delivery method is selected before the confirmation. In 17.0, the payment page auto-clicked the selected carrier on load, which re-rated the shipping cost and masked the issue.

Fix
===
Re-rate the selected delivery method in `shop_confirm_order` after the prices have been recomputed, as `_cart_update` already does.

[1]: https://github.com/odoo/odoo/commit/8e2b6cede55b51f7ccdbe7601aa7e6035fd6f9fe

opw-6383849


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

Forward-Port-Of: odoo/odoo#282963
Forward-Port-Of: odoo/odoo#276905

When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it opens and on every later render. The server raises a ValueError and the call has no error handling, so the whole editor goes down. The bad domain stays saved on the property, so reopening the editor fails the same way and the property can no longer be edited or deleted.

Wrap the search_count call in _updateMatchingRecordsCount (property_definition.js) in a try/catch and show no count when it fails. This is the only place the editor counts matching records, so guarding it here handles a bad domain from any source, the field selector or the code editor. The field selector still shows its warning on the invalid path, so the user can fix or delete the property.

Steps to reproduce:
1. On a model that has a Properties field, add a Many2one property and set its Model to a model that itself has a Properties field.
2. Open the property Domain and click New Rule.
3. In the field selector pick the Properties entry, then close the selector.

=> An error dialog appears and the property can no longer be edited or deleted.

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

Forward-Port-Of: odoo/odoo#281221
Forward-Port-Of: odoo/odoo#259886

**Issue**
If a move's package is already reserved, relocating that move raises an AccessError.

**Steps to reproduce**
- Activate the "Packages" feature in Inventory settings.
- Activate track localization in settings
- Create a new storable product.
- Using an inventory adjustment, add some quantity of that product in Stock, in a new package X.
- Create a sales order for that product and confirm it, so the quantity in Stock gets reserved.
- Go to Inventory > Reporting > Locations.
- Select the quant and try to relocate it, e.g. to WH/Input.
-> Raises an AccessError: "Failed to write field stock.package.picking_ids"

**Cause**
Relocating a quant creates a move:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1531
which creates a new move line without a `picking_id`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1276-L1287

Since both move lines (the new one and the one linked to the SO delivery) share the same `result_package_id`,
in `_compute_picking_ids`, both move lines are grouped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L174-L176
Thus, two "pickings" end up associated with the package: the SO's, and `None`.
While setting those pickings on the package, it tries to access them:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L182
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1497-L1503
And since `self` isn't just `None`, this check won't be skipped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4152
This eventually raises an AccessError since `None` gets filtered out by `filtered_domain`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4154-L4156
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1504-L1505

opw-6427070

Forward-Port-Of: odoo/odoo#282209

When paying with an eWallet or gift card in POS, the reward line could end up 0.01 short of the actual card balance if the discount product's tax is configured as tax-excluded through a per-tax override, regardless of the tax's own default configuration. The card is still debited for the full balance, but the order is only discounted by one cent less, so the amount charged to the customer no longer matches the amount consumed from the card.

Steps to reproduce:
-------------------
* Top up an eWallet (or gift card) with a balance of 10.00
* On the eWallet/gift card program's discount product, set an 18% tax whose Tax Computation is overridden to "Excluded" (price_include_override = tax_excluded), independently of the company's default tax configuration
* In POS, add a product to an order and pay (partly) with that eWallet/gift card

> Observation:
Only 9.99 is deducted from the order total, while the backend correctly shows 10 consumed on the wallet/gift card.

Why the fix:
------------
The reward line's price_unit was reconstructed from a one-time backward tax computation, then kept only the tax amount for taxes whose price_include field was true, dropping it for any tax forced excluded. That price_unit was later re-taxed forward using the tax's real (excluded) configuration, and the two roundings don't agree for rates like 18%, losing a cent.

We now force special_mode "total_included" whenever an eWallet/gift card reward line's taxes are computed, not just at creation, so its tax-included total always equals the exact redeemed amount regardless of how the tax is configured, and store price_unit as that target amount directly.

opw-5819389

Forward-Port-Of: odoo/odoo#278568

Clicking the translate button saves the form's root record before opening the translation dialog, since https://github.com/odoo/odoo/commit/9da52919a03dbcee5209430918195158c0652099. A record opened in an x2many form dialog keeps its changes for itself until the dialog is saved, see https://github.com/odoo/odoo/blob/242f6d3cf7288853f163ac6986a3b7aa4279efaf/addons/web/static/src/model/relational_model/static_list.js#L193. Its pending changes are not part of the root record changes, so saving the root sends nothing to the server, and the translation dialog then shows the stored terms instead of the current content, or no terms at all when the stored value is empty.

The fix changes openTranslationDialog in translation_button.js, the place that decides which record to save. When the record keeps its changes for itself (record._noUpdateParent), the record is saved directly, like the button did before the commit above. The root record is still saved in the other cases, so the editable list case that commit fixed keeps working.

Steps to reproduce:
1. Activate a second language in Settings > Translations > Languages
2. Open the Surveys app, open a survey and click a question in the Questions tab
3. In the Description tab, change the description
4. Click the EN button on the description field

=> the translation dialog shows the terms of the previous description, not the current one

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

Forward-Port-Of: odoo/odoo#269507

Steps to produce:
---
- Install `sale_management` and `sale_loyalty` module without demo.
- From sales > products > discounts & loyalty, create new loyalty card program and save.
- Now create new product of 100$.
- Create a user which have sales rights as `user: own documents only`.
- With that user, create new sale order with product and confirm.
- Try to cancel the order.

Issue:
---
- It shows the access error: 
```py
You are not allowed to delete 'Sale Order Coupon Points - Keeps track of how a
 sale order impacts a coupon' (sale.order.coupon.points) records.

This operation is allowed for the following groups:
	- Sales/Administrator

Contact your administrator to request access if necessary.
```

Root cause:
---
- Users with the `Sales: Own Documents Only` access right only have read permissions ([1]). When they cancel a Sales Order, the `_action_cancel` method attempts to clean up the temporary pending points allocated to the order by calling `self.coupon_point_ids.unlink()`. Because this call is executed without elevated privileges, the system blocks the deletion and raises an Access Error

Solution:
---
- Added `.sudo()` to the `unlink()` call for `coupon_point_ids` in the `_action_cancel` method. This ensures the pending point records are cleaned up with the necessary elevated privileges.

[1]https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/sale_loyalty/security/ir.model.access.csv#L16

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

Forward-Port-Of: odoo/odoo#283535
Forward-Port-Of: odoo/odoo#281477

Peppol documents can be received in a journal or in the Documents app (peppol_reception_mode). Some companies cannot use Documents: _peppol_allows_document_reception() returns False and the journal stays required. This is the case of French companies (via l10n_fr_pdp).

The onchange of the settings and the import did not check this method. So on a French company with the mode set to 'documents':
  - the Settings cleared the journal on each opening, while it was still required
  - the incoming documents were saved in Documents instead of vendor bills

Steps to reproduce:
- Create a Belgian company, with a purchase journal, and register it on Peppol as receiver
- Set the reception mode to "Receive in Documents"
- Change the fiscal position to France, and install l10n_fr_pdp, the Peppol part is replaced by "French Electronic Invoicing", so the radio button is not visible anymore, but the company still has peppol_reception_mode == 'documents'.
- Open the Settings again: the field "Incoming Invoices Journal" is empty.

opw-6429691

Forward-Port-Of: odoo/enterprise#126462

Before this commit, it was impossible to use budget on the Moroccan P&L, for the following reasons:

- The feature was designed for one-column reports. MA's P&L uses 3, one of which is the total of the two others.

=> We remove that requirement, and make sure to always select the 'balance' column as the reference for the budget comparison.

- When trying to input a budget amount in the report, the amount disappeared entirely.

    => This was because the total column of report was not using 'balance' as its expression label. We fix that by rewriting the expression labels of that report.

The fact we hardcode the use of 'balance' is arguable. It is however not possible here to rely on some custom handler to change a specific option key that would be used to generate the budget comparison data, since some of those data need to be generated in the get_options, before _custom_options_initializer even gets called. This is the simplest approach, and this case is rare enough for us to deem it acceptable.

opw-6385229

Forward-Port-Of: odoo/enterprise#128816
Forward-Port-Of: odoo/enterprise#128266