**Problem:**
the default account suggested for landed cost (with 
real time category) are not the good ones.

**Steps to reproduce:**
- create a storable product with perpetual average category
- create a landed cost (a service product with 'is a 
landed cost' checked in the purchase tab)
- create a category for the landed cost with perpetual valuation
- confirm a purchase order for 10 quantity of the product with a 
unit price of 10
- validate the receipt
- confirm quotation for 3 of the product, validate the delivery and 
confirm the invoice
- create a bill for the purchase order
- on the invoice lines, unhide the product column
- add an invoice line with the landed cost product, for a quantity 
of 1 and a price of 10
- confirm the bill
- click on create landed cost 
- select the receipt in the transfers field
- validate
- click on the journal entry on the landed cost form

**Current behavior:**
On the bill, for the landed cost : 
- stock valuation is debited of 10
- account payable is credited of 10 (which makes the total 
credit 110 for account payable)

On the journal entry linked to the landed cost: 
- stock valuation is debited of 7 
- stock valuation is credited of 7

So in total there is a debit of 10 in stock valuation and 
a credit of 10 in account payable.
Which does not reflect that part of the products are out 
of stock. 

**Expected behavior:**
If the expense account was used, both on the bill and on 
the landed cost, (which is already the case for landed cost
with periodic category) the account move lines would be: 

On the bill : 
- Expense is debited of 10
- account payable is credited of 10 (which makes the total 
credit 110 for account payable)

On the journal entry linked to the landed cost: 
- stock valuation is debited of 7 
- Expense is credited of 7

So in the total there is : 
- a credit of 10 in account payable
- a debit of 7 in stock valuation
- a debit of 3 in expense

This is what we want, because the debit of 7 in stock valuation 
reflect that we only increase the valuation by 7 because only 7 
products are still in stock. 
The debit of 3 in expenses compensate for the cogs. Indeed 
when we invoiced the SO, the cogs where of 30 but, after the landed
cost, valuation wise, the products actually exited the stock with a 
value of 33 total (11 each).

**Cause of the issue:**
For the bill: 
when you create the new account move line and enter the product, 
_compute_account_id is called to compute the default account 
for the line. 
In the stock override, _eligible_for_stock_account is called on the line
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_account/models/account_move_line.py#L18-L19
Because of the stock_landed_costs override, the return value is true
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_landed_costs/models/account_move.py#L78-L82
So the account is changed to stock valuation
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_account/models/account_move_line.py#L23-L24

For the landed cost: 
- if we create it by selecting 'create landed cost' on the bill : 
the account id is set in button_create_landed_cost
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/stock_landed_costs/models/account_move.py#L34
-if we create the landed cost, from adjustment/landed cost and 
selecting new : the expense account is already selected


**fix:**
In both cases, the client can already manually set the 
accounts they want, the fix is about having the right 
default accounts. 

opw-5941753

Forward-Port-Of: odoo/odoo#253430
Forward-Port-Of: odoo/odoo#251766

In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store.

This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation.

Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents).

task-4038651

Forward-Port-Of: odoo/enterprise#78742

# How to reproduce
- Create a BOM for a product
- Create a MO for a set quantity (Exemple: 1) for that product
- Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3)
- Confirm the unbuild
- Go to the stock moves of that unbuild via the smart button

# The problem
3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated

# Why
The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves.

When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected.

This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'.

opw-5915981

opw-5449109

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

Forward-Port-Of: odoo/odoo#248056

Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient.

### Steps to reproduce

1. Drag and drop multiple files into a WhatsApp Discuss channel.
2. Send the message.

-> Odoo shows all files, but only the first reaches the destination.

### Cause

WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest.

### Fix

Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss.

opw-5889035

Forward-Port-Of: odoo/enterprise#107424

Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient.

### Steps to reproduce

1. Drag and drop multiple files into a WhatsApp Discuss channel.
2. Send the message.

-> Odoo shows all files, but only the first reaches the destination.

### Cause

WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest.

### Fix

Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss.

opw-5889035

Forward-Port-Of: odoo/enterprise#107424

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a
Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P
-> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110
It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246
This calls `_set_quantity_done_prepare_vals` with a qty of 2:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264
which will, for each move line:
- Take the quantity indicated by move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327
Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that move lines being created in mrp without changing the producing quantity are manually created

opw-[5946439](https://www.odoo.com/web#id=5946439&view_type=form&model=project.task)

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a
Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P
-> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110
It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246
This calls `_set_quantity_done_prepare_vals` with a qty of 2:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264
which will, for each move line:
- Take the quantity indicated by move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327
Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that move lines being created in mrp without changing the producing quantity are manually created

opw-[5946439](https://www.odoo.com/web#id=5946439&view_type=form&model=project.task)

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

When accessing the accounting module's dashboard on a new database, the bills widget displays the option to "try our sample" bill, which will create a contact record (Deco Addict), several products and categories, and a vendor bill with this newly created demo data prepopulated. This option to "try our sample" not only exists on the bills widget in the Accounting dashboard on a fresh database, but exists in the bills list view if either there are no bills in the database, or if a search filter
 is applied such that the result set is empty.

The implementation is problematic for two reasons:
1. It is not made clear to the user that several database models will be populated with demo data.
2. The "try our sample" button is presented to users outside of its intended context.

The current implementation does not clearly communicate to the user that they will be creating real demo records in several models on their database, which would obviously pollute a production database. Being that we provide an explicit warning when demo data is enabled for the whole database, a similar confirmation seems appropriate in this case, which has been added. Additionally, it does not seem appropriate that the "try our sample" option should be present in the list view. This is because its intent is to allow the user to try the bill functionality in the case that their database does not have any data. When a user is in the list view, more often than not will users who have applied an invalid search filter on existing data be shown the option, rather than new users on a new database. This can cause accidental addition of demo data. By only presenting the option only in the dashboard widget, it is far more likely that this prompt is shown only in the intended context.

Enterprise PR:
https://github.com/odoo/enterprise/pull/93352
opw-4959767

When accessing the accounting module's dashboard on a new database, the bills widget displays the option to "try our sample" bill, which will create a contact record (Deco Addict), several products and categories, and a vendor bill with this newly created demo data prepopulated. This option to "try our sample" not only exists on the bills widget in the Accounting dashboard on a fresh database, but exists in the bills list view if either there are no bills in the database, or if a search filter
 is applied such that the result set is empty.

The implementation is problematic for two reasons:
1. It is not made clear to the user that several database models will be populated with demo data.
2. The "try our sample" button is presented to users outside of its intended context.

The current implementation does not clearly communicate to the user that they will be creating real demo records in several models on their database, which would obviously pollute a production database. Being that we provide an explicit warning when demo data is enabled for the whole database, a similar confirmation seems appropriate in this case, which has been added. Additionally, it does not seem appropriate that the "try our sample" option should be present in the list view. This is because its intent is to allow the user to try the bill functionality in the case that their database does not have any data. When a user is in the list view, more often than not will users who have applied an invalid search filter on existing data be shown the option, rather than new users on a new database. This can cause accidental addition of demo data. By only presenting the option only in the dashboard widget, it is far more likely that this prompt is shown only in the intended context.

Community PR:
https://github.com/odoo/odoo/pull/224328
opw-4959767

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

Use `with_context(prefetch_fields=False)` when evaluating `filtered('email_normalized')` to prevent the ORM from prefetching a large group of fields. This avoids fetching heavy fields such as `description` for the whole batch, as by default all the stored fields share the same prefetch group.
which could lead to excessive memory usage and `MemoryError` during recomputation.

```sql
apan_3928644=> select pg_size_pretty(sum(pg_column_size(description))) from crm_lead where description is not null;
 pg_size_pretty
----------------
 18 GB
(1 row)
```

MemoryError faced with target db:
```py
File "/home/odoo/src/odoo/17.0/addons/crm/models/crm_lead.py", line 465, in _compute_email_domain_criterion
    for lead in self.filtered('email_normalized'):
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6166, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6166, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6165, in <lambda>
    func = lambda rec: any(rec.mapped(name))
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6142, in mapped
    recs = recs._fields[name].mapped(recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1293, in mapped
    self.__get__(first(remaining), type(remaining))
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
    self.fetch(fnames)
  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/models.py", line 3967, in _fetch_query
    rows = self.env.cr.fetchall()
MemoryError
```




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

ISSUE:

When generating product variant combinations, the cartesian product algorithm enters an infinite loop whenever the attribute lines follow the pattern: non-empty → empty → non-empty. In this case, the DFS backtracking logic incorrectly returns to the empty middle line, which always forwards execution to the next line instead of propagating the backtrack upward. This causes the search to oscillate between the empty line and the deeper non-empty line, never allowing the first line to advance to its next value and repeatedly yielding the same combinations.

FIX:

This fix introduces a minimal, localized change: during backtracking, the algorithm now skips backward over empty attribute lines until it reaches a line that actually has selectable values (or reaches the root). This preserves all existing behavior, avoids altering the core iteration logic, and ensures that the DFS always makes progress and terminates properly.

The change avoids modifying exclusion logic or altering the order of generated combinations. It simply ensures that empty intermediate lines do not trap the state machine in a loop.

opw-5231175