[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

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

Forward-Port-Of: odoo/odoo#235263

Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.

**Error:**
    `ProgrammingError: can't adapt type 'res.partner'`

This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or 
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes 
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID, 
when the system tries to browse the partner by this record [3], the error is raised.

This commit ensures that when writing the parent_id of the partner, the actual ID is used instead 
of the record.

[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386

[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53

[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801

sentry-6831922000

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

Forward-Port-Of: odoo/odoo#235198

## [FIX] hr: track the fields updated when creating new version

Before this commit, when the user alters an employee form view and then
create a new version, if a version exists on that employee altered, it
will copy the version with the changes made by the user at the same
time and so no tracking values on the values changed by the user are
created.

This commit makes sure the changes made by the user are correctly
tracked when a new version is created with some values given in
parameter.

## [FIX] hr: add explanation how to change group on version fields in employee model

## [FIX] hr*: make sure copy of a version copy all version fields

This commit makes sure all the information of a version is
completely duplicated when the user creates a new version from an
existing version of an employee.

## [FIX] hr: protect fields copied in create_version to avoid recomputing

Before this commit, since now we do a write after the copy of a new
version to be able to track the changes made by the user. We cannot
guarantee the vals given to the write will trigger a compute method from
a field copied.

This commit makes sure the version fields copied will never be
invalidated and only the fields inside the write (that is, the fields
altered by the user) will be altered.

Forward-Port-Of: odoo/odoo#222744

Steps to reproduce:

1. Install studio and contact (the bug is in the ORM, but studio/contact make it easy to reproduce).
2. Add a field (regular one, text/checkbox/...) on a partner form view with studio. Note its auto generated "old" name.
3. Rename the field via studio Note its new name.
4. Go to /doc, traceback `Key error: "old name" not in Model._fields`.
5. Go to "technical/database structure/fields" in ?debug=1 mode.
6. Search for "x_studio" `[("x_studio", "in", "name")]`

On "partner" you only see a single field, with the new name. On "user" you see two fields, one with the old name and another with the new name.

The problem is that when renaming the field, the ORM renamed (replaced) the old field by the new one on partner, reflected the change by adding a new field on res.users (inherits) but failed to remove the old field on res.users.

The traceback in /doc is only a symptom of the above problem. In this work we are adding a band-aid to skip badly renamed fields. It doesn't solve the root problem but it makes it possible to use /doc again until the actual bug is solved.

task-5172546

# 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