Before this commit, as a public user in website chatter: - Trying to add a reaction would result in a traceback. - The link created from the "Copy Link" action would lead to an unauthorized page. Steps to reproduce: - Install website module and add course page - As public user open a course - Go to reviews - Add a reaction to any message -> traceback - Copy link to any message - Open said link -> unauthorized page This commit fixes the issues by adding a "can_react" field in the po

Before this commit, as a public user in website chatter:
- Trying to add a reaction would result in a traceback.
- The link created from the "Copy Link" action would lead to an unauthorized page.

Steps to reproduce:
- Install website module and add course page
- As public user open a course
- Go to reviews
- Add a reaction to any message -> traceback
- Copy link to any message
- Open said link -> unauthorized page

This commit fixes the issues by adding a "can_react" field in the portal store init.

task-4551910

Forward-Port-Of: odoo/odoo#197508

Similarly to other types of products, combo products must be published to make them available in eCommerce. However, combo item products (i.e. the different choices in a combo) don't need to be published. Unfortunately, if a product is unpublished, public/portal users don't have access to its images, so they won't be shown in the combo configurator. This is a bad UX, as public/portal users are expected to make a product selection, but we don't show them the corresponding images. This PR us

Similarly to other types of products, combo products must be published to make them available in eCommerce. However, combo item products (i.e. the different choices in a combo) don't need to be published. Unfortunately, if a product is unpublished, public/portal users don't have access to its images, so they won't be shown in the combo configurator.

This is a bad UX, as public/portal users are expected to make a product selection, but we don't show them the corresponding images.

This PR uses the `src` attribute of the `img` tag to show the raw combo item's image instead of using the image url, bypassing access checks.

This is done only for combo items that are not published.

task-4337641

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

Forward-Port-Of: odoo/odoo#191838

### Steps to reproduce: - Duplicate a user - Login to this user - In Accounting select an invoice and try to send it by post ### Cause: The keys `author_user_id` and `author_partner_id` have switched values. They should be like in the [batch](https://github.com/odoo/odoo/blob/becbccbef5f2aa6b062d8b3714c233dbeaca9c98/addons/account/wizard/account_move_send_batch_wizard.py#L91-L92). opw-4531514 Forward-Port-Of: odoo/odoo#197509

### Steps to reproduce:
- Duplicate a user
- Login to this user
- In Accounting select an invoice and try to send it by post

### Cause:
The keys `author_user_id` and `author_partner_id` have switched values. They should be like in the [batch](https://github.com/odoo/odoo/blob/becbccbef5f2aa6b062d8b3714c233dbeaca9c98/addons/account/wizard/account_move_send_batch_wizard.py#L91-L92).

opw-4531514

Forward-Port-Of: odoo/odoo#197509

This commit adds new tax ISR 1.25 witheld RESICO for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/enterprise#80081](https://github.com/odoo/enterprise/pull/80081) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199579 Forward-Port-Of: odoo/odoo#195346

This commit adds new tax ISR 1.25 witheld RESICO for mexican localization

target: 17 -> master
task-4486643

Linked PR: [odoo/enterprise#80081](https://github.com/odoo/enterprise/pull/80081)

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

Forward-Port-Of: odoo/odoo#199579
Forward-Port-Of: odoo/odoo#195346

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

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

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

On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content, considering the editor handles the delete operation and assumes the default behavior is prevented. The steps below illustrate one of the possible issues. Steps 1: a. Have the following html: ``` <h1><span style="font-size: 36px;">Welcome to the To-do app! </span></h1> <p> <span style="font-s

On Android Chrome, for some obscure reason (bug?) the beforeinput event of type deleteContentBackward cannot be default prevented. This leads to unpredictable behavior when deleting content, considering the editor handles the delete operation and assumes the default behavior is prevented.

The steps below illustrate one of the possible issues.

Steps 1:

a. Have the following html:
```
<h1><span style="font-size: 36px;">Welcome to the To-do app! </span></h1>
<p>
    <span style="font-size: 14px;">
        Use it to manage your work</span>
</p>
```

b. On Android Chrome, place the cursor at the beginning of the paragraph and press backspace on the device's virtual keyboard.

As a result, the paragraph is merged with the heading, but the characters "Use it to" disappear:
```
<h1>
    <span style="font-size: 36px;">Welcome to the To-do app!</span>
    <span style="font-size: 14px;">&nbsp;manage your work</span>
</h1>
```

This example was taken from the "Welcome Mitchell Admin" task in the To-do app, so it's easily testable.

Steps 2:

a. On Android Chrome, have two paragraphs with some text, and place the cursor at the beginning of the second paragraph. E.g.:
```
    <p>abc</p>
    <p>[]def</p>
```

b. Press backspace on the device's virtual keyboard.

As a result, the paragraphs are merged (as expected), but the cursor is placed in the wrong position, e.g.: `<p>abcd[]ef</p>`, whilst `<p>abc[]def</p>` was expected.

Since the default behavior cannot be prevented, this commit makes sure that eventual DOM mutations and selection changes occurred after the beforeinput event are reverted, aiming to achieve the same effect as preventing default.

task-4243933

Forward-Port-Of: odoo/odoo#193821

Description of the issue/feature this PR addresses: ticket id: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - MENA l10n module descriptions were uncomplete or unconsistent Desired behavior after PR is merged: - improve l10n module description for MENA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199174 Forward-Port-Of: odoo/odoo#190703

Description of the issue/feature this PR addresses:
ticket id: https://www.odoo.com/odoo/my-tasks/4179478

Current behavior before PR:
- MENA l10n module descriptions were uncomplete or unconsistent

Desired behavior after PR is merged:
- improve l10n module description for MENA



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

Forward-Port-Of: odoo/odoo#199174
Forward-Port-Of: odoo/odoo#190703

In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field

In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value.

Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions.

#### speedup

Test database with account_accountant and sale.
Trying to create batches of account.moves

| Batch size | Before PR | After PR |
|:----------:|:---------:|:--------:|
|     1      |    70ms   |    58ms  |
|     50     |    150ms  |    100ms |
|     100    |    275ms  |    188ms |
|     250    |    660ms  |    450ms |
|     1000   |    2.43s  |    1.75s |
|     3000   |    7.55s  |    5.33s |

Average speedup: 68%.




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

Forward-Port-Of: odoo/odoo#160313
Forward-Port-Of: odoo/odoo#157887

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

In odoo/odoo#196748, the secured group usability was changed to only grant access to the new features relating to securing entries if moves from a journal without "Hash on Post" are secured. In odoo/odoo#197226, an issue with the first commit was addressed, in which an error was raised when checking if a journal had unhashed entries. This commit adds tests to validate that the group-granting behavior occurs correctly, and that there are no errors raised when checking a journal for unhashed en

In odoo/odoo#196748, the secured group usability was changed to only grant access to the new features relating to securing entries if moves from a journal without "Hash on Post" are secured. In odoo/odoo#197226, an issue with the first commit was addressed, in which an error was raised when checking if a journal had unhashed entries.

This commit adds tests to validate that the group-granting behavior occurs correctly, and that there are no errors raised when checking a journal for unhashed entries.

no-task

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

Forward-Port-Of: odoo/odoo#197558

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

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

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

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

Currently, when using the same pos session with different users can result in some order being created without user_id. Steps to reproduce: ------------------- * Open register as Mitchell Admin * Make a pos order, pay with cash, validate, select 'new order' * Log out * Log with Marc Demo and open the pos * Make a pos order, pay with cash, validate * In the backend, see both orders > Observation: For the second order, Mard Demo is written in the chatter as the one who created the orde

Currently, when using the same pos session with different users can result in some order being created without user_id.

Steps to reproduce:
-------------------
* Open register as Mitchell Admin
* Make a pos order, pay with cash, validate, select 'new order'
* Log out
* Log with Marc Demo and open the pos
* Make a pos order, pay with cash, validate
* In the backend, see both orders
> Observation: For the second order, Mard Demo is written in the chatter
as the one who created the order but on the form no user is registered

Why the fix:
------------
This happens because when selecting 'new order', an order gets created which will then be loaded back when logging with the second user.

When loaded the order has an unidentified user but still has a user_id in the vals of the setup. We do not want to use this user as it is the one that created the order, not the one who finalized it.

opw-4566194

Forward-Port-Of: odoo/odoo#199827

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

This commit fixes an issue where clicking "Load more" in the first column of the Kanban view caused the page to scroll to the button, making users lose their previous position. This appears to be related to the browser's behavior of scrolling to a focused element if it still exists after DOM mutations. However, it remains unclear why this only affects the first column and not the others. As a temporary workaround, a t-key is added to the "Load more" button to ensure it is removed and replaced

This commit fixes an issue where clicking "Load more" in the first column of the Kanban view caused the page to scroll to the button, making users lose their previous position. This appears to be related to the browser's behavior of scrolling to a focused element if it still exists after DOM mutations. However, it remains unclear why this only affects the first column and not the others.

As a temporary workaround, a t-key is added to the "Load more" button to ensure it is removed and replaced each time it is clicked. This issue was partially addressed in https://github.com/odoo/odoo/pull/115706, but that fix is no longer relevant with this commit.

Forward-Port-Of: odoo/odoo#199541

**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#198416
Forward-Port-Of: odoo/odoo#191816

**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#197902
Forward-Port-Of: odoo/odoo#196786

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

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

Before this commit: === - If `urbanpiper_fiscal_position_id` is not set, the system attempts to retrieve the default UrbanPiper fiscal position. After this commit: === - The check ensures that if no valid fiscal position is found (either missing or belonging to a different company), a new one is created. runbot-115934 Forward-Port-Of: odoo/enterprise#79652

Before this commit:
===
- If `urbanpiper_fiscal_position_id` is not set, the system attempts to retrieve the default UrbanPiper fiscal position.

After this commit:
===
- The check ensures that if no valid fiscal position is found (either missing or belonging to a different company), a new one is created.

runbot-115934

Forward-Port-Of: odoo/enterprise#79652

This PR aims to automatically set the status of a “Rejected” document to “Cancelled” while preserving the sequence number assigned by DGI (based on the CAE) to ensure all documents, including rejected ones, remain in the system with their original sequence. This is to maintain proper accounting records and provides visibility of all rejected documents. Forward-Port-Of: odoo/enterprise#80597 Forward-Port-Of: odoo/enterprise#76931

This PR aims to automatically set the status of a “Rejected” document to “Cancelled” while preserving the sequence number assigned by DGI (based on the CAE) to ensure all documents, including rejected ones, remain in the system with their original sequence. This is to maintain proper accounting records and provides visibility of all rejected documents.

Forward-Port-Of: odoo/enterprise#80597
Forward-Port-Of: odoo/enterprise#76931

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

Mod349 tax report in Spanish localization should report the total number of intra-community operators and a following details of each operation type Currently if the user decide to unset the field l10n_es_reports_mod349_invoice_type on an intra-community invoice (because of a mistake or an exception) the Mod349 will still report the invoice in the total number of intra community operators but no operation will be reported in the following section Steps to reproduce: - With an ES company se

Mod349 tax report in Spanish localization should report the total number of intra-community operators and a following details of each operation type
Currently if the user decide to unset the field
l10n_es_reports_mod349_invoice_type on an intra-community invoice (because of a mistake or an exception) the Mod349 will still report the invoice in the total number of intra community operators but no operation will be reported in the following section

Steps to reproduce:
- With an ES company setup
- Create 1 invoice to an EU partner
- Make sure Mod349 Invoice Type is unset
- Go to Accounting / Reporting / Statement Reports / Tax Report
- Select Tax Report (Mod 349) (ES)

Issue: Total number of intra-community operators is 1, but no operation is shown

opw-4403287

Forward-Port-Of: odoo/enterprise#80458
Forward-Port-Of: odoo/enterprise#80253

This PR addresses a payslip-calculating issue where overtime records right outside the payslip's period were being included in the calculations, messing up normal hours. The way this is fixed in this PR is by delaying the timezone-stripping code until it is necessary. This allows the local timezone variables, `date_from` and `date_to`, to be used to query the associated overtime records, rather than their UTC versions. We need this behavior because the "overtime" query depends on the field `

This PR addresses a payslip-calculating issue where overtime records right outside the payslip's period were being included in the calculations, messing up normal hours. 

The way this is fixed in this PR is by delaying the timezone-stripping code until it is necessary. This allows the local timezone variables, `date_from` and `date_to`, to be used to query the associated overtime records, rather than their UTC versions. We need this behavior because the "overtime" query depends on the field `HrAttendanceOvertime.date`, which is of type `fields.Date` and is timezone-agnostic.

This bug can be replicated in any variation of the following scenario (this one assumes the payslip period covers exactly one month of work):
- Create an attendance record for employee `A` that would cause them to have `h` hours of overtime at the end of month `X`, where `X` is a number in the set `{1, 2, ..., 12}`.
- Create an attendance record for `A` on the 1st of the next month, `Y := X mod 12 + 1`, with `h'` regular hours and `0` hours of overtime.
- Generate their payslip for the month `Y`.
- See that there is an overtime line with `h` hours and a regular hours line with `h' - h` hours. 🐛

opw-4371083

Forward-Port-Of: odoo/enterprise#80012
Forward-Port-Of: odoo/enterprise#78880

"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

This commit adds new tax ISR 1.25 witheld for mexican localization target: 17 -> master task-4486643 Linked PR: [odoo/odoo#195346](https://github.com/odoo/odoo/pull/195346) Forward-Port-Of: odoo/enterprise#80357 Forward-Port-Of: odoo/enterprise#80081

This commit adds new tax ISR 1.25 witheld for mexican localization

target: 17 -> master
task-4486643

Linked PR: [odoo/odoo#195346](https://github.com/odoo/odoo/pull/195346)

Forward-Port-Of: odoo/enterprise#80357
Forward-Port-Of: odoo/enterprise#80081

This commit is a patch to the following PR: https://github.com/odoo/enterprise/pull/76478#discussion_r1946575309 Steps to reproduce the bug: - Create two storable products “P1” and “P2”: - Tracked by Serial Number - Create a quality control point: - Operation: Receipt - Control per: Quantity - Create a receipt: - 10 units of P1 - 10 units of P2 - Mark it as "To Do." - Open the detailed operation of P1: - Assign two SNs: - SN1 - SN2 - Save. - The “Quantity” f

This commit is a patch to the following PR: https://github.com/odoo/enterprise/pull/76478#discussion_r1946575309 Steps to reproduce the bug:
- Create two storable products “P1” and “P2”:
    - Tracked by Serial Number
- Create a quality control point:
    - Operation: Receipt
    - Control per: Quantity

- Create a receipt:
    - 10 units of P1
    - 10 units of P2
- Mark it as "To Do."
- Open the detailed operation of P1:
    - Assign two SNs: - SN1 - SN2 - Save.
- The “Quantity” field of the P1 move is updated to 2.
- Mark the move of P1 as "Picked."
- Validate the receipt.
- The backorder wizard is triggered → Validate it.

Problem:
A wizard to process the quality check is triggered, but 12 quality checks (2 for P1 and 10 for P2) are loaded instead of only 2 for P1.

Expected Behavior:
Quality checks should only be triggered for picked moves

opw-4442564

Forward-Port-Of: odoo/enterprise#80467

-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

Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_ext

Steps to reproduce:
- Open Expenses.
- Upload a sample expense pdf. The blue ribbon shows up saying “”
- Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense.
- Go back to the expenses list view

Issue:
Notice this expense is at the top of the list and grayed out

Cause:
The order is determined by the extract_state_processed field:
https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_extract/models/hr_expense.py#L21

An expense is muted when this field is set to `True`:
https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/hr_recruitment_extract/views/hr_applicant_views.xml#L67

Solution:
We override `iap_extract` method
https://github.com/odoo/enterprise/blob/2e3113562309bf4d440e12ab09eaf94d0b302f1f/iap_extract/models/extract_mixin.py#L69
If the expense is not in draft, it indicates that the process continued without waiting for the extraction process to complete (values were manually entered).
To ensure a consistent extraction state, we extend the "Check OCR Status" logic to prevent an infinite waiting_extraction status.

opw-4239404

Forward-Port-Of: odoo/enterprise#76015
Forward-Port-Of: odoo/enterprise#75202

There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice. Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron. **Reproduction/Rationale**: - Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it - The order might be to be signed but not marked to be paid for acceptanc

There is no reason to not reset the payment exception state if an invoice is in draft and the subscription has not to be paid before the invoice.

Also reset the next payment date on reset of the order/subscription and also make it eligible to be invoiced via cron.

**Reproduction/Rationale**:

- Have a scenario where the invoice of a subscription is proposed to be posted manually instead of automatically posting it
- The order might be to be signed but not marked to be paid for acceptance
- Therefore the signature will confirm the order and the subscription will be invoiced via cron later
- The draft is, as stated, not a failure but the wanted behavior in this scenario and no payment exception is possible because there is no payment related and created on confirmation.

As the approach is to automatically put the order into a payment exception it is very important to catch ALL the scenarios where it needs to be removed. (this approach should be reconsidered in master IMO as it is a trap and rabbit hole)

Info: @wt-io-it

Forward-Port-Of: odoo/enterprise#79391

Description of the issue/feature this PR addresses: ticket id: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - MENA l10n module descriptions were uncomplete or unconsistent Desired behavior after PR is merged: - improve l10n module description for MENA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#80110 Forward-Port-Of: odoo/enterprise#75666

Description of the issue/feature this PR addresses:
ticket id: https://www.odoo.com/odoo/my-tasks/4179478

Current behavior before PR:
- MENA l10n module descriptions were uncomplete or unconsistent

Desired behavior after PR is merged:
- improve l10n module description for MENA



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

Forward-Port-Of: odoo/enterprise#80110
Forward-Port-Of: odoo/enterprise#75666

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

- Positive-Negative total amounts were set to `''` instead of `'000000000000000'` when they were zero. - In the descriptive field there's now the reconciled moves name and not the batch payment name. - File import we use for troubleshooting used to read the field `creditor_sia_code` as `int` but it's `alnum`. - `negative_amount` amount was the sum of the payment amounts, and it has some rounding differences. Now I'm using the Batch Payment amount. - The total in the description field of each

- Positive-Negative total amounts were set to `''` instead of `'000000000000000'` when they were zero.
- In the descriptive field there's now the reconciled moves name and not the batch payment name.
- File import we use for troubleshooting used to read the field `creditor_sia_code` as `int` but it's `alnum`.
- `negative_amount` amount was the sum of the payment amounts, and it has some rounding differences. Now I'm using the Batch Payment amount.
- The total in the description field of each payment section is correct, but it was rounded incorrectly instead in another field on the first row of the section.
- Now using ASCII instead of UTF8 - accents are changed to apostrophes as per the Company Registry in Italy
- `payment_date` in record `14` should be `invoice_date_due`
- Test has been adjusted.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4535559)
opw-4535559

Forward-Port-Of: odoo/enterprise#80539
Forward-Port-Of: odoo/enterprise#78827

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

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

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

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

Issue: When we export a report to xlsx containing some amounts in foreign currency, those amounts are exported as values in the file, and loose any kind of currency symbols. It then becomes impossible to know what currency they were expressed in. Solution: When a column has an expression label with the 'currency' word inside, adds a new column right next to it, with the currency 3 letters code as value. This is done in the accounting reports framework and so is used on all reports using a c

Issue:
When we export a report to xlsx containing some amounts in foreign currency, those amounts are exported as values in the file, and loose any kind of currency symbols. It then becomes impossible to know what currency they were expressed in.

Solution:
When a column has an expression label with the 'currency' word inside, adds a new column right next to it, with the currency 3 letters code as value. This is done in the accounting reports framework and so is used on all reports using a custom engine.

task-4011008

Forward-Port-Of: odoo/enterprise#76441

We remove unnecessary blackbox call in preSyncAllOrders method. Before we were calling the blackbox every time we were syncing orders with the server, even if it was not useful when there was no line change. Now we only call the blackbox when there is at least a line change. Forward-Port-Of: odoo/enterprise#75981

We remove unnecessary blackbox call in preSyncAllOrders method. Before we were calling the blackbox every time we were syncing orders with the server, even if it was not useful when there was no line change. Now we only call the blackbox when there is at least a line change.

Forward-Port-Of: odoo/enterprise#75981

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