`_read_grouping_sets` dispatches each SQL result row to the grouping set(s) that requested it, using the `GROUPING()` bitmask as the key.

When a grouping set repeats a groupby spec, e.g. `['foo', 'foo']`, it computes the exact same bitmask as the grouping set for the deduplicated column alone (`['foo']`).

Two grouping sets sharing a bitmask were treated as interchangeable duplicates: only the first one seen got its extractor registered, and its already-extracted result list was later blindly copied onto every other grouping set sharing that bitmask.

This is wrong whenever those sets don't actually share the same shape:

`_read_grouping_sets(grouping_sets=[['foo'], ['foo', 'foo']])`

returned

`[('my_foo_val', <aggregate>), ('my_foo_val', <aggregate>)]`

instead of

`[('my_foo_val', <aggregate>), ('my_foo_val', 'my_foo_val', <aggregate>)]` (repeating the value, as `_read_group` does).

Callers unpacking crashed with `ValueError: not enough values to unpack`.

Fix:
- Deduplicate the SQL terms of each grouping set before building its `GROUPING SETS (...)`, so that grouping sets which are physically the same always produce a single row from PostgreSQL.
- Register every grouping set's own extractor under its bitmask in a list, instead of keeping only the first one seen, and dispatch each result row to all of them.

task-6511626

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

Forward-Port-Of: odoo/odoo#284683

Steps to reproduce the bug:
- Log in as a user with only the "Inventory / User" access right and
Products/Create (product.group_product_manager) granted (write access
to product.product/product.template)

- Open a storable product's form view.
    - Observe the "Quantity On Hand" field is readonly, and the "On Hand"
    quants popup opened from it is read-only too.
- Go to the Inventory > Physical Inventory / Inventory Adjustments menu instead.
    - Observe the same user can freely edit the quantity and apply the inventory adjustment.

Problem:
A stock user could apply inventory adjustments from the Inventory
Adjustments menu, but could not perform the exact same action from
the product form, forcing an unnecessary detour.

Three places in `stock` still gated editing to `stock.group_stock_manager`,
even though `inventory_mode` is already granted to any `stock.group_stock_user`
by `stock.quant._set_view_context()`, and the underlying write is already
guarded correctly by `_is_inventory_mode()`:
- `stock.quant._get_quants_action()` only picks the editable tree view
(used by the "On Hand" quants popup) for managers:
  https://github.com/odoo/odoo/blob/19.0/addons/stock/models/stock_quant.py#L1328
- The product form's own "Quantity On Hand" field/link
(`product_views.xml`) is only made editable for managers, and forced
readonly for everyone else:
  https://github.com/odoo/odoo/blob/19.0/addons/stock/views/product_views.xml#L192-L196
- The `inventory_quantity_auto_apply` field itself (the one actually
rendered in the editable quants list, whether opened from the product
form or the Forecasted Report) is restricted to managers at the Python
field-definition level:
  https://github.com/odoo/odoo/blob/19.0/addons/stock/models/stock_quant.py#L100-L104

All three checks were left over from before commit
https://github.com/odoo/odoo/commit/37d96f49ccc85fa651f092b6c32bab1af2c34f2d,
which gave `stock.group_stock_user` write access on `stock.quant`
(see `ir.model.access.csv`) and dropped the manager-only restriction on
`action_apply_inventory`. The ACL and the Inventory Adjustments flow
were updated at the time, but these three entry points were not, leaving
them stricter than the rest of the permission model.

opw-6439844

Forward-Port-Of: odoo/odoo#282010

### Steps to reproduce:

- In the settings: Enable Storage Locations
- Create a customer location "Customer stock" with "Customers" as its parent location
- Create a delivery operation type "Deliver Super Customer" and set its default destination location to "Customer stock"
- Go to Inventory > Overview > Deliver Super Customer > New
- Set a contact on the transfer
#### > The destination location switches from "Customer stock" to "Customers"

### Cause of the issue:

The `location_dest_id` of `stock.picking` depends on its `partner_id`. So that changing the partner recomputes the locations of the transfer. However, as soon as the destination of the operation type has a `customer` usage, the `property_stock_customer` of the contact replaces it unconditionally:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L949-L963 
However, the `property_stock_customer` falls  back to an `ir.default` pointing at the default `Customers` location when nothing is set on the contact:
https://github.com/odoo/odoo/blob/1c40fab04b71def8f3645c4c4bb0c1441057f307/addons/stock/data/stock_data.xml#L71-L72vs

The override comes from 8a0775aa1dd9, which replaced an `elif` fallback on the contact by an "unconditional" substitution as this fallback had become unreachable once `default_location_src_id` and `default_location_dest_id` were made required:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L34-L41

opw-6421090

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

Forward-Port-Of: odoo/odoo#283886
Forward-Port-Of: odoo/odoo#280016

**Steps to reproduce:**
- Install Accounting and l10n_se
- Switch to a Swedish company (e.g. SE Company)

- In Accounting settings, set "Identification" with anything
- In Bank journal:
  * Set an account number
  * Make sure "Swedish ISO20022" is available in "Outgoing Payments"
  * Set "pain.001.001.09" as "XML Format" in "Outgoing Payments"
- Create a vendor payment:
  * Vendor: [a vendor with a trusted bank account]
  * Payment Method: Swedish ISO20022
  * Amount: [any]
- Confirm the payment
- From the payments list, select the payment and create a batch
- Validate the batch payment

**Issue:**
When the batch is validated, a `pain.001.001.09` file should be generated. However, its content is that of a `pain.001.001.03` file, even if the version reported in the file is `pain.001.001.09`.

For example, `<ReqdExctnDt>` should contains a subnode `<Dt>` in `001.001.09`, which is not the case.

It leads to the file being rejected as non-compliant to `pain.001.001.09`.

opw-6472050

Forward-Port-Of: odoo/enterprise#129234
Forward-Port-Of: odoo/enterprise#128598

Steps to reproduce:
- Set up a company in Kenya with eTIMS.
- Sell an order from the POS and send it to eTIMS.
- Refund that order and send the refund to eTIMS.

Cause of the issue:
When we build the JSON for eTIMS, the "orgInvcNo" field (the KRA invoice number of the order we are refunding) was always set to `self.sequence_number`, which is just the order's own number in its session. This is wrong for a refund: eTIMS then can't find the item on "the original invoice" (since it's looking at the wrong invoice), and also can't check the amounts, since it's comparing them to the wrong order. eTIMS then rejects the refund with a 910 error, like "item sequence ... does not exist on the original invoice" or "amount is incorrect for item ...".

The invoice-based flow (account_move.py) already does this the right way, using `reversed_entry_id.l10n_ke_oscu_invoice_number`, but the POS order flow was not doing the same thing.

Solution:
For a refund order, use the KRA invoice number of the refunded order (`refunded_order_id.l10n_ke_oscu_order_number`) instead of the refund's own sequence number. Normal sales keep working like before.

opw-6445174

Forward-Port-Of: odoo/enterprise#128387

**Problem:**
For a French company, an employee whose working schedule differs from the company's cannot have their Working Hours changed when they have a validated time off that falls on a non-working day (e.g. a Saturday). Saving fails with "The operation cannot be completed: The start date must be before or equal to the end date."

**Steps to reproduce:**
1. Install l10n_fr_hr_holidays and work in a French company.
2. Set the company Working Hours and a reference (Paid) Time Off type.
3. Give an employee a Monday-to-Friday schedule that differs from the company's.
4. Create a one day Paid Time Off for the employee on a Saturday.
5. Change the employee's Working Hours.

**Current behavior:**
Saving is rejected by the date_from <= date_to constraint; the Working Hours cannot be changed as long as the weekend time off exists.

**Expected behavior:**
The Working Hours can be changed and the time off keeps a valid date range.

**Cause of the issue:**
When the French computation applies, `_get_fr_date_from_to` moves `date_start` forward to the first working day and, in a separate loop, moves `date_target` forward while the next day is a non-working day. The two loops are asymmetric: for a leave lying entirely on non-working days (a single Saturday for a Monday-to-Friday employee) `date_start` is pushed to the following Monday while `date_target` only reaches the Sunday. The pair is then written to `date_from`/`date_to` as Monday > Sunday, violating the date_from <= date_to constraint.

**Fix:**
A leave that contains no working day has nothing to anchor the "lost days" extension on, so the adjustment must not apply. Detecting the crossed pointers and keeping the leave's original dates preserves a valid range while leaving every leave that contains at least one working day untouched.

opw-6348425

Forward-Port-Of: odoo/odoo#278833

Opening a tax report from a return and submitting it could act on a different
return than the one on screen.

_get_return_from_report_options searches by company, period and report with
limit=1, but that combination is not unique: l10n_nl declares two return types
on l10n_nl.tax_report, nl_tax_return_type and nl_tax_correction_return_type, so
a VAT return and its correction both match. Which one is returned is then
decided by _order (is_completed, date_deadline, name, id).

For a Dutch VAT correction it resolves to the original VAT return of the same
quarter, so send_xbrl submits and flags that record instead of the correction.

The options already carry the return type they were built for, in the
return_periodicity filter, so restrict the search to it when it is set.
l10n_nl_reports kept a return_id option for the same reason when computing the
already declared amount of a suppletie; it can use
_get_return_from_report_options now.

opw-6421300

Forward-Port-Of: odoo/enterprise#127073

`_prepare_edi_vals` always called `_get_formatted_payment_values()`, adding an EDI-Paiement (telereglement) block to the T-IDENTIF of the 3310CA3, regardless of whether the company owes VAT or is in a credit position.

Steps to reproduce:
- French company in a VAT credit position, requesting a refund.
- Fill a bank account line, the account to receive the refund and send the VAT report to the DGFiP.

Current behaviour:
The DGFiP returns a negative acknowledgement on the CA3 interchange: "Telereglement 1 rejete: Montant telereglement absent ou invalide. Code erreur : 018", even though the declaration itself is accepted.

The wizard's bank account lines are reused for two opposite purposes: the account to debit when VAT is due, and the account to credit when a refund is asked. `_get_formatted_payment_values()` builds a payment order from them unconditionally, so a telereglement for the credit amount is emitted in the refund case. A telereglement is invalid when no VAT is due, hence error 018. A return nets to either a payment or a credit, never both, so the two cases are mutually exclusive.

This commit guards the call with `self.is_vat_due`, so the telereglement is only generated when the company actually owes VAT. The VAT-due flow is unchanged.

opw-6275695

Forward-Port-Of: odoo/enterprise#124694
Forward-Port-Of: odoo/enterprise#120840

Steps to reproduce
---
1. Enable Units of Measure (`uom.group_uom`) and give a unit a very long name.
2. Build a product using that unit for its components, and set a long note (plain text or an HTML table) on its manufacturing order.
3. Open that operation in Shop Floor.

Observed: the finished-product name breaks one letter per line, the long unit next to the quantity and the note both run off the right edge of the card.
Expected: name, unit and note stay within the card, wrapping or scrolling.

Issue
---
Each of these rows is a flexbox whose children keep the default `min-width: auto`, so they never shrink below their content's intrinsic width. A long UoM name therefore forces its flex sibling (the product name) down to min-content and wraps it one character per line, while long quantities and notes push past the fixed-width card instead of wrapping. Adding `min-w-0` lets the flex items shrink, replacing `text-nowrap` with `text-wrap` on the quantity lets the value wrap, and wrapping `logNote` in a `min-w-0 overflow-auto` span contains an HTML-table note within the card.

opw-6496759

Root cause:
Inserting a Field placeholder for a contact property in the mail editor builds the path with a property accessor, of the form properties.get('name') for a plain property or properties.get('name', env['res.partner']) when the property points to a relation. The field service walks a path by splitting it on every dot, so it reads get('name') as a field name and the dot inside env['res.partner'] as another separator. Neither matches a real field, so the path is reported as an invalid field chain, the Update button stays inactive and the placeholder cannot be inserted.

This validation only runs since https://github.com/odoo/odoo/commit/a4efb745e9f4ba24dfa01f1e17e65f1a7cac90a5 switched the mail editor to the generic dynamic field plugin, which re-reads the picked path through the field service instead of inserting it as is.

Fix:
Add a splitPath helper in field_service.js that splits the path on dots outside quotes and rewrites each get('name') or get('name', env['model']) accessor back to the property name, then use it in loadPath. loadPath is the single place every consumer goes through, so both the field chain shown in the popover and the Update button that reads the field info start resolving the property again.

Steps to reproduce:
1. Open a contact in Contacts, open the cog menu, click Edit Properties, add a property and save.
2. Open Email Marketing and create a new mailing.
3. Set Recipients to Contact.
4. In the mail body type /field and pick Field.
5. In the popover open the field selector, pick Properties then the property, and click Update.

=> the field shows Invalid field chain and the placeholder is not inserted

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6375568)

opw-6375568

Deleting a project also sends the folders of every archived project to the trash.

### Steps to reproduce

- Install `documents_project`, where each project has its own Documents folder linked through `project.project.documents_folder_id`.
- Create `Project 1`, `Project 2`, and `Project 3`, then archive the first two.
- Delete `Project 3`.
- The folders of `Project 1` and `Project 2` are moved to the trash with their contents, although both projects still exist and still reference them.

### Cause

`_archive_folder_on_projects_unlinked` only archives folders that are no longer used by any project. This was checked through a `documents.document` domain on `project_ids`.

The domain mixed two conditions on the same relation:

- `('project_ids', '!=', False)` checks that a folder has users,
- `('project_ids', 'not any', [('id', 'not in', self.ids)])` checks that it has no users outside the projects being deleted.

Those conditions are not evaluated the same way by the ORM. The first one keeps archived projects visible by disabling `active_test` internally, while the second one searches `project.project` normally and hides archived projects.

An archived project can therefore be counted as a folder user by one condition and ignored by the other, causing its folder to be archived.

### Fix

Check remaining users directly on `project.project` with `active_test=False`, so archived projects are included. Since only folders of deleted projects can become unused, the search starts from those folders instead of scanning all Documents.

opw-6442976

Forward-Port-Of: odoo/enterprise#127217

This is one of many errors fixing the FAIA report, which is the SAF-T report for Luxembourg. See PR #113316 for a list of similar PRs.

### Error 1: Negative tax amounts

Auditors from Luxemborg provided one Odoo user with analysis files of their FAIA xml report. The following discrepancy was present in more than 300 lines:

`[TaxInformation/TaxAmount/Amount] # is negative. Only postive values are admitted. The sign is automatically determined by the corresponding CreditAmount (-) Or DebitAmount (+) on the same Line.`

This discrepancy was caused by two different scenarios. The first was a negative `unit_price` line, such as a Discount product. The second was a tax with negative and positive repartition lines, such as a tax with xml ID `lu_2015_tax_AP-EC-17`.

Luxembourg officials confirmed the following behavior:
1. The TaxInformation/TaxAmount/Amount element must be positive.
2. The TaxInformationTotals/TaxAmount/Amount element may be negative.
3. There may only be one TaxInformationTotals element per TaxCode in an Invoice element.

This commit ensures that these conditions are met for the FAIA report. I'm not sure if the TaxInformation changes should also be applied to the base `account_saft saft_report.xml` file.

### Error 2: SoftwareVersion

The SoftwareVersion element is limited to 18 characters. The relevant error from a customer's analysis file is below.

Error:  Value exceeds maxLength of "18".

### Error 3: CurrencyAmount

The `account_saft` method `GeneralLedgerCustomHandler._saft_fill_report_tax_details_values()` does not report the amount of tax in foreign currency, instead replacing this value with the amount in company currency. No errors prompted this change; it just seems wrong on its face.

### Error 4: 
PR #113720 ensured that the TaxType element is always TVA. This means that the TaxType should no longer should be ignored in our example documents.

### Error 5: Schema validation failure

The elements Inovice/CustomerInfo and Invoice/SupplierInfo are defined with the element `<xs:choice>` in the XSD file linked below. Only one can be present at any time, not both.

https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. note: currently the link is broken.

PR #100749 allowed many parts of SAF-T code to display both customer and supplier data, including these elements. This commit ensures that the elements are mutually exclusive.

opw-6344914 [Link](https://www.odoo.com/odoo/project.task/6344914)

Forward-Port-Of: odoo/enterprise#129043
Forward-Port-Of: odoo/enterprise#126121

BACKPORT OF https://github.com/odoo/odoo/pull/278180

When refunding an order that had a fixed-amount global discount, the refunded total was inflated: e.g. a 65.00 order (80.00 - 15.00 fixed discount) was refunded as 95.00 instead of 65.00. On the refund order amount_paid then differed from amount_total, so the POS session's closing entry could not balance; _validate_session rolled back and no account.move was created, leaving the session closed with no accounting.

When a refund is created, the product lines are negated and the discount line is excluded, then pos_discount re-applies the global discount to the refund order through applyDiscount. For a fixed amount, reduce_base_lines_to_target_amount targets an absolute value and does not follow the sign of the (now negative) base, so the discount keeps the sale sign. Percentages scale with the base and are not affected.

Negate the fixed discount amount when the destination order is a refund so it mirrors the negative base. The stored discount_value is left unchanged so the auto-resync of the discount stays idempotent.

opw-6458124

Forward-Port-Of: odoo/odoo#281958

When a return order is created from the front end and later cancelled without being deleted from the backend, opening the original order from the POS ticket screen causes the UI to crash.

The issue occurs because the refundedQty getter in `addons/point_of_sale/static/src/app/models/pos_order_line.js` assumes that every refunded order line has a valid order_id. For cancelled return orders, line.order_id is no longer available, resulting in the following runtime error:

`TypeError: can't access property 'state', line.order_id is undefined`

As a result, selecting the original paid order from the Ticket Screen breaks the POS interface.

**Steps to Reproduce**
1. Create a normal sale in the POS.
2. Keep the POS session open.
3. In the backend, open the POS order and click Return Products.
4. Cancel the generated refund order (do not delete it).
5. In the POS, navigate to Ticket Screen → Orders → Paid Orders.
6. Select the original order.


Desired behavior after PR is merged:

The original order should open normally without any errors, even if a related refund order has been cancelled.

Issue Ticket: https://github.com/odoo/odoo/issues/260079


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

Forward-Port-Of: odoo/odoo#279942

**Behavior:**
When a sales user without accounting access rights tries to view an invoice created from a sale order where a cash rounding is applied, an AccessError is raised.

This occurs because loading the invoice view triggers `_compute_tax_totals()`, which then passes the invoice's `invoice_cash_rounding_id` to `_get_tax_totals_summary()`. Which then ends up failing when trying to access fields on the `cash_rounding` record  due to missing accounting rights, even though the user is allowed to view the parent invoice.

This is fixed by ensuring reading fields on `cash_rounding` during tax total computation bypasses the access check using `sudo()`, as the user already has legitimate access to the invoice itself.

**Steps to reproduce:**
- As an admin, enable cash rounding then create one.
- Create an invoice and set the Cash Rounding Method
- In debug mode, go to 'Set Default Values' in the debug dropdown and set Cash Rounding Method = your rounding for all users
- Go to users, and ensures that Demo has no accounting rights but has sales user rights
- As Demo, create a sale order, confirm it, then create the related invoice.
- When trying to acces said invoice, you should get an Access Error

opw-6379781

Forward-Port-Of: odoo/odoo#284212
Forward-Port-Of: odoo/odoo#278815