### 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:
- Have a paid order with a product ordered once
- Open the ticket screen, select that order and its line
- Scan a product barcode with a keyboard-wedge scanner

Issue:
"Maximum Exceeded - The requested quantity to be refunded is higher than the ordered quantity. 6 is requested while only 1 can be refunded." When the line holds enough quantity no dialog is shown at all and a refund quantity taken from the barcode is silently set.

Cause:
A keyboard-wedge scanner types the barcode as a burst of keystrokes. The number buffer discards such bursts by waiting
barcodeService.maxTimeBetweenKeysInMs before handling the keys it collected and dropping any batch of more than two, but only when its holder asks for it with `useWithBarcode`. TicketScreen never set the flag, so its buffer handled every keystroke on its own and the digits of the barcode reached _setToRefundDetail as the refund quantity. ProductScreen, OrderSummary and PaymentScreen all set it.

Fix:
Set `useWithBarcode: true` on the ticket screen number buffer. Since the keys are now handled with a delay, capture the buffer before the selected order or orderline changes, so that a keystroke is applied to the line that was selected when it was typed and not to the next one.

opw-6465148

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

Forward-Port-Of: odoo/odoo#282610
Forward-Port-Of: odoo/odoo#281962

Steps to Reproduce :
1. Go to Website → Edit Mode
2. Add a snippet with button
3. Click on button and change its type to : " Custom"
4. Apply the gradient type color in fill color option
5. Apply any color in text color option
6. You will notice that the gradient type color in fill color option is
removed.

Problem:
Since [this commit][1] new button style options have been added to the
sidebar. If one changes the style of a button to custom, changes the
background to gradient, and tries to change the text color, the
background gradient is removed.

Cause:
Whenever a gradient is added either to text or as a background, it is
applied as a background image. In the case of a text gradient, an
additional class, `text-gradient`, is applied for correct styling. Once
a change to either color or background/fill is applied that is not a
gradient color change, the background image of the element would be
reset to nothing. This is the result of [this line][2] from a [previous
commit][3]. In the case of a button, this meant changing the font
color would reset the background. That is not the desired outcome.
The flaw was only discovered once new options were added to change
non-text/font elements' backgrounds to gradient.

Solution:
An additional check has been added to see if the element being edited
is text. If so, and it's a gradient style being changed, we remove the
background image. Otherwise it is kept so that the button case from
above is resolved.

[1]: https://github.com/odoo/odoo/commit/2bf1db001b195480b963b338583c170aa1c009a3
[2]: https://github.com/odoo/odoo/blob/8e0845712f462ecfafd2176406dcbafc869a5564/addons/html_editor/static/src/main/font/color_plugin.js#L575
[3]: https://github.com/odoo/odoo/commit/8e0845712f462ecfafd2176406dcbafc869a5564

task-6247134

Forward-Port-Of: odoo/odoo#279070

### Before this fix
---

The `_get_so_mapping_from_project()` method returns a mapping where the key is
the move line ID and the value is a `sale.order` record (or `None`).

Because of the issues described below, a valid `sale.order` could be available
for reinvoicing, but the corresponding move line might still not be mapped to
that sale order. As a result, the move line is not added to the reinvoiceable
sale order.

However, the implementation has two issues:

#### 1. Projects are overwritten when they share the same analytic account

`project_per_accounts` is built as a dictionary mapping an analytic account ID
to a single project. If multiple projects reference the same analytic account,
each new assignment replaces the previous one. As a result, only the last
project associated with a given analytic account is retained.

**Example:**

* Analytic Account **AA1** is linked to **Project A** and **Project B**.
* The dictionary becomes `{AA1: Project B}`.
* **Project A** is lost, even though it also references **AA1**.

**Steps to reproduce:**

1. Create an analytic account **AA1**.
2. Create **Project A** and **Project B**, both linked to **AA1**.
3. Create **Sale Order SO1** linked only to **Project A**.
4. Create a vendor bill (or expense) that generates an AML using **AA1** for a
   product configured with **Reinvoice Costs = At Sales Price**.
5. Validate the document.

**Expected behavior:**
The product should be added to **SO1** for reinvoicing.

**Actual behavior:**
The move line is not mapped to **SO1**, so no sale order line is created.

#### 2. Previously found projects are overwritten during iteration

The `project` variable is reassigned on every iteration of the loop. After the
loop completes, it only contains the project (or lack of one) corresponding to
the last processed analytic account. This can cause valid projects found earlier
in the loop to be discarded.

**Example:**

* Move line has analytic accounts **AA1** and **AA2**.
* **AA1** maps to **Project A**.
* **AA2** has no linked project.
* After the loop, `project` is `None`, even though **Project A** was found.

**Steps to reproduce:**

1. Create analytic accounts **AA1** and **AA2**.
2. Create **Project A** linked to **AA1** only.
3. Create **Sale Order SO1** linked to **Project A**.
4. Create a vendor bill (or expense) whose AML is distributed between **AA1**
   and **AA2**, where **AA2** is processed after **AA1**.
5. Validate the document.

**Expected behavior:**
The move line should still be mapped to **SO1** because **AA1** references
**Project A**.

**Actual behavior:**
The last processed analytic account (**AA2**) overwrites the previously found
project, causing the move line not to be linked to **SO1**.

### After this fix
---

* `project_per_accounts` stores **all** projects associated with each analytic
  account instead of keeping only the last one.
* The project lookup preserves all valid project candidates instead of
  overwriting previously found results during iteration.
* As a result, the method can resolve the related `sale.order` in more cases,
  improving the overall accuracy of the mapping.

> **Note:** This change prevents valid project associations from being lost
> when multiple projects share an analytic account or when multiple analytic
> accounts are processed for the same move line.

**OPW:** 6294615

Forward-Port-Of: odoo/odoo#277110

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

`_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:**
- 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

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#283719
Forward-Port-Of: odoo/odoo#258952

Issue:
---
Fiscal position is wrongly set to `self.env.user.partner_id.country_id`
instead of `partner_shipping` country, if `partner_shipping_id` is not
changed in the checkout process.

Steps:
1- Create two auto detect fiscal positions: France, Germany
2- Set portal user's partner address country to France.
3- Using portal user, shop from website, and create a delivery address.
4- Pay and confirm the order.
5- Using the admin user, you check the SO's FP which is correctly set
   to Germany.
6- Using portal user, again shop from website, and don't change
   address. Keep previous shipping address which is Germany.
7- Confirm and pay the order.
8- Using admin user, check the new SO's FP. It's set to France.

Cause:
---
`_compute_fiscal_position_id` in SO depends on `partner_shipping_id`.
When the `partner_shipping_id` is not changed, the fiscal position
value set in create will remain.
This value is set in `Website._prepare_sale_order_values()`.
The `fiscal_position_id` is set to self.fiscal_position_id, which is
`_get_fiscal_position(self.env.user.partner_id)`.

Fix:
---
If the user has already a SO, we can use last SO's shipping address
and invoice address to calculate FP in `_prepare_sale_order_values`.

opw-6357638

Forward-Port-Of: odoo/odoo#279716
Forward-Port-Of: odoo/odoo#276485

Issue:
UAE companies cannot create their salaries bank account directly from Payroll Settings. The bank account cannot be saved, leaving payroll configuration incomplete and preventing the UAE WPS process from being completed.

Steps to reproduce:
* Configure an Emirati company with the UAE Payroll localization.
* Open Payroll > Configuration > Settings.
* Create a new Salaries Bank Account from the settings field.
* Fill in the bank details and try to save the account.

Cause:
Since saas-19.2, the bank account form hides the required account holder and expects the opening field to provide it through `default_partner_id`.
The UAE salaries bank account setting only restricts selectable accounts through its domain and does not provide that creation default. Newly created accounts therefore have no owner and cannot be saved.

Domains only filter selectable records and do not initialize fields on new records. Since the shared bank account form hides the required partner, accounts created from Payroll Settings have no owner and cannot be saved.

Solution:
We need to provide the current company partner as the account creation default while retaining the existing selection domain. This preserves the company and country restrictions and guarantees that newly created salaries accounts satisfy the required ownership invariant.

opw-6441848

Forward-Port-Of: odoo/enterprise#127777

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

`_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

**Problem:**
When sending an Email to multiple Applicants when one Applicant does not have a `partner_id` set, all Applicants set to receive the email will copy the `email_from` of the Applicant without a `partner_id`.

**Cause:**
When sending an Email to an Applicant record that does not have a `partner_id` set on it, a new Contact is created to be set to the Applicant. When this Contact is created, its `applicant_ids` value defaults to the Applicants in the context. This causes all Applicants in the current context (i.e. the recipients of the Email) to be set on the Contact, also causing that Contact to be set as the `partner_id` of all the Applicants, rather than just the one missing a `partner_id`. This then causes the `email_from` of the Contact to be set on all the Applicants.
https://github.com/odoo/odoo/blob/ccd167e23ea80545e4f09e2302c1b2489e8c42d8/addons/hr_recruitment/wizard/applicant_send_mail.py#L40-L42 https://github.com/odoo/odoo/blob/ccd167e23ea80545e4f09e2302c1b2489e8c42d8/odoo/orm/models.py#L1292-L1293

**Purpose:**
Modify the `create` call used to create the new Contact to define `applicant_ids` as only the Applicant that the Contact is being created for.

**Steps to Reproduce in Runbot:**
1. Delete the Contact corresponding to the `partner_id` of any given Applicant.
2. Select multiple Applicants, including the one whose `partner_id` was deleted, then send an email to them using the Actions menu.

opw-6383263

Forward-Port-Of: odoo/odoo#284323
Forward-Port-Of: odoo/odoo#283271

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

## Note on this PR

My previous PR in this chain (odoo/odoo#284334, base `saas-19.2`) was mistakenly capped with
`@robodoo up to saas-19.2`, so the forward port stopped there instead of continuing. This PR is
technically a forward port: it cherry-picks the merged `saas-19.2` commit of #284334 (itself a
forward port of #284003 and of the original #274312 on 19.0) onto `saas-19.3`.

## 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()`.
- Clicking the button on an invoice still on `unknown` does nothing at all, since those invoices
  are filtered out before the status refresh.

## 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.
- Invoices on `unknown` get their status refreshed on click, so one that Nilvera has already
  resolved is picked up without waiting for the next cron run.

## 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

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

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

The `l10n_tr_zero_vat_warning` field is a boolean field but was incorrectly defined as [binary], causing the compute method to fail when assigning a boolean value.

```py
  File "/home/odoo/src/odoo/saas-19.3/addons/l10n_tr_nilvera_einvoice/models/account_move.py", line 156, in _compute_l10n_tr_l10n_tr_zero_vat_warning
    invoice.l10n_tr_zero_vat_warning = exempt_zero_tax and invoice.l10n_tr_gib_invoice_type == 'SATIS' and exempt_zero_tax in invoice.line_ids.tax_ids
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1892, in __set__
    self.write(protected_records, value)
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields_binary.py", line 151, in write
    super().write(records, value)
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields.py", line 1583, in write
    cache_value = self.convert_to_cache(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.3/odoo/orm/fields_binary.py", line 83, in convert_to_cache
    raise TypeError(f'{self}: use BinaryValue instead of {value.__class__.__name__}')
TypeError: account.move.l10n_tr_zero_vat_warning: use BinaryValue instead of bool
```

upg-4608394

[binary]: https://github.com/odoo/odoo/pull/242043/changes#diff-d3cbb345d0a5855b7d7aa91e64a0ff480e3e5acfa3b2c71503a23ca7f3c0c511R132

The POS Avatax tour sporadically failed after returning from the payment screen. The race was reproduced locally by delaying the mocked Avatax response in mocked_request().

There's three somewhat related fixes.

Firstly, get_order_tax_details() calls sync_from_ui(), which emits a SYNCHRONISATION notification. Unlike the normal POS sync path, the Avatax RPC did not pass the device context. The browser therefore treated its own notification as coming from another device and started an independent reload of open orders.

That reload could replace the current order state after the tour returned to the product screen, causing the selected order line to disappear.

We now pass the normal sync context so the browser can properly ignore its own notification.

Secondly, we'll keep the complete sync_from_ui() response and replace its order, line, tax, and tax group data after the AvaTax calculation. We then simplify the processing client-side by moving towards the established pattern in the POS: missingRecursive() to load any other referenced records, and then pass that through loadConnectedData().

Lastly, clickPayButton() only waits for the payment screen element to be displayed. The AvaTax request starts from the screen's onMounted() callback, leaving a short window where the screen and its buttons exist but the request and UI blocker have not started yet. The next tour step can probably run during that window. To make sure this can't happen we explicitly waitRequest(). This first waits for requests to appear and then waits for them to complete.

runbot-error-944281

Forward-Port-Of: odoo/enterprise#125944

### Steps to Reproduce:
1. Create a sign request and have 3 total signers (User, Customer, Employee)
2. Enable Signing Order and make the order as follows: (1) User, (2) Customer, (3) Employee
But make the User and Employee the same contact
3. Send and sign the request > Notice that (1) is able to sign for (3) immediately after, (2) has not signed yet.

### Description of the issue/feature this PR addresses: 
**Issue:** The signing order is ignored when the same user has to sign multiple times on a document, even if it is configured for a different person to sign in between. This happens because all signature request items are initialized in the 'sent' state upon creation, rather than strictly advancing based on the order. As a result, the system prematurely allows users to sign out of order and prompts them with their next turn too early.

**Solution:** To resolve this,  the controller was updated to include an `is_mail_sent = True` domain filter. This ensures that the UI's post-sign popup only displays documents where it is explicitly the user's active turn, rather than prompting a premature sign.

### Current behavior before PR: 
Users are able to sign prematurely, and the system will disregard the configured signing order.

### Desired behavior after PR: 
Users will only be prompted and able to sign a document when it is explicitly their turn, per the `mail_sent_order`. This way, documents are signed in order.

opw-6417327

Forward-Port-Of: odoo/enterprise#128487
Forward-Port-Of: odoo/enterprise#125573

### Steps to Reproduce:
1. Go to the Website
2. Click on the Jobs section
3. Select any job
4. Click the Edit button
5. Select any text and click the AI button
6. Observe the error

### Description of the issue/feature this PR addresses: 
**Issue:** Opening the AI chat from a text selection on frontend records (ex. website Jobs pages) raises a "Missing Record" error referencing an unrelated hr.job record. The `res_id` sent from the frontend arrives as a string (e.g. "133"), and `action_launch_ai_chat` passes it directly into `browse()`. Since Python strings are iterable, `browse("133")` was interpreted as three separate ids ('1', '3', '3') instead of one id, causing an access check on a nonexistent record.

**Solution:** We can cast `res_id` to `int` before calling `browse()` in `action_launch_ai_chat`. This ensures that the id is treated as a single record reference instead of being unpacked one character at a time.

### Current behavior before PR: 
Selecting text and launching the AI chat on a record with a multi-digit id (e.g. 133) fails with `MissingError: Record does not exist or has been deleted. (Record: hr.job('1',), User: 2)`, which blocks the feature entirely for any id longer than one digit.

### Desired behavior after PR: 
The AI chat should correctly resolve and check access on the actual selected record (e.g. hr.job(133)). Ultimately, it should launche successfully, regardless of the length of the id.

opw-6443065