This error occurs while entering the barcode number.

Steps to reproduce:
---
- Install `stock_barcode` module(without demo)
- Setting > Barcode > Set Barcode Nomenclature = `Default GS1 Nomenclature`
- Barcode > click on `Scan or tap` > Enter a barcode(barcode number should startwith `urn` (eg: "urn:epc:tag:sgtin-96 : 3.0614141.038656.0")) > Apply

Traceback:
---
`KeyError: 'rule'` (with GS1 Nomenclature)
`AttributeError: 'list' object has no attribute 'get'`  (without GS1 Nomenclature)

At [1], we expect the key `rule` to be present in the result, but this key is never set in the return statement at [2]. Since [1] also relies on the result’s type, a new key value `type` has been added in this [commit] to address that.

This commit ensures that the correct keys are passed in the result dictionary.

[1]- https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/stock_barcode/controllers/stock_barcode.py#L29-L31

[2]- https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/barcodes/models/barcode_nomenclature.py#L174-L189

[commit]: https://github.com/odoo/odoo/commit/1394fa161a6fcf77b4443cbf784ad7dd635e7f9e#diff-be2a58d0591614180295c070396ff487f4bc04bf33aad2829d7bfab4671a792cR60

sentry-6992944243

Forward-Port-Of: odoo/enterprise#98761

## Issue:
When creating a Global Invoice with a non-admin user (e.g., demo), an Access Error was raised:
`Sorry, you are not allowed to access this document`

## Cause:
This commit change the attachment creation to use the SUPERUSER: https://github.com/odoo/enterprise/pull/95197
However, updating `attachment.res_id` then required `base.group_system` access rights, preventing regular users from modifying the attachment
As a result, non-admin users (like demo) triggered an access error during Global Invoice creation

## Steps to reproduce:
- Switch to the MX company
- Create a product with an UNSPSC Category (Accounting Tab)
- Create and Confirm an Invoice for the product (enable CFDI to public)
- Connect as Demo
- Go in Accounting > Customers > Invoices
- Toggle the last created invoice checkbox
- Actions > Create Global Invoice
- Before the fix, the Access Error is displayed
- Check in the invoice Chatter for the Global CFDI document creation success

opw-5181925

Forward-Port-Of: odoo/enterprise#98218

Steps to reproduce:
===================
- Connect Unsplash to your database
- Add a snippet on your website page like "Feature wall" for example
- Double click on an existing image
- type at least two words separated by a space like "Sleeping cat"
- select any image from the list.
- Add a shape to this image -> Traceback

Cause:
======
When an image is chosen from Unsplash using a multi-word search, its URL contains encoded characters (e.g., `%20` for a space).

The image processing utility was extracting the `pathname` directly from the image's URL. This path, however, remained URL-encoded. This encoded path was then used in a subsequent RPC call to fetch the original image data before applying the shape.
https://github.com/odoo/odoo/blob/b9435baa1948f54e19f2dd5702a39d073e8eb57d/addons/html_editor/static/src/utils/image_processing.js#L204

This caused the fetch operation to fail, returning an `undefined` value. The attempt to apply a shape to this `undefined` result is what triggered the traceback.

Solution:
=========
The `srcUrl.pathname` is now wrapped in `decodeURIComponent()`.

This function correctly decodes URL-encoded sequences (like `%20`) back into their original characters before the path is sent to the server. The backend now receives a clean, valid path, resolving the traceback.

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

If a user sends a message to an ai agent and then closes the chat channel before receving the response,
- For AI composer channels (channels opened through AI chatter button) an error occurs.
- For other AI channels, A new ai chat channel gets created and the response is posted to that channel instead of the deleted one.

Cause of the Issue :
When the channel is deleted, a serialization error occurs because one transaction is trying to delete the channel while the other is trying to post the ai response to the channel.
The delete transaction finishes execution and the response generation transaction is retried.
- For AI composer channels some fields of the deleted channel are accessed inside `_ai_add_message_to_context` and `_ai_create_response` which raises an error.
- For other AI channels, when generate_response is retried,_get_or_create_ai_chat is called and given that the old channel has already been deleted, a new one is created and the response is posted to that channel.

Note: No issue will happen if the response generation transaction is executed and the deletion transaction is retried, because it will delete the channel after the response was posted which is a normal behavior.

task-5063221

Forward-Port-Of: odoo/enterprise#93877

**Issue**
When a subscription order line is deleted after being invoiced, attempting to create a new invoice for the subscription raises a UserError about UoM category mismatch.
Video: https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view

**Steps to Reproduce**
1. Create and confirm a subscription with a recurring product (e.g., Car Leasing)
2. Generate and post the invoice for the subscription
3. Add a new product line to the subscription (e.g., Office Cleaning Service)
4. Delete the original invoiced line (Car Leasing)
5. Attempt to create an invoice for the new product line
→ Error: "The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category."
(https://drive.google.com/file/d/11-CV7wcEHQJFoVEQM5o5YBkZuTXPYDqL/view)

**Root Cause**
Commit https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 introduced quantity tracking per period in _get_max_invoiced_date() to fix partial credit note handling. The implementation accesses `sale_line_ids.product_uom` assuming sale_line_ids is always populated. However, when a sale order line is deleted, the related account.move.line remains in the system with empty sale_line_ids. Accessing `sale_line_ids.product_uom` on an empty recordset returns False, causing the UoM validation to fail during invoice creation.

**Fix**
Add a fallback to use the invoice line's own product_uom_id when sale_line_ids is empty. This preserves the partial credit note fix from https://github.com/odoo/enterprise/commit/22e49fca1e0fbfefac974c562491d170b8d70025 while handling the edge case of deleted subscription lines. If no valid UoM is found, the line is skipped in the calculation.

Forward-Port-Of: odoo/enterprise#99497
Forward-Port-Of: odoo/enterprise#99231

This commit reverts PR [1] which attempted to fix an issue with grouped list views with sample data. The issue occured when the web_read_group returned real groups that are all empty. When this happened, the model kept and relied on the real groups information, in particular which groups are open ("folded" flag).

In kanban, this works fine because we use those real groups in the sample server, and populate them with sample records. However, we didn't do that for the list view, for an obscure reason. As a consequence, in list, we sometimes received sample groups that matched the real ones (same id, when grouped by many2one), so we re-used the real group information (i.e. the folded flag). We were then manipulating groups that we believed to be open, i.e. to have a `records` key, whereas the fake read group done by the sample server returned groups without that `records` key, leading to a crash.

PR [1] tried to fix web_read_group in the SampleServer, to take into account the `opening_info` and return a `__records` key for opened groups. However, the fix crashed if there were more open real groups than sample groups (i.e. 5).

This commit fixes the issue by generalizing the kanban logic to the list, i.e. by moving it to the RelationalModel. From now on, both kanban and list will use the real groups, and fill them with sample data if necessary.

In master, we'll go even further by allowing to manipulate those groups (e.g. edit, create new...) like we do in kanban.

[1] https://github.com/odoo/odoo/pull/226253

Issue reported on the feedback pad after migrating odoo.com to v19

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

### Steps to reproduce:
	- Create a sale order with a SOL and an optional product
	- Preview the sale order and add the optional product to the order
	- Go back to edit mode and change the pricelist
	- Click on 'Update Prices'
	- Notice the optional product price won't change

### Cause:
When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation.

If sale_subscription is installed we will set the product's prices to 0 

https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 

so the price of the 'Optional product' SOL will change but will be equal to 0

### Fix:
An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed

opw-5058609

Forward-Port-Of: odoo/odoo#234968
Forward-Port-Of: odoo/odoo#230053

Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill.
```
The validation failed with the following errors:
The reference document UUID [...] does not exist.
The internal ID for DocumentUUID [...] does not match.
```

Steps to reproduce:

- With an MY company setup
- Create a bill and add a custom reference
- Send Bill to MyInvois
- Create credit note for the Bill
- Send Credit note to MyInvoice

Issue:

Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used.

Analysis:

A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice.

opw-5057050

Forward-Port-Of: odoo/odoo#234762
Forward-Port-Of: odoo/odoo#234199

# Description of the issue/feature this PR addresses:

Currently, the constraint `account.account._check_account_type_unique_current_year_earning` raises a validation error when there are more than one accounts of type "Current Year Earnings" in the same company. This is expected behaviour.

However, the ORM will throw an exception if it finds two or more accounts of this type across multiple inactive companies. Example:

```sql
lare_3183476=>
    SELECT COUNT(account.id), account.company_id, company.active
      FROM account_account account
      JOIN res_company company
        ON account.company_id = company.id
     WHERE account.account_type = 'equity_unaffected'
  GROUP BY account.company_id, company.active;
 count | company_id | active
-------+------------+--------
     1 |          1 | t
     1 |          2 | f     --
     1 |          3 | t
     1 |          4 | f     --
     1 |          5 | t
     1 |          6 | t
(6 rows)
```

# Current behavior before PR:

When the above constraint retrieves accounts of type "Current Year Earnings" grouped by their companies, those records belonging to inactive companies are grouped together into an "empty" company, res.company(). This raises an exception due to the definition of the constraint even though the accounts belong to a different company, and therefore, don't break the condition.

# Desired behavior after PR is merged:

To address this issue, we will modify the context of the environment to consider inactive records in the search by disabling the flag `active_test`. Since only two models are involved in the query, and account.account doesn't have a field for active records, this addition will correctly group the accounts in their correct company.

---

upg-3185680
upg-3143424

Thanks to @jlom-odoo for providing initial insights on the problems as well as additional examples.

---

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/18.0/addons/l10n_mx/migrations/2.2/end-migrate.py", line 7, in migrate
    env['account.chart.template'].try_loading('mx', company, force_create=False)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 160, in try_loading
    return self._load(template_code, company, install_demo, force_create)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 228, in _load
    self._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/enterprise/18.0/account_reports/models/chart_template.py", line 10, in _post_load_data
    super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/18.0/addons/stock_account/models/account_chart_template.py", line 12, in _post_load_data
    super()._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 681, in _post_load_data
    self._setup_utility_bank_accounts(template_code, company, template_data)
  File "/home/odoo/src/odoo/18.0/addons/account/models/chart_template.py", line 874, in _setup_utility_bank_accounts
    self.env['account.account']._load_records([
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5503, in _load_records
    data['record']._load_records_write(data['values'])
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 1103, in _load_records_write
    super()._load_records_write(values)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5421, in _load_records_write
    self.write(values)
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 1036, in write
    res = super(AccountAccount, self.with_context(defer_account_code_checks=True, prefetch_fields=not any(field in vals for field in ['code', 'account_type']))).write(vals)
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 343, in write
    return super(MailThread, self).write(values)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4830, in write
    real_recs._validate_fields(vals, inverse_fields)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/18.0/addons/account/models/account_account.py", line 42, in _check_account_type_unique_current_year_earning
    raise ValidationError(_('You cannot have more than one account with "Current Year Earnings" as type. (accounts: %s)', [a.code for a in account_unaffected_earnings]))
odoo.exceptions.ValidationError: You cannot have more than one account with "Current Year Earnings" as type. (accounts: [False, False])
```

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

Forward-Port-Of: odoo/odoo#231708

[FIX] purchase_mrp, sale_purchase_stock: track kit bom when receiving without pull rule

Problem:
If an inventory workflow is completed without any pull rules (only Push or Buy), then `bom_line_id` is never set on the sale order line. The result has two primary impacts: `qty_received` will not be updated upon final transfer, and the COGS line on the invoice will be calculated using the incorrect method, with an incorrect result.

Solution:
Upon confirming a Purchase Order, when the picking is being created, we will try to assign the `bom_line_id` on the Sale Order Line if:
	1. The PO is attached to a Sale Order
	2. The SO line is for the kit
	3. The product on the PO line is component of the BOM for that kit
With the `bom_line_id` assigned on the SO line, `qty_received` will be calculated correctly for kits, and COGS lines on the generated invoice will also be calculated correctly based on the kit.

Steps to Replicate (Runbot 18)
- 2-step receipt, 2-step delivery
- Cross-Dock enabled
- Kit item, fifo auto
	- No routes enabled on kit
	- Two components, fifo auto
		- Enable Buy and Cross-Dock routes
		- Set a vendor and non-zero price

1. Create a sale order for the kit and sell for non-zero price, confirm
2. Confirm the PO
3. Validate the pickings
	1. Receipt
	2. Cross-Dock
	3. Delivery
4. Go back to the sale order, note the first issue of 0 quantity delivered
5. Create an Invoice
6. Confirm the invoice, note the second issue of the COGS lines being triple the total purchase price

opw-5139590

Forward-Port-Of: odoo/odoo#235818
Forward-Port-Of: odoo/odoo#233132