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

**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 pull request introduces a new Odoo module, which adds support for compliant electronic delivery guides (e-Remitos) for Uruguay, integrating with the EDI system and enhancing stock picking operations. The main changes include configuration for managing and generating e-Remitos according to Uruguayan fiscal requirements.

**Steps to create an e-Remito**

1. Install l10n_uy_edi_stock
2. Create a new delivery order.
3. Select a value for the field "Type of Operation". This will indicate that we are creating the electronic document, and also add a tab named "UY EDI" with some configurations for the e-Remito.
<img width="1231" height="585" alt="image" src="https://github.com/user-attachments/assets/c4c0baa8-8f9b-4453-b0c0-ce1b1503c536" />

<img width="1211" height="565" alt="image" src="https://github.com/user-attachments/assets/c827f787-27ed-4d55-a660-42a6b617e7df" />

The field "Addenda and disclosures" works as in invoices, the user will be able to select the addenda to add to the e-Remito report. 
The field "EDI Reference" is used to indicate that the e-Remito is a correction of another, so it will suggest previous e-Remitos made for the same partner, and it will add "Correction of e-Rem XXX" on the addenda.

4. Validate the delivery order and click on "Create Delivery Guide" button. This will send the document to DGI for validation and add the PDF returned by Uruware. 
<img width="1705" height="618" alt="image" src="https://github.com/user-attachments/assets/8bb36b08-ab08-4240-b3bb-f593a7f2a462" />



Odoo Task 1334
Adhoc Task 53147

Forward-Port-Of: odoo/enterprise#89706

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

The Work Entry Type form view needed to be refactored.
The form view is now split into new groups (computation, display,
exports code, benegit eligibility and description).

Tooltips and placeholders have been added to avoid further confusion of
the fields, and some naming repetition has been removed (e.g.: "Partena
Code" under the "Exports Code" group).

Some hidden columns and some filters have been added to the list view.
Here is a visualization of all the visual changes that needed to be
done:
https://app.excalidraw.com/l/65VNwvy7c4X/4LJSOZo8W3D

`_is_unforeseen` (and anything related to it) has been deleted, since it
was not used anywhere.

After the UI cleanup, some views became unused. I had to remove them in migrations.

`is_leave` (and its mirrror, `is_work`) are redundant, especially now
that we want to use a selection field instead. So I had to remove them
both and replace every single one of their occurences in the code by a
new selection field named `category`.
A migration making sure `category` reflects the old `is_leave` needed to
be put in place.

Due to having to do some back and forth in how to handle `is_work`, I
found some issues (unused file, bad `querySelector`, etc.) with the
`boolean_radio` widget. Fixes of this widget are thus included in this PR.

task-5162567

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

By running the test_sign_flow tour as a regular user, a typo is detected by the tests in the sign.send.request wizard.
The issue is that, on the model `res.partner`, the field `user_id` is the Salesperson associated to this Contact, whereas the field `user_ids` contain the `res.users` that inherit this Contact, and `main_user_id` is the most appropriate User of `user_ids` when we need only one.

When testing as admin, all fields are the admin user, whereas when testing as Laurie Poiret (or any regular user), the Salesperson is still the admin while `main_user_id` is Laurie Poiret.

A regular user can access only its own `sign_signature` field, while an administrator can access the `sign_signature` of all users, so this bug remained undetected:

On a runbot, log in as `admin` to change the sales person of Marc Demo to Mitchel Admin, then log in as `demo` and click on "Sign Now" on the `Rental_Agreement.pdf` template.

    You do not have enough rights to access the field "sign_signature" on User (res.users). Please contact your system administrator.

    Operation: read
    User: 5
    Groups: allowed for groups 'Role / Administrator'

Forward-Port-Of: odoo/enterprise#99408

_
## Short functional explanation of the error
Let's say a customer buys 2 products. An SO is created. This customer wants to refund only one of the 2 products. He sends a ticket to helpdesk and we click on refund. Even if we specify the product to refund, this action creates a credit note containing both products (previously present on the SO) instead of only the one to refund.

Additionally, when selecting the product, we could see in the dropdown of suggestions all the existing products, instead of only the ones related to the SO.

## Reproduction Steps
1. Create a SO containing 2 different products and confirm it.
2. Create a regular invoice and confirm.
3. Go to Helpdesk. Click on the configuration tab, and helpdesk teams.
4. Click on your helpdesk team, scroll down. In After-Sales, check "Refunds".
5. Create a ticket and specify the customer who wants to refund. Make sure the correct helpdesk team is assigned.
6. Click on refund. It opens the wizard. Specify the product to refund and the Invoices to Refund.
7. Click on reverse.

### Expected behavior
A credit note containing only the specified product to refund should be created.

### Unexpected behavior
The created credit note contains both products originally present on the SO.

## Origin of the issue
When issuing a refund from helpdesk_stock_account, this piece of code is called:
https://github.com/odoo/enterprise/blob/2051e84c55618c64179c4b9f3e99f4e795bacd32/helpdesk_stock_account/wizard/account_move_reversal.py#L16-L17

which calls the ```reverse_moves``` method in the
helpdesk_account.py file, which itself calls the ```reverse_moves``` method in the account_move_reversal.py file, in the account module, and so on.
Finally, we arrive in the account_move.py file. In the
```_reverse_moves``` of this file, we can see the code:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/account/models/account_move.py#L4937-L4947
where we simply copy all the lines of the move in the SO
without filtering them. As a result, we get the lines
of the product we don't want to refund

__
opw-5148789

Forward-Port-Of: odoo/enterprise#99477
Forward-Port-Of: odoo/enterprise#98771

## 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:**
- Add some folders
- Create a new company
- Assign some folders to the new company
- Archive the company
- Click on Documents app
- AccessError is raised when opening it

**Issue:**
The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`:
`folders = accessible_records.filtered(lambda d: d.type == 'folder')`

This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched.

**Fix:**
Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere.

For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows.

opw-4931278

Forward-Port-Of: odoo/enterprise#99126
Forward-Port-Of: odoo/enterprise#96817

[FIX] mail: can add message reaction in mobile

Before this commit, mobile uses could not practically add reactions.

Steps to reproduce:
- open a discuss conversation on mobile device
- post a message
- click on "..."
- click on "Add a reaction"
=> No emoji picker is shown.

This happens because the emoji picker opens in a modal in mobile. The modal has a z-index lower than chat window, and because of this it is actually shown below the chat window.

The chat window being above modal is sometimes desirable, like for AI chat windows triggered from a modal in desktop, but sometimes the opposite is desirable, like in mobile. Chat window had z-index for desktop use of above modal, but in mobile the opposite is desirable.

This commit fixes the issue by reducing the chat window z-index in mobile, so that modals are above chat windows.

Note that current desktop style for chat window being necessarily above modals is not exactly correct, but this is a tricker part to fix therefore this PR focuses on the immediate usability issue in mobile that makes using any modal in chat window unusable.

Task-5208322
Task-5261880

This PR also disables the showing of chat bubbles in discuss app similarly to the desktop counter-part.

Task-4607436

https://github.com/odoo/enterprise/pull/99588

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

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

**Steps to reproduce:**
* Install the **Point of Sale** module with demo data.
* Open the POS interface and create a new order.
* Add a product that has **taxes applied** and set its quantity to more than one.
* Confirm the order by proceeding to payment and Validate payment.
* Go to the backend: **Point of Sale → Orders → Orders**.
* Open the created order and check the value displayed under **Tax Excl**.

**Issue:**
* The **Tax Excl** field shows the *unit price* of the product instead of the *subtotal without tax*.

- *Example -*
 *Unit Price*: 10
 *Quantity*: 3
 *Tax*: 10%

**Expected Value -** 
**Tax Excl**(price_subtotal) : 30
**Tax Incl**(price_subtotal_incl): 33

**Current Value -** 
**Tax Excl**(price_subtotal) : 3
**Tax Incl**(price_subtotal_incl): 33

**Cause:**
* The POS code incorrectly assigns `price_subtotal` using the displayed unit price
 instead of the actual tax-excluded subtotal.

**Fix:**
* Assign `price_subtotal` using the correct **PriceExcl** value so the subtotal
 without tax is accurately reflected.

---
opw-5252340

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

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

# 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

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#233757