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

__
## Short functional explanation of the error
Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B.
In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0.

## Reproduction Steps
1. Switch to company A and create a timeoff starting before today and ending later.
2. Switch back to company B. Create a project, a stage and a task.
3. Enable the debugger.
4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check
Show Invisible Elements.
5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible.
6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change.

### Expected behavior
The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation

### Unexpected behavior
Nothing happens

## Origin of the issue
When computing the working time to assign, we also take into consideration leaves:
if this happened during public holidays, we consider that it took no working time to get assigned.
However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following:
https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-#L546 
The company isn't taken into account in the domain,
applying the holiday for every company.
_________________________________________
opw-5222883

---

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

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

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

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

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

**Issue**
A PO triggered by a SO could have an invalid vendor selected.

**Steps to reproduce**
- Install Sale and Purchase apps
- Create a product with:
  - Two routes: MTO and Buy (Inventory tab)
  - Two sellers in this order (Purchase tab):
    1. With an expired `end_date`
    2. With a valid `end_date`
- Create a SO for that product with a client that is **not** one of the vendors
→ A PO is created with the first vendor instead of the second (valid) one.

**Cause**
In the method `_run_buy`, to retrieve the vendor for the PO, `_select_seller` is called with the associated partner of the SO:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/purchase_stock/models/stock_rule.py#L62C1-L66C52

That method calls `_get_filtered_sellers` with that associated partner:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/product/models/product_product.py#L699

Which returns an empty recordset because every seller record is filtered out since every one of them has an associated partner different than the one set on the SO:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/product/models/product_product.py#L673C1-L674C25

Then, in `_run_buy`, the fallback is to call `_prepare_sellers` with no param, and to select the first one found:
https://github.com/odoo/odoo/blob/fa8bfc7306c7f85b013d7f5e336dcfe0586990df/addons/purchase_stock/models/stock_rule.py#L70C1-L72C18

And since, `_prepare_sellers` sorts the records according the sequence (among other thing but not the end_date):
https://github.com/odoo/odoo/blob/1478cbcfbf8d1e0184fce6236c5201ba4b59a159/addons/product/models/product_product.py#L653
it will select the first one (here, the one with an expired end_date)

**Solution**
One option would be to not indicate the vendor when calling `_select_seller` in `_run_buy`, but this would prevent specifying a vendor explicitly.
Instead, add a better fallback where we call `_select_seller` again without specifying the vendor, ensuring a valid seller is selected even when the SO partner doesn’t match any vendor.

opw-5145683