A new `pos_tyro` module for the Australian payment terminal Tyro was added in https://github.com/odoo/enterprise/pull/79432, but there was no way to select it other than installing the module manually. This commit adds Tyro to the payment terminal selection widget. Since it is an Enterprise module, it also adds additional filtering to hide enterprise modules from community users in the widget. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

A new `pos_tyro` module for the Australian
payment terminal Tyro was added in
https://github.com/odoo/enterprise/pull/79432,
but there was no way to select it other than
installing the module manually.

This commit adds Tyro to the payment terminal
selection widget. Since it is an Enterprise
module, it also adds additional filtering to hide
enterprise modules from community users in the
widget.

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

Forward-Port-Of: odoo/odoo#200114

**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate

**Steps to reproduce**
- Create accrual plan with  "Accrued gain time": at the start of the accrual period
- Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over.
- Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation.
- Manually set the number of days of the allocation to 0.
- Validate the allocation.

- Time Off Dashboard > Check the number of days accrued on the 2nd day of next year. Actual: 20 days. Expected: 10 days (gained on the 1st of next year, 0 days before that as the allocation has been set to 0).

**Cause**
0 days allocations (using an acrcual plan with gain time at start) are considered as not already accrued, even if they are marked as `already_accrued`.
https://github.com/odoo/odoo/blob/8b339fdde161e81e1a00cecd3b1fd280de51fd08/addons/hr_holidays/models/hr_leave_allocation.py#L460 In this case, we process the accrual plans when changing the date, which triggers the `_onchange_date_from` and marks the allocation as `already_accrued`.

opw-4340521

Forward-Port-Of: odoo/odoo#199510
Forward-Port-Of: odoo/odoo#198110

during refactoring of `hr_holidays` for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a), the `_get_days_request` function has been removed in the `hr_holidays` module, but it is still overridden in `hr_holidays_attendance` Forward-Port-Of: odoo/odoo#192885 Forward-Port-Of: odoo/odoo#190472

during refactoring of `hr_holidays` for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a), the `_get_days_request` function has been removed in the `hr_holidays` module, but it is still overridden in `hr_holidays_attendance`

Forward-Port-Of: odoo/odoo#192885
Forward-Port-Of: odoo/odoo#190472

There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the h

There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo.

One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http.

> The server generating a 401 response MUST send a WWW-Authenticate
> header field containing at least one challenge applicable to the
> target resource.

https://httpwg.org/specs/rfc9110.html#status.401
https://httpwg.org/specs/rfc9110.html#field.www-authenticate

https://github.com/odoo/odoo/pull/199063

Forward-Port-Of: odoo/odoo#199296

This commit will set the company_id from partner party legal entity when the partner is not from SA task: 4531706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196757

This commit will set the company_id from partner party legal entity when the partner is not from SA

task: 4531706




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

Forward-Port-Of: odoo/odoo#196757

Live chat windows automatically open for new conversations to improve agent efficiency. However, when the chat hub is in compact mode, these windows are still opened in the background and become visible when returning to normal mode, which feels too intrusive. Some agents prefer chats to open automatically, while others do not. This PR prevents automatic chat openings in compact mode, offering a better compromise for both. task-4614339 Description of the issue/feature this PR addresses:

Live chat windows automatically open for new conversations to improve agent efficiency. However, when the chat hub is in compact mode, these windows are still opened in the background and become visible when returning to normal mode, which feels too intrusive.

Some agents prefer chats to open automatically, while others do not. This PR prevents automatic chat openings in compact mode, offering a better compromise for both.

task-4614339

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

Forward-Port-Of: odoo/odoo#199979

Before this commit: Special mentions (@everyone) appeared as raw HTML instead of links because when message content is not `markup()`, it is rendered as text instead of HTML when using `t-out`. After this commit: This commit ensures special mentions are correctly rendered as links. Before / After   Forwar

Before this commit:

Special mentions (@everyone) appeared as raw HTML instead of links because when message content is not `markup()`, it is rendered as text instead of HTML when using `t-out`.

After this commit:

This commit ensures special mentions are correctly rendered as links.

Before / After 
![image](https://github.com/user-attachments/assets/868f00b3-a3e0-47ee-a2e7-3d6c6d76b948)
![image](https://github.com/user-attachments/assets/063f0b41-d214-49b1-83fa-7403884006e1)

Forward-Port-Of: odoo/odoo#200069

**Problem**: When the editor gains `focus` for the first time, `_latestComputedSelection` is set. However, `_resetFromClient` is then called to synchronize history steps with another client, recreating the nodes in the editor. This causes new node `oid`s to be generated (so we can't match with the `oid`s), invalidating the existing `_latestComputedSelection` (its `anchorNode` and `focusNode` no longer point to valid nodes). **Solution**: Before recreating the history, save the selection pat

**Problem**:
When the editor gains `focus` for the first time, `_latestComputedSelection` is set. However, `_resetFromClient` is then called to synchronize history steps with another client, recreating the nodes in the editor. This causes new node `oid`s to be generated (so we can't match with the `oid`s), invalidating the existing `_latestComputedSelection` (its `anchorNode` and `focusNode` no longer point to valid nodes).

**Solution**:
Before recreating the history, save the selection path. This allows the selection to be restored accurately from the newly created nodes.

**Steps to reproduce**:
1. Open a task in one browser tab and start editing.
2. Keep that tab open.
3. Open the same task in a second browser tab.
4. Click to start editing in the second tab.
5. Observe that the cursor moves back to the start of the description in the first tab.

opw-4235013

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

Forward-Port-Of: odoo/odoo#199773
Forward-Port-Of: odoo/odoo#191816

### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n

### Steps to reproduce the issue:

1. Create two Argentinian Companies
2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_
2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020
3. Install _Argentina - Payment Withholdings_
4. The following issue occurs:

### Explanation:

In `_l10n_ar_withholding_post_init`, for each company, we will compare a previously created dict to the existing accounts. If an account already exists, the data is removed from the dict, and since it is created before we start looping through the Companies to make the comparison, any removed data is removed for the companies that follow as well.

### Fix reasoning:

We will copy the original dict to keep a safe version of the data and only modify the copy during the comparison process.

opw-4446501

Forward-Port-Of: odoo/odoo#196207
Forward-Port-Of: odoo/odoo#194329

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---17.0-esoriginlength-jco I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187439 Forward-Port-Of: odoo/odoo#187332

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#187439
Forward-Port-Of: odoo/odoo#187332

**Current behavior:** Invoicing some product at a price unit different from that at reception (with the product having manual valuation and non-standard costing) will create pdiff account move lines on the invoice. **Expected behavior:** With manual valuation, there should not be pdiff AMLs. **Steps to reproduce:** 1. Create a product with average costing and manual valuation 2. Receive 10 units @ $100 to establish some std price 3. Consume the 10 product qty (scrap, sale, ...)

**Current behavior:**
Invoicing some product at a price unit different from that at reception (with the product having manual valuation and non-standard costing) will create pdiff account move lines on the invoice.

**Expected behavior:**
With manual valuation, there should not be pdiff AMLs.

**Steps to reproduce:**
1. Create a product with average costing and manual valuation

2. Receive 10 units @ $100 to establish some std price

3. Consume the 10 product qty (scrap, sale, ...)

4. Create the invoice on the purchase order

5. Change the price unit on the bill to $120 per product -> post

6. In the journal items tab on the invoice, see the pdiff AMLs

**Cause of the issue:**
No consideration for valuation when creating the AMLs for pdiff.

**Fix:**
Check that valuation is not manual prior to creating the AMLs.

opw-4492217

Forward-Port-Of: odoo/odoo#199884
Forward-Port-Of: odoo/odoo#196786

Steps: - Install `sale_management` - Open Sales - Go back to home menu - traceback `getParentScroll` can return `null` ```js const scrollParentElement = getScrollParent(this.currentTarget); const targetBounds = this.currentTarget.getBoundingClientRect(); if (targetBounds.bottom > scrollParentElement.clientHeight) ``` ```js export function getScrollParent(element) { if (!element) { return null; } ``` This commit adds a fallback for the return value of `get

Steps:
- Install `sale_management`
- Open Sales
- Go back to home menu
- traceback

`getParentScroll` can return `null`

```js
const scrollParentElement = getScrollParent(this.currentTarget);
const targetBounds = this.currentTarget.getBoundingClientRect();
if (targetBounds.bottom > scrollParentElement.clientHeight)
```

```js
export function getScrollParent(element) {
    if (!element) {
        return null;
    }
```

This commit adds a fallback for the return value of `getScrollParent` to
prevent this traceback.

opw-4600271

Forward-Port-Of: odoo/odoo#199075

This PR aims to solve multiple issues related to analytics and project generation in sales orders. 1. Let's assume an SO with the following: - Add an SOL with product that generates a project (or a project & a task) - Add an SOL with product that generates a task in no particular project - Confirm the SO with those products OR start from a confirmed SO, and add those products to it (add them all, and then save the SO) In that case, the second product should generate a task in the proj

This PR aims to solve multiple issues related to analytics and project generation in sales orders.

1. Let's assume an SO with the following:
- Add an SOL with product that generates a project (or a project & a task)
- Add an SOL with product that generates a task  in no particular project
- Confirm the SO  with those products OR start from a confirmed SO, and add those products to it (add them all, and then save the SO)

In that case, the second product should generate a task in the project generated by the first product (unless a project was selected on the SO). After this commit, if the SO generates multiple projects and no project was selected on the SO, we generate the task in the generated project with the lowest (sequence, id).

2. Let's assume an SO with the following:
- Create two SOs having both a service product which creates a project (or a project & a task)
- Confirm both SOs at the same time

Issue: Both SOs have the same project, while two projects have been generated (one per SO)
Solution: Each SO should have the project it has generated. In other terms, we should make it work when confirming multiple SOs in batch.

3. Let's assume an SO with the following:
- Add an SOL with product that generates a project (or a project & a task) not based on a project template
- Add an SOL with product that generates a project (or a project & a task) based on a project template
- Confirm the SO

Issue: Two projects were generated, each one having a different analytic account (but with the same name). It's not consistent with the previous behavior (from 17.4).
Solution: Create one analytic account that all generated projects will share.

4. Let's assume an SO with the following:
- Set the project of the SO to a project having an account_id
- Add an SOL with product that generates a project (or a project & a task)
- Confirm the SO

Issue: The account of the generated project is not the account of the project on the SO. Again, it's not consistent with the previous behavior (from 17.4).
Solution: Do not create a new analytic account for the generated project but instead take the one from the project on the SO if it is defined.

task-4244890
version-18.0

Forward-Port-Of: odoo/odoo#187045

Update es_419 translations for the following modules: - l10n_uy - l10n_latam_invoice_document - l10n_latam_base - l10n_latam_check --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197365

Update es_419 translations for the following modules:
- l10n_uy
- l10n_latam_invoice_document
- l10n_latam_base
- l10n_latam_check



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

Forward-Port-Of: odoo/odoo#197365

For `sale.order`, the salesperson (`user_id`) on the order is set to the partner's salesperson (`user_id` on `res.partner`) if set. Currently, `account.move` sets the salesperson (`invoice_user_id`) to the user creating the invoice. With this commit, `invoice_user_id` is set to the partner's salesperson if exists. task-4374265 Forward-Port-Of: odoo/odoo#197526

For `sale.order`, the salesperson (`user_id`) on the order is set to
the partner's salesperson (`user_id` on `res.partner`) if set.

Currently, `account.move` sets the salesperson (`invoice_user_id`) to
the user creating the invoice.

With this commit, `invoice_user_id` is set to the partner's salesperson
if exists.

task-4374265

Forward-Port-Of: odoo/odoo#197526

The PR #198791 introduced a reprinting of the pairing codes on the connected printers. However connected_by_usb variable isn't present in PrinterDriver_W which resulted in an error. This PR only reprints the status on the connected printer if we are on a Linux system Forward-Port-Of: odoo/odoo#200046

The PR #198791 introduced a reprinting of the pairing codes on the connected printers. However connected_by_usb variable isn't present in PrinterDriver_W which resulted in an error.
This PR only reprints the status on the connected printer if we are on a Linux system

Forward-Port-Of: odoo/odoo#200046

Before this commit, editing a message on a mobile device resulted to a crash. This happens because the 'edit' message action relies on presence of `props.messageEdition` on the component, which is present on `Message` but not `MessageActionMenuMobile` that is used in mobile. This commit fixes the issue by propagating the message edition hook from `Message` to `MessageActionMenuMobile`, so that message edition is possible without crash in mobile. There was a test to cover mobile, but due

Before this commit, editing a message on a mobile device resulted to a crash.

This happens because the 'edit' message action relies on presence of `props.messageEdition` on the component, which is present on `Message` but not `MessageActionMenuMobile` that is used in mobile.

This commit fixes the issue by propagating the message edition hook from `Message` to `MessageActionMenuMobile`, so that message edition is possible without crash in mobile.

There was a test to cover mobile, but due to test not being tagged as mobile, it was running with the screen size of mobile but without user agent as a mobile. The `MessageActionMenuMobile` component is shown when the device is considered mobile, therefore the mis-tag resulted in a test that takes into account screen size of mobile but on a desktop environment, thus this menu wasn't shown. The test has been fixed as a result.

Bug in action with crash:
![Mar-03-2025 21-01-53](https://github.com/user-attachments/assets/5b72ba4f-2f1f-4fd1-9201-f0faa1cb3b92)

Forward-Port-Of: odoo/odoo#200064

…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about t

…number

Steps to reproduce:
[l10n_ec]
- Create a credit note from the Bill journal
- Set a foreign customer
- Set a customized document number

Issue:
An error will be raised saying that the format is not correct

But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format."

Solution:
When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations.

opw-3993305

Forward-Port-Of: odoo/odoo#181450
Forward-Port-Of: odoo/odoo#174950

**issue:** If a user lacks Sales module rights, they are not allowed to duplicate a project. **steps to reproduce:** - Settings / Users & Companies / Users - Remove sales rights from the user while retaining rights in projects - In the project module, try duplicating a project An access error is raised because the ```reinvoiced_sale_order_id``` field is attempted to be read during the copy operation opw-4466519 Forward-Port-Of: odoo/odoo#196769

**issue:**

If a user lacks Sales module rights, they are not allowed to duplicate a project.

**steps to reproduce:**

- Settings / Users & Companies / Users
- Remove sales rights from the user while retaining rights in projects
- In the project module, try duplicating a project

An access error is raised because the ```reinvoiced_sale_order_id``` field is attempted to be read during the copy operation

opw-4466519

Forward-Port-Of: odoo/odoo#196769

When the user is on the screen saver, we do not want to propagate some events like click so that his click does not do something unexpected in the POS (like adding a product or something). This commit adds a check in the onAlive method of the pos app to stop the event propagation of some events when the screen saver is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199370

When the user is on the screen saver, we do not want to propagate some events like click so that his click does not do something unexpected in the POS (like adding a product or something).

This commit adds a check in the onAlive method of the pos app to stop the event propagation of some events when the screen saver is active.

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

Forward-Port-Of: odoo/odoo#199370

**Description of the issue/feature this PR addresses:** When computing l10n_in's `res_partner.l10n_in_gst_state_warning` field, we [search](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_partner.py#L45) for a res_country_state whose `l10n_in_tin` is the same as the one encoded in the partner's `vat`; if none is found we warn the user. Since the res_country_state's [`l10n_in_tin`](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e137

**Description of the issue/feature this PR addresses:**

When computing l10n_in's `res_partner.l10n_in_gst_state_warning` field, we [search](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_partner.py#L45) for a res_country_state whose `l10n_in_tin` is the same as the one encoded in the partner's `vat`; if none is found we warn the user.

Since the res_country_state's [`l10n_in_tin`](https://github.com/odoo/odoo/blob/f1fb0527f1b29e4b464e13718d6d0edb3b32a114/addons/l10n_in/models/res_country_state.py#L10) is not unique though, it is legal for the customer to have multiple res.country.state entries with the same l10n_in_tin (typically one standard plus one custom state):
```sql
> SELECT ARRAY_AGG(id),ARRAY_AGG(country_id),ARRAY_AGG(name),ARRAY_AGG(code),l10n_in_tin FROM res_country_state WHERE l10n_in_tin IS NOT NULL GROUP BY l10n_in_tin HAVING COUNT(*)>1
+-------------+------------+------------------------+--------------+-------------+
| array_agg   | array_agg  | array_agg              | array_agg    | l10n_in_tin |
|-------------+------------+------------------------+--------------+-------------|
| [1741, 589] | [104, 104] | ['HARYANA', 'Haryana'] | ['06', 'HR'] | 06          |
+-------------+------------+------------------------+--------------+-------------+
```

If our search passes more than one results to `state_id.name` though, Odoo fails with a ValueError:
```
 Traceback (most recent call last):
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 269, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 429, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpdugmps2c/migrations/base/tests/test_mock_crawl.py", line 457, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3801, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4032, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6999, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1291, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1473, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5238, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 113, in determine
    return needle(records, *args)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 710, in _compute_related
    record[self.name] = self._process_related(value[self.related_field.name], record.env)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6999, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1291, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1473, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5238, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/l10n_in/models/res_partner.py", line 48, in _compute_l10n_in_gst_state_warning
    "As per GSTN the state should be %s, so it's recommended to", state_id.name
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1232, in __get__
    record.ensure_one()
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6212, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
 ValueError: Expected singleton: res.country.state(1741, 589)
```


**Desired behavior after PR is merged:**
We can avoid this by explicitly limiting the search to a single result.

TBG: https://upgrade.odoo.com/web#cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form&id=1804


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

Forward-Port-Of: odoo/odoo#198388

The company logo on the hungarian invoices are too big if the used picture is big, because the size is not limited on the PDF report. So we set the class "o_company_logo_small" on the picture just like on everywhere in Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199835

The company logo on the hungarian invoices are too big if the used picture is big, because the size is not limited on the PDF report.

So we set the class "o_company_logo_small" on the picture just like on everywhere in Odoo.




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

Forward-Port-Of: odoo/odoo#199835

The chat hub's compact mode hides all chat windows to prevent disturbances, mainly from automatic actions. However, users should still be able to open chats explicitly (e.g., via the command palette or messaging menu). This PR allows user-initiated chats to open even in compact mode, balancing distraction-free usage with accessibility. Forward-Port-Of: odoo/odoo#199828

The chat hub's compact mode hides all chat windows to prevent
disturbances, mainly from automatic actions. However, users should
still be able to open chats explicitly (e.g., via the command palette
or messaging menu).

This PR allows user-initiated chats to open even in compact mode,
balancing distraction-free usage with accessibility.

Forward-Port-Of: odoo/odoo#199828

This is a solution for https://github.com/OCA/timesheet/issues/740 Forward-Port-Of: odoo/odoo#199851

This is a solution for https://github.com/OCA/timesheet/issues/740

Forward-Port-Of: odoo/odoo#199851

Issue: When you try to acssess the kiosk mode for a company which has no lang set on its partner, a blocking error is raised solve: add the env.lang as a default lang if the partner lang return false Task: 4465594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199865 Forward-Port-Of: odoo/odoo#199028

Issue: When you try to acssess the kiosk mode for a company which has no lang set on its partner, a blocking error is raised

solve: add the env.lang as a default lang if the partner lang return false

Task: 4465594

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

Forward-Port-Of: odoo/odoo#199865
Forward-Port-Of: odoo/odoo#199028

- add the _t() to translate the labels coming from options. - add the label values to the template to be available on the pot file Task: 4488490 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197470

- add the _t() to translate the labels coming from options.
- add the label values to the template to be available on the pot file

Task: 4488490

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

Forward-Port-Of: odoo/odoo#197470

Steps: - Install sales app. - Open a sale order and toggle studio. - Click on list view, select 'Edit list view' - Select 'Open form view' for 'when creating record' under 'views' side panel. - Go back to sale order. Add Product in sale order line. - Create Order Lines form opens. Issue: - Fields (quantity, delivered, etc.) are misformatted and not in sequence. - Product field has no label. Cause: - There was no label defined for product field as done for others that was breaking

Steps:
- Install sales app.
- Open a sale order and toggle studio.
- Click on list view, select 'Edit list view'
- Select 'Open form view' for 'when creating record' under 'views' side panel.
- Go back to sale order. Add Product in sale order line.
- Create Order Lines form opens.

Issue:
- Fields (quantity, delivered, etc.) are misformatted and not in sequence.
- Product field has no label.

Cause:
- There was no label defined for product field as done for others that was breaking the flow and sequence.

Fix:
- Added a Label to product field which solves the issue.

opw-4455197

Forward-Port-Of: odoo/odoo#199572

*FPOS - Fiscal Position *POS - Place of Supply - Before this commit: The fiscal position was determined based on the partner's shipping address (`partner_shipping_id`) in sales orders, which did not align with Indian tax regulations. - After this commit: The fiscal position is now computed based on the place of supply, ensuring compliance with Indian tax requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo

*FPOS - Fiscal Position
*POS - Place of Supply

- Before this commit: The fiscal position was determined based on the partner's shipping address (`partner_shipping_id`) in sales orders, which did not align with Indian tax regulations.

- After this commit: The fiscal position is now computed based on the place of supply, ensuring compliance with Indian tax requirements.


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

Forward-Port-Of: odoo/odoo#199834
Forward-Port-Of: odoo/odoo#197433

This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. - Cause an issue for MX and EC country code - VAT field is removed from mandatory fields - No need to remove the vat field manually, when the country changes the mandatory field list will be changed accordingly. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/enterprise/pull/79646 --- I confirm I have signed the CLA and read the PR guide

This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing.
- Cause an issue for MX and EC country code - VAT field is removed from mandatory fields
- No need to remove the vat field manually, when the country changes the mandatory field list will be changed accordingly.


Runbot Errors: 111328, 111329

Related: https://github.com/odoo/enterprise/pull/79646

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

Forward-Port-Of: odoo/odoo#198506

Before this PR, the composer was not always blocked after the user answered a question. This can lead to multiple answers being posted and inconsistent state. Steps to reproduce: - Create a chat bot with a free input step. - Open a live chat with this chat bot. - Throttle your network to 3G speed. - You can send many messages during the delay. This PR ensures the composer is disabled as soon as the user answers the bot until the next step is ready. part of task-4607689 Descriptio

Before this PR, the composer was not always blocked after the user answered a question. This can lead to multiple answers being posted and inconsistent state.

Steps to reproduce:
- Create a chat bot with a free input step.
- Open a live chat with this chat bot.
- Throttle your network to 3G speed.
- You can send many messages during the delay.

This PR ensures the composer is disabled as soon as the user answers the bot until the next step is ready.

part of task-4607689

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

Forward-Port-Of: odoo/odoo#199920

Before this commit, when using an ipad in portrait mode, clicking on message action "add a reaction" resulted to the following crash: ``` Uncaught Promise > Cannot read properties of undefined (reading 'getRootNode') ``` This happens because in mobile, the message actions are displayed with mobile action menu. Clicking on "Add a reaction" opens the emoji picker, which should open the mobile version of the emoji picker. However, the inner-code of emoji picker was attempting to use the des

Before this commit, when using an ipad in portrait mode, clicking on message action "add a reaction" resulted to the following crash:

```
Uncaught Promise > Cannot read properties of undefined (reading 'getRootNode')
```

This happens because in mobile, the message actions are displayed with mobile action menu. Clicking on "Add a reaction" opens the emoji picker, which should open the mobile version of the emoji picker. However, the inner-code of emoji picker was attempting to use the desktop emoji picker, due to relying on screen size rather than `isMobileOS()`. The desktop mode of emoji picker needs a anchor target, which is the quick message action "add a reaction" in desktop. In mobile this doesn't exist, thus the anchor was `undefined`, and inner-code of popover crashes when the anchor el is undefined.

This commit fixes the issue by using the mobile emoji picker mode using `isMobileOS()` rather than `ui.isSmall`. This makes showing of mobile emoji picker consistent for all mobile devices, which matches the expected UX/UI in Discuss.

opw-4606671

Forward-Port-Of: odoo/odoo#199804

When discuss sidebar is compact and there's a call in a channel, the call participant UI in discuss sidebar had the following issues: - The floating menu had harsh shadow, whereas all other floating menu have soft shadow `.shadow-sm`. - The short status of user was shown in the bottom-right of "+X" users in call, rather than bottom-right of the avatar. - The avatar stack could be expanded when sidebar is compact, but there's no way to compact it again. This commit fixes the issues as fol

When discuss sidebar is compact and there's a call in a channel, the call participant UI in discuss sidebar had the following issues:

- The floating menu had harsh shadow, whereas all other floating menu have soft shadow `.shadow-sm`.
- The short status of user was shown in the bottom-right of "+X" users in call, rather than bottom-right of the avatar.
- The avatar stack could be expanded when sidebar is compact, but there's no way to compact it again.

This commit fixes the issues as follow:
- Adds `.shadow-sm` in the floating menu of call participant.
- Position short status of active call participant in bottom-right as it should
- Remove expand feature on click avatar stack of call participant when sidebar is compact

Before / After
<img width="222" alt="Screenshot 2025-03-03 at 14 46 39" src="https://github.com/user-attachments/assets/27b86dda-ab5e-4f70-b467-f8af28945a7e" /> <img width="224" alt="Screenshot 2025-03-03 at 14 45 49" src="https://github.com/user-attachments/assets/906b8e81-d1db-409b-a42a-a90af0804639" />

Expand bug:
![Mar-03-2025 14-47-57](https://github.com/user-attachments/assets/92a706c7-2bb4-4715-afb1-449401a09234)

Forward-Port-Of: odoo/odoo#199984

This PR fixes 2 issues: 1. new message sound effect had too long decay, this PR reduces it significantly 2. "message sound" toggle settings to enable or disable "new message" sound effect was not working properly. Before https://github.com/user-attachments/assets/0d4482ee-ca25-4312-b4e7-85cea4d1f085 After https://github.com/user-attachments/assets/089d5546-8aa6-4145-8105-88695bd6f2b4 Forward-Port-Of: odoo/odoo#199904

This PR fixes 2 issues:

1. new message sound effect had too long decay, this PR reduces it significantly
2. "message sound" toggle settings to enable or disable "new message" sound effect was not working properly.

Before
https://github.com/user-attachments/assets/0d4482ee-ca25-4312-b4e7-85cea4d1f085

After
https://github.com/user-attachments/assets/089d5546-8aa6-4145-8105-88695bd6f2b4

Forward-Port-Of: odoo/odoo#199904

Certain certificates contain additional fields beyond those currently included (CN, OU, O, C), such as "2.5.4.97" and "L". Since these additional fields are not incorporated into the issuer name, attempts to validate the signed document on the following sites will result in errors: - https://face.gob.es/es/facturas/validar-visualizar-facturas - https://valide.redsara.es/valide/validarFirma/ejecutar.html These errors typically indicate that the signature is either invalid and that the cer

Certain certificates contain additional fields beyond those currently included (CN, OU, O, C), such as "2.5.4.97" and "L".

Since these additional fields are not incorporated into the issuer name, attempts to validate the signed document on the following sites will result in errors:
- https://face.gob.es/es/facturas/validar-visualizar-facturas
- https://valide.redsara.es/valide/validarFirma/ejecutar.html

These errors typically indicate that the signature is either invalid and that the certificate does not match the values within `<KeyInfo>`. This discrepancy occurs because all certificate fields are included in the signature, but some are missing from the `<X509IssuerName>` field.

This fix adds the missing certificate fields to ensure consistency between the signature and the issuer name. Based on my tests, the order of these fields does not affect the validation process.

opw-4484906
opw-4482626

Forward-Port-Of: odoo/odoo#199891
Forward-Port-Of: odoo/odoo#196576

Problem ---------- Amendments to PAYE computation from 27 Dec 2024 Objective ---------- Correct the Kenya Payroll computation with the new rules from the 27 Dec 2024 Solution ---------- Adapt rules and parameters task-4457038 Forward-Port-Of: odoo/enterprise#80377

Problem
----------
Amendments to PAYE computation from 27 Dec 2024

Objective
----------
Correct the Kenya Payroll computation with the new rules from the 27 Dec 2024

Solution
----------
Adapt rules and parameters

task-4457038

Forward-Port-Of: odoo/enterprise#80377

"Customs" was translated to "Pedimiento" instead of "Pedimento". Have also updated / re-exported the po and pot files to keep them in sync. opw-4507567 Forward-Port-Of: odoo/enterprise#80511 Forward-Port-Of: odoo/enterprise#78933

"Customs" was translated to "Pedimiento" instead of "Pedimento".
Have also updated / re-exported the po and pot files to keep them in sync.

opw-4507567

Forward-Port-Of: odoo/enterprise#80511
Forward-Port-Of: odoo/enterprise#78933

-change the date format to dd/mm/yyyy -employee code should be employee registration number of the employee -title should be bold -borderline should be same on both table task-4452670 Forward-Port-Of: odoo/enterprise#76534

-change the date format to dd/mm/yyyy
-employee code should be employee registration number of the  employee 
-title should be bold
-borderline should be same on both table

task-4452670

Forward-Port-Of: odoo/enterprise#76534

Bug === Some custom actions might change the token for some reason, if that code is badly implemented, it will result in a crash when uploading on the request. Task-4492764 Forward-Port-Of: odoo/enterprise#80604 Forward-Port-Of: odoo/enterprise#77403

Bug
===
Some custom actions might change the token for some reason, if that code is badly implemented, it will result in a crash when uploading on the request.

Task-4492764

Forward-Port-Of: odoo/enterprise#80604
Forward-Port-Of: odoo/enterprise#77403

This commit adds 2 major module for handling SIE4 files within Odoo. Even though the SIE5 is already available in Odoo, the majority of the Swedish userbase still uses SIE4 (or below) for importing and exporting accounting data. In addition to the new features below, this commit also renames the current odoo implementation of SIE5 from just "SIE" to "SIE 5" to avoid confusion between the two. This first implementation does not at all consider the effects of the `#OBJEKT` and `#DIM` (or

This commit adds 2 major module for handling SIE4 files within Odoo.

Even though the SIE5 is already available in Odoo, the majority of the Swedish userbase still uses SIE4 (or below) for importing and exporting accounting data.

In addition to the new features below, this commit also renames the current odoo implementation of SIE5 from just "SIE" to "SIE 5" to avoid confusion between the two.

This first implementation does not at all consider the effects of the `#OBJEKT` and `#DIM` (or other similar dimension) items.

---

### SIE4 Import - `l10n_se_sie4_import`

Odoo can now import accounting data from SIE of type 4 and below (thanks to backward-compatibility of SIE format).

SIE4 files are designed as a text file with label on each line and its contents. One item can be referred by another item down the file, so we need a variable (`data_map`) to save the required information for future use, in-between the reading process.

From the SIE4 file, we can then import the following data: company, chart of accounts, fiscal year, and move informations.

An option will be provided when creating the wizard to allow user to choose whether they'd like to import opening balance move, and/or update any duplicate accounts already found in their company with the one in the file.

---

### SIE4 Export - `l10n_se_sie4_export`

Odoo's implementation of exporting SIE4 files are placed in the General Ledger view's export buttons, similar to other import implementation like SAF-T and Libros.

To be able to export SIE4 file, the date periods in the selected options must be of type fiscal year, and exporting multiple companies at once is forbidden.

---

[SIE 4 documentation](https://sie.se/wp-content/uploads/2020/05/SIE_filformat_ver_4B_ENGLISH.pdf)

task-id: 3735808

Forward-Port-Of: odoo/enterprise#80403
Forward-Port-Of: odoo/enterprise#66263

This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. Runbot Errors: 111328, 111329 Forward-Port-Of: odoo/enterprise#79646

This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing.

Runbot Errors: 111328, 111329


Forward-Port-Of: odoo/enterprise#79646

Recent updates introduced automatic inclusion of the user's signature to the mail composer (see: odoo/odoo#184695). When the user clicks on the "Send as Message" button of a clipboard block in Knowledge, the macro system will do a few steps to (1) restore the previous view, (2) open the full mail composer and (3) insert the clipboard text at the end of it. As the signature is added when opening the full mail composer, the clipboard text is inserted after the user's signature which is inconven

Recent updates introduced automatic inclusion of the user's signature to the mail composer (see: odoo/odoo#184695). When the user clicks on the "Send as Message" button of a clipboard block in Knowledge, the macro system will do a few steps to (1) restore the previous view, (2) open the full mail composer and (3) insert the clipboard text at the end of it.

As the signature is added when opening the full mail composer, the clipboard text is inserted after the user's signature which is inconvenient as users must manually adjust the message to position the signature at the end of the message.

To avoid this problem, we'll replace the full mail composer content with the concatenation of the clipboard text and the user's signature. This guarantee that the two elements will appear in the desired order.

Steps to reproduce:
1. Open the CRM lead view
2. Press `Ctrl` + `k` to open the command palette
3. In the command palette, select any article
4. In the article you chose, insert a clipboard block with the /clipboard command
5. Click on the "Send As Message" button of the clipboard

=> The macro restores the CRM lead view, opens the full mail composer and paste the clipboard content after the user's signature.

TO BE: The macro should replace the message of the full composer with the clipboard content and the user's signature should be placed after the clipboard content.

Task-4428445

Forward-Port-Of: odoo/enterprise#76725

Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial

Steps to reproduce:
[l10n_ec]
- Create a credit note from the Bill journal
- Set a foreign customer
- Set a customized document number

Issue:
An error will be raised saying that the format is not correct

But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format."

Solution:
When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify
certain conditions to bypass the document check/formatting for localisations.

We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test

opw-3993305

Forward-Port-Of: odoo/enterprise#70673
Forward-Port-Of: odoo/enterprise#67589

In Knowledge, in the Calendar embed, event text descriptions and properties tend to overlap with each other, and the header. The Calendar embed also does not resize properly when the sidebar width or article width get changed. This commit makes it so that event descriptions and properties do not overlap ; and that calendar width (and, subsequently, column width) is affected by sidebar or article width changes. task-4558391 Forward-Port-Of: odoo/enterprise#80537 Forward-Port-Of: odoo

In Knowledge, in the Calendar embed, event text descriptions
and properties tend to overlap with each other, and the header.
The Calendar embed also does not resize properly when the
sidebar width or article width get changed.

This commit makes it so that event descriptions and properties
do not overlap ; and that calendar width (and, subsequently,
column width) is affected by sidebar or article width
changes.

task-4558391

Forward-Port-Of: odoo/enterprise#80537
Forward-Port-Of: odoo/enterprise#79164

Steps to reproduce ================== - Use a mobile viewport - Go to field service - Switch to the calendar view - Click on an empty slot to create a new record => The default dates are missing - Go back to the calendar view - Click on an existing record => We should be able to edit the selected record, but instead, we can create a new one opw-4596689 Forward-Port-Of: odoo/enterprise#80506

Steps to reproduce
==================

- Use a mobile viewport
- Go to field service
- Switch to the calendar view
- Click on an empty slot to create a new record => The default dates are missing
- Go back to the calendar view
- Click on an existing record => We should be able to edit the selected record, but instead, we can
   create a new one

opw-4596689

Forward-Port-Of: odoo/enterprise#80506

Steps to reproduce ================== - Go to Field Service - Use a mobile viewport - Click on "new" Without debug: The default assignee is not the current user In debug: Invalid props for component 'ProjectTaskFormController': unknown key 'additionalContext', unknown key 'onClose' opw-4512178 Forward-Port-Of: odoo/enterprise#80497

Steps to reproduce
==================

- Go to Field Service
- Use a mobile viewport
- Click on "new"

Without debug:

The default assignee is not the current user

In debug:

Invalid props for component 'ProjectTaskFormController': unknown key 'additionalContext', unknown key 'onClose'

opw-4512178

Forward-Port-Of: odoo/enterprise#80497

This error occurs when we delete the user's role in the configuration and then attempt to ``Send`` the template in Templates. Steps to reproduce: - Install the ``Sign`` module - Sign > Configuration > Roles > Delete ``User`` role - Now go to ``Templates`` and Click on the ``Send`` and `Sign Now` buttons of any template Traceback: ``ValueError: External ID not found in the system: sign.sign_item_role_user`` The error in [1] occurred because the ``sign_item_role_user`` ID is missing

This error occurs when we delete the user's role in the configuration and then attempt to ``Send`` the template in Templates.

Steps to reproduce:
- Install the ``Sign`` module
- Sign > Configuration > Roles > Delete ``User`` role
- Now go to ``Templates`` and Click on the ``Send`` and `Sign Now` buttons of any template

Traceback: 
``ValueError: External ID not found in the system: sign.sign_item_role_user``

The error in [1] occurred because the ``sign_item_role_user`` ID is missing from the ``Sign`` model, as it was deleted.

[1]- https://github.com/odoo/enterprise/blob/ec873122c01f5312e907a96e462ace794e12fe18/sign/wizard/sign_send_request.py#L132

sentry-5694515390

Forward-Port-Of: odoo/enterprise#70087

Steps to reproduce =================== Admin: 1. Create an article 2. Share the article 3. Add a portal user as a member 4. Write a comment (using the editor, select the text, and use the toolbar to write a comment) 5. Attach a file to the new message Portal: 6. Go to the created article 7. Go to the comment with the message and attachment 8. Download/view the attachment => No access to the document After this commit ================= Portal user who has read or write access t

Steps to reproduce
===================
Admin:
1. Create an article
2. Share the article
3. Add a portal user as a member
4. Write a comment (using the editor, select the text, and use the toolbar to write a comment)
5. Attach a file to the new message

Portal:
6. Go to the created article
7. Go to the comment with the message and attachment
8. Download/view the attachment
=> No access to the document

After this commit
=================
Portal user who has read or write access to the linked article is granted the access

Task-4223292

Forward-Port-Of: odoo/enterprise#80519
Forward-Port-Of: odoo/enterprise#75819

**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551

**Issue:**
The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant.

opw-4566689
opw-4590293
opw-4572865

Forward-Port-Of: odoo/enterprise#80551