Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form `o-color-[n]` with n some integer)

Those colors are a bit special (see full discussion on the opw)
- Their existence is described in module `web`
- Their CSS definition is implemented in module `html_editor`
- Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#253115
Forward-Port-Of: odoo/odoo#251446

Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)

Those colors are a bit special (see full discussion on the opw)

    Their existence is described in module web
    Their CSS definition is implemented in module html_editor
    Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

see odoo/odoo#251446

opw-5892573

Forward-Port-Of: odoo/enterprise#110164
Forward-Port-Of: odoo/enterprise#109206

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

**Steps to reproduce:**
- Install Accounting

- From a Bank journal, create a transaction with an amount of -1000
- Set Account to "Liquidity Transfer"
- From a Cash journal, create a transaction with an amount of 999.99
- Set Account to "Liquidity Transfer"
- Create a MISC entry:

  |       Account        | Debit | Credit |
  | -------------------- | ----- | ------ |
  |  Liquidity Transfer  |  0.00 |  0.01  |
  | Cash Difference Gain |  0.01 |  0.00  |

- Post the entry

- From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them

- Go back to the Bank journal and try to edit the previous transaction

**Issue:**
A traceback is raised.

**Cause:**
In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved.
A single line is expected and some operations that are only allowed on a singleton are performed.
In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition.

**Solution:**
The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line.
Therefore, the computation can be skipped in such a case.

opw-6031879

Forward-Port-Of: odoo/enterprise#110857

Steps to reproduce the bug:
- Install voip and open the Odoo backend on Firefox
- Setup your voip settings
- Call your softphone number, thanks to your smartphone
- Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller.

This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*".

The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done).

Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists.

This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added.

[1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf
[2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0
[3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e
[4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850

task-5902700

Forward-Port-Of: odoo/enterprise#110833

Steps to reproduce the error :
==============
1. Go to Settings -> Technical -> Digest Emails
2. Open any Digest record
3. Click `Send Now` or `Test`
-> A traceback occurs.

Issue
=============
A previous refactor of Social UTM tracking:

- removed `source_id` from social.post and now stores post reference
  directly in link.tracker (utm_reference)
- removed `utm_medium_id` from social.account

The "Social Media Clicks" digest KPI computation still relied on
`social.post.source_id` and `social.account.utm_medium_id`.
Since these fields were removed, the SQL query fails with a
“column does not exist” error.

Fix
=============
Update the KPI computation to adapt to the new utm_reference logic

Note
============
If a post is posted across all companies, its clicks are
visible to all companies.
This is an expected limitation of the new utm_reference logic

See https://github.com/odoo/enterprise/commit/0058e409cd9ae4868bc8ed974f34f29d26c1f7df for more details

task-5960183

Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error

The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.

This commit improves error handling for both public and internal AI chat
by:

- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.

The following behavior will now be observed during error in the UI.

- Public AI chat:
  - Initial fetch failed: shows "oops" message
  - Stream interrupted:
    - Server handled: shows "oops" message
    - Server stopped: shows "Connection Interrupted" dialog

- Internal AI chat:
  - Initial fetch failed: show RPCError dialog
  - Stream interrupted:
    - Server handled: shows RPCError dialog
    - Server stopped: shows "Connection Interrupted" dialog

We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.

TASK-ID: 5886825

Forward-Port-Of: odoo/enterprise#105875

### Steps to reproduce:
	- Create a Overtime hours time off type
	- Create mutliple allocations with different start dates but no end date
	- Create some leaves for the created allocations one after each allocation start date
	- Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report.

### Cause:
After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery.

### Fix:
Following the same approach we use in  if
the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date

opw-5474596

Forward-Port-Of: odoo/odoo#254053
Forward-Port-Of: odoo/odoo#250432

When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging barcode
* Scan one of the lots
-> Issue, the lot create a new line, and will not find the packaging

### Observation:

When scanning a barcode, it will first try to find a match with existing lines,
In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501
It will erase the line, to avoid to overfill a completed line:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460
and since, it decided to ignore that line, it will not find another lines, and will create a new one :
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535

Additional Issues
-----------------
Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots.
Issue 2 :  When having sublines with different uoms, it will add the quantity without considering the differences in uoms

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Create a packaging 2 with barcode for product A
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging 1 barcode
* Scan one of the lot 1
* Scan packaging 1
* Scan lot 2
-> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot.
* Scan packaging 2
-> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms

### Observation:
Issue one :
When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460
and since, it found a line, it will just add it's self to the line

Issue Two:
When creating the group lines it will first calculate the sum of all the quantities:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254
And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461

opw-5189492
opw-5408372

Forward-Port-Of: odoo/enterprise#108666
Forward-Port-Of: odoo/enterprise#98701

__

## Short functional explanation of the error
When we create an invoice for a quotation that holds a timesheet product and recorded timesheets for last month.
In the wizard, we set the timesheet period from the first to the last day of last month.
Then, we set the `Invoicing Switch Threshold` to the day of last month. We record another hour for the timesheet, for this product, for today. When we select last month as timesheet period when creating a new invoice, the 2 hours that have already been invoiced are reinvoiced. Moreover, once we confirm this second invoice, it is possible to create again and again invoices for these already invoiced timesheets, without changing the Invoicing Switch Threshold parameter.

## Reproduction Steps
1. Create a quotation. Add as a line a timesheet product. Set the quantity to 2. Validate and click on the smart button Recorded.
2. Record 2 hours with a random date for last month.
3. Create an invoice. In the wizard, set the timesheet period to the first -> the last day of last month. Confirm, and on the invoice form,
 set the invoice date to last month  (after the day on which you
 recorded the timesheet hours) and confirm.
4. Click on configuration > settings. Search for Invoicing Switch Threshold, and set the date to the last day of last month.
5. Go back to the invoice you created. It should have the ribbon `Ìnvoicing App Legacy`.
6. Go back to the sales order. Click on the smart button Recorded and add one more hour to the timesheets, but this time in February.
7. Create an invoice. On the wizard, set the timesheet period to the first -> last day of last month. Click confirm.

### Expected behavior
The system shouldn't let us create an invoice, as we have nothing to invoice, as all the timesheets have already been invoiced.

### Unexpected behavior
An invoice is created with 2 hours. It doesn't take into account the hours added in February (normal) but reinvoices the timesheets that have already been invoiced (not normal).

## Origin of the issue
When retrieving the quantities to invoice for the timesheets, we don't take into account the quantities already invoiced for the same timesheet.

__
opw-5426434

Forward-Port-Of: odoo/odoo#250946

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

When the user sends a push notification through Social Marketing, the application displays two notification popups because:

1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field.
2. Our service worker displays a notification popup when receiving a background message from Firebase.

To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us.

Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications.

To fix that issue, we will:
1. Ensure that the service worker reaches the `ready` state before communicating with it.
2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page.

Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers.

Task-5124645

Forward-Port-Of: odoo/enterprise#110823
Forward-Port-Of: odoo/enterprise#96029

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

# Product Configuration
*Manufactured Product*
- Storable
- Tracked by Quantity
- Manufacture Route
- Has a BOM with atleast 1 component

*Component Product*
- Storable
- Tracked By Lot

# How to reproduce
- Ensure there is available stock for the component product in a lot
- Create a MO for the Manufatured Product
- Confirm the MO
- Click "Details" on the component product
- Remove the reserved quant and add a new one
- Increase the quantity of this new quant to more than "To Consume"
- Save
- Observe that "Consumed" = The quantity you just set on the quant
- Click on "Produce All"

# The issue
- The Consumed quantity is reset to the "To Consume" quantity.
- Furthermore, a warning popup should be displayed when clicking on "Produce All" but there is none.
- Finally, depending on the version you may get this error message : "You need to supply Lot/Serial Number for products and 'consume' them: - Component Product" even though a lot is already assigned

# Why
All these issues stem from the fact that move_raw_ids.picked from mrp.production is set to False instead of True.

This issue was introduced by this commit (https://github.com/odoo/odoo/commit/ef592464983d66ac76bc71a9886462f1f47dc28d) that changed the way the picked value is set.

In write(self, vals) de stock_move, we have :
```py
if self.env.context.get('force_manual_consumption') and 'quantity' in vals:
            moves_to_update = self.filtered(lambda move: move.product_uom_qty != vals['quantity'])
            if moves_to_update:
                moves_to_update.write({'manual_consumption': True, 'picked': True})
```
Followed a bit later by :
```py
res = super().write(vals)
```

This usually works fine except when vals contains edition commands for move_line_ids. Then, the first write will correclty set picked to True, but then picked will be reevaluted after the second write with :
```py
@api.depends('move_line_ids.picked', 'state')
    def _compute_picked(self):
        for move in self:
            if move.state == 'done' or any(ml.picked for ml in move.move_line_ids):
                move.picked = True
            else:
                move.picked = False
```

If all the resulting move_line_ids from the commands edition have picked set to False, then move.picked will also be set to False.

opw-5937171

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

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#105115

Steps to reproduce:
- Activate the GS1 nomenclature
- Create a product "P1" with the barcode: 15099590225865
- Create an internal transfer with one unit of P1
- Go to Barcode > Operations > Internal Transfers
- Scan the barcode: 15099590225865 to filter transfers by this product barcode

Problem:
An validation error is raised:
A ValidationError is raised:
"A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date."

Explanation:
GS1 barcodes must follow a strict nomenclature based on well-defined rules.
For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits.

The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError.

Solution:
Catch the ValidationError raised during GS1 date parsing in   filter_on_barcode
and explicitly reset parsed_results to False, allowing the normal filter
on product resolution logic to continue. This prevents GS1 parsing errors
from blocking valid barcodes and ensures that product is correctly filtered

opw-5929064

Forward-Port-Of: odoo/enterprise#110679
Forward-Port-Of: odoo/enterprise#110636

## ISSUE 1:
**Steps to reproduce [l10n_be easier]:**
- Create a journal entry:
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
 > account 600
 tax 12% (purchase)
- Validate
- Check the last entry created

**Issue:**
There is no invert tag set on the tax line

**Cause:**
The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815
The line was never set to properly (same of is_refund)

## ISSUE2:
**Steps to reproduce:**
- create a journal entry
```
440 : supplier			0 		300			False
499 : suspense account		300		0 			False
```
- Accounting > Reconcile: select the entry and in the wizard
> account 600
tax 21% EU M (Purchases)
- Validate
- Check the last entry created

**Issue:**
No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0.

opw-4976780

Forward-Port-Of: odoo/enterprise#93839
Forward-Port-Of: odoo/enterprise#92556

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#105115

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

**Problem:**
compensation amls are not created for dropshipped 
products when there is a difference between the 
price of the PO and the price on the bill

**Context:**
For non dropship avco real time products: 
When you create a PO for a product @ 10
- stock interim received is credited of 10
- stock valuation is debitted of 10

And you then validate a bill for a price of 8
- stock interim received is debitted of 8
- account payable is creditted of 8

This leaves stock interim received with credit of 
2 and stock valuation is over valued by 2. 
So we create 2 extra account move lines 
- One debit of 2 for stock interim received
- One credit of 2 for stock valuation (or Expenses 
if the product is not in stock anymore because then 
it's the expense account which was over valuated)
nb: if the product is still in stock those 2 lines are 
created via stock valuation layer

In the case of a dropshipped product, the product 
is not in stock anymore so it should be creditting 
expense, but no extra amls are created at all.

**Steps to reproduce:**
- enable the "dropshipping" and "anglo saxon accounting" 
settings
- create a storable product with avco automated category
- in the inventory tab, select the dropship route
- in the purchase tab, set a vendor
- create and a confirm a quotation for this product
- on the linked purchase order, set a unit price of 10$ and 
confirm
- validate the dropship move
- create a bill for the purchase order
- set the price to 8$ and confirm
- navigate to journal items and search for your product

**Current behavior:**
no compensation account move lines were created

**Expected behavior:**
2 account move lines should have been created: 
- One debitting 2 in stock interim received
- One creditting 2 in expense

**Cause of the issue:**
*the following logic was introduced by* https://github.com/odoo/odoo/pull/126536
to create those extra amls and layers, 
_apply_price_difference() is called inside _post()
https://github.com/odoo/odoo/blob/32408a8dea43f57bba1a56c775ae228131720749/addons/purchase_stock/models/account_invoice.py#L129

There we have 2 problems : 

Problem 1: When fetching the layers linked to the account move line, 
we fetch both the incoming and the outgoing valuation 
layers because they are both linked to the dropship move. 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L46
But we only want the incoming layer because the outgoing 
layer should not interfere with the bill.
nb: In a standard case like the one of the steps to reproduce, 
it would work to leave both layers, but : 
- it works for the wrong reasons : the quantity of the aml would 
first be consumed on the incoming 
layer and nothing would happen with the second layer as the 
quantity of the incoming layer is the same as the one of the aml.
- it would probably break in more complex use cases.

So it feels unnecessarily risky to leave it like that.

Problem 2: Inside _generate_price_difference_vals we call _replay_history
which returns two values that are assigned to two variables. 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L82
The second variable, layers_and_invoices_qties is a default dict
which keys are tuples (layer L, invoice I) mapped with [the initial 
quantity invoiced by I on L, the remanining qty invoiced by I on L]
(here 'remaining' is related to invoice and has nothing to do with stock qties)
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L168-L171

So in our very basic use case, with a single invoice and a single layer, 
we should have a key (our layer, our invoice) linked 
to the value [1,1].
But this key is not in the dictonary. 

*The reason is the following :* 
inside _replay_history the parameter "history"
contains the layers and the amls (in our case 
1 layer and one aml which is self). 
Each layer is added to qty_to_invoice_per_layer
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L177-L178
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L191-L192

Then, for each aml: the layers are added to 
layer_to_consume, alongside their remaining 
quantity.
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L215-L221
And for each layer which has a quantity billed
by the invoice, a key is added to layers_and_invoices_qties
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L222-L231

In our case, the move linked to the layer is the
dropship move so _is_in() will be false and 
the layer won't be added to layers_to_consume.
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L220-L221
So the key will not be created.

*The consequence is the following:*
Later in _generate_price_difference_vals() we acces the value 
of this key (the key that should be there (layer, invoice)) 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L91
to get the invoiced qty which will later be used to determine which 
quantity is still in stock and which is out of stock (giving us 
the quantities for the compensation layers and amls) 
but as the key does not exist, invoicing_layer_qty will have a value of 0 
so we will exit the loop and no amls or svls will be created
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L92-L93

opw-5498878

**Description of the issue/feature this PR addresses:**
When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note, resulting in unnecessary blank space in the activity card.

**Current behavior before PR:**
Even when the activity description is cleared and contains only empty HTML, the activity note container is still rendered, leaving visible empty space in the UI.

**Desired behavior after PR is merged:**
The activity note is rendered only when it contains meaningful content. Empty HTML descriptions are ignored, preventing blank space from appearing in the activity card UI.

Before
<img width="445" height="84" alt="image" src="https://github.com/user-attachments/assets/f6648bb0-78d9-4063-a347-fe664370106e" />

After
<img width="459" height="72" alt="image" src="https://github.com/user-attachments/assets/84c2063a-7c68-4dfe-b729-566ca4b5dcd1" />

task-[4752613](https://www.odoo.com/odoo/project/1519/tasks/4752613)

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

At install, the `auth_oauth` module adds `oauth_access_token`
to the constant list `base.models.res_users.USER_PRIVATE_FIELDS`.

At uninstall, it doesn't get removed automatically,
it stays in the list until a server restart or a worker
reload.

This causes problem when other/custom modules also add fields
to this `USER_PRIVATE_FIELDS` and then perform a read
with one of these private fields.
in `odoo/addons/base/models/res_users.py` in the method `def _fetch_query`
`self.env.cache.update(records, self._fields[fname], repeat('********'))`
raises a crash as it tries to access `self._fields['oauth_access_token']`
while it no longer exist.

Actually it's also a multi-tenant problem: If one database installs the
`auth_oauth` module on the server, `oauth_access_token` is added to the list
`USER_PRIVATE_FIELDS` for all databases, not just the one which installed
the `auth_oauth` module.

The solution is to convert this list with a property method,
and override that property method in `auth_oauth` to add
`oauth_access_token` when the module is installed.
It also solves the multi-tenant issue.

Steps to reproduce:

- Use this diff to add temporary a private field
```diff
diff --git a/odoo/addons/base/models/res_users.py b/odoo/addons/base/models/res_users.py
index 2c8da7ec529c..ac973205e6ef 100644
--- a/odoo/addons/base/models/res_users.py
+++ b/odoo/addons/base/models/res_users.py
@@ -87,7 +87,7 @@ class CryptContext:

  # Only users who can modify the user (incl. the user herself) see the real contents of these fields
-USER_PRIVATE_FIELDS = []
+USER_PRIVATE_FIELDS = ['login']
  MIN_ROUNDS = 600_000
  concat = chain.from_iterable
```

- Start the server, preferably in threaded mode rather than worker mode
- Then, in the web interface, install and uninstall `auth_oauth`
- Then, using RPC, do a read on `res.users` with `login` as field

```py
import xmlrpc.client
URL, DB, UID, PASSWORD = 'http://localhost:8069', '17.0', 6, 'demo'
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(URL))
print(models.execute_kw(DB, UID, PASSWORD, 'res.users', 'read', [[1], ['login']]))

```

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 2410, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1985, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 153, in retrying
    result = func()
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 2013, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 2217, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 799, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 25, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 21, in _call_kw
    return call_kw(Model, method, args, kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 484, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 469, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 1913, in read
    res = super(UsersView, self).read(other_fields, load=load)
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 645, in read
    return super(Users, self).read(fields=fields, load=load)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3583, in read
    self._origin.fetch(fields)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/res_users.py", line 551, in _fetch_query
    self.env.cache.update(records, self._fields[fname], repeat('********'))
KeyError: 'oauth_access_token'
```

opw-6042456

Forward-Port-Of: odoo/odoo#254387

**Issue:**
- When opening the full composer from the chatter, the body of the default email
template is not loaded. Only the subject line from the template appears,
while the body remains empty or contains only the user's signature.

**Steps to reproduce:**
1. Install `contact`
2. Open any contact form.
3. In the chatter, click 'Send message' and then expand button
4. Write a something in body, then save this as a new template.
5. Set this new template as the default (using Debug Mode > Set Default Values).
6. Click 'Send message' in the chatter,
7. Click the 'Full composer' (expand) button without typing anything.

**Observed behavior:**
- The full composer opens with the correct subject from the default template,
but the body is empty.

**Cause:**
- The `onClickFullComposer` method always passes a `default_body` value
in the context to the mail.compose.message wizard. Even if the chatter input is empty

**Solution:**
- Forward isBodyEmpty in the context from onClickFullComposer.
If the user typed content, do nothing. If the body is empty and a default template is available,
allow the backend to apply the default template by removing default_body.

opw-5405056