This fix prevents formatting markers like <tab> and <br> from appearing as plain text in selection fields. Users will now see cleaner, properly spaced account and country labels, reducing confusion during data entry.

[1] introduces the new "odoomark" syntax where \<tab\> is supposed
to be displayed as a tab in m2o fields, notably.

[2] changes \<tab\> to \t and \<br\> to \n but does not update some uses.

This lead to \<tab\> and \<br\> appearing in plain text in the m2o selection.

task-4783344

[1]: f18bbfa6748c4be7f2f22ade479d00b1c1443468
[2]: 5effbe451d580c268c7e524fbf71640552111e18

The VoIP call screen no longer shows a transfer button for a feature that is not yet available. This prevents users from clicking an action that would not work and reduces confusion during calls.

The feature is not implemented yet. Don't show buttons that aren't mapped to anything.

This fix restores required planning information on the sales order form so the planned hours button can open correctly. Users can now confirm quotations and access related planning details without encountering an error.

Before this commit, due to a cleaning of sale order views, the `planning_first_sale_line_id` and `planning_initial_date` has been removed from the sale order form view but those fields have to be loaded in the form view to be used as default values when the user clicks on `Planned\n x Hours` stat button, otherwise a traceback will be occurred.

This commit introduces again those fields in the sale order form view to be sure those fields are defined and used as default value for the `Planned\n x Hours` stat button.

Steps to reproduce
------------------

0. Install sale_planning module
1. Go to Sales app
2. Create a quotation with a product in which slots will be generated
3. Confirm the quotation
4. Click on `Planned\n x Hours` stat button

Current behavior
----------------

A traceback is occurred because `planning_first_sale_line_id` and `planning_initial_date` fields are not defined in the form view.

Expected behavior
-----------------

The action of the stat button should be executed without any issue.

task-4781696

The Documents app now updates the favorite icon as soon as a user marks or unmarks a document. This removes a confusing delay where the action seemed not to work, making document organization feel more reliable.

Steps to reproduce:
1. Go to documents
2. Try to mark your favourite document
3. It will ghost you.

Technical Reason:
Used record.load() as value was not updating instantly in the UI. 'this.props.record.data[this.props.name] = result' fetched correct value, but didn’t trigger re-render.

After this commit:
favorite icon state updates instantly.

Task-4766725

Forward-Port-Of: odoo/odoo#207877

Forward-Port-Of: odoo/odoo#207877

**Behavior before this PR:** - Create a bold or italic tag using keyboard when selection is collapsed, leave it empty. - Change selection using arrow key. - Put cursor back where format tag was created. Notice that empty element is not removed and text is formatted when writing something. **Behavior after PR is merged:** - This PR makes sure that empty format element gets removed when changing selection. - Tag will not get removed if it's parent block element is empty. task-424

**Behavior before this PR:**

- Create a bold or italic tag using keyboard when selection is collapsed, leave it empty.
- Change selection using arrow key.
- Put cursor back where format tag was created.

Notice that empty element is not removed and text is formatted when writing something.

**Behavior after PR is merged:**

- This PR makes sure that empty format element gets removed when changing selection.
- Tag will not get removed if it's parent block element is empty.

task-4240818


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

Forward-Port-Of: odoo/odoo#195018

**Current behavior before PR:** - When the height option is passed to the editor and the content exceeds that fixed height, the bottom border scrolls along with the content instead of staying anchored at the bottom. - When Enter was pressed at the bottom of a fixed-height editor, the newly inserted block was positioned outside the editable area. As a result, power buttons were also shown outside the editor until the block was scrolled into view. **Desired behavior after PR is merged:**

**Current behavior before PR:**

- When the height option is passed to the editor and the content exceeds that fixed height, the bottom border scrolls along with the content instead of staying anchored at the bottom.
- When Enter was pressed at the bottom of a fixed-height editor, the newly inserted block was positioned outside the editable area. As a result, power buttons were also shown outside the editor until the block was scrolled into view.

**Desired behavior after PR is merged:**

- The bottom border now remains fixed at the bottom of the editor when the height option is set, even if the content overflows and becomes scrollable.
- Power buttons are no longer displayed while the block is outside the visible editable area.

task: 4718217

Forward-Port-Of: odoo/odoo#206081

**Current behaviour before PR:** When there is a text having background color, inserting a tab at the beginning of text creates a tab with background color. **Desired behaviour after PR is merged:** Now, if there is a text having background color, - Inserting tab at the beginning of text, tab will not have background color. - Inserting tab in the middle of a text, tab will have a background color corresponding to the text. - Inserting tab in the end of text, tab will have a backgro

**Current behaviour before PR:**

When there is a text having background color, inserting a tab at the beginning of text creates a tab with background color.

**Desired behaviour after PR is merged:**

Now, if there is a text having background color,

- Inserting tab at the beginning of text, tab will not have background color.
- Inserting tab in the middle of a text, tab will have a background color corresponding to the text.
- Inserting tab in the end of text, tab will have a background color corresponding to the text.

task-4381135



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

Forward-Port-Of: odoo/odoo#199733

In this PR: ## [FIX] tools: don't export attributes that aren't translated anyway PR #162079 made the list of translated attributes shared between QWeb and OWL templates. In hindsight, this was not a good idea, since: - some attributes are exclusive to QWeb (e.g.: string) - t-attf- variants of attributes are not translated in OWL - it does not reflect the list of attributes that OWL actually translates ## [IMP] tools: add missing ARIA attributes to OWL_TRANSLATED_ATTRS https://github

In this PR:
##  [FIX] tools: don't export attributes that aren't translated anyway
PR #162079 made the list of translated attributes shared between QWeb and OWL templates. In hindsight, this was not a good idea, since:

- some attributes are exclusive to QWeb (e.g.: string)
- t-attf- variants of attributes are not translated in OWL
- it does not reflect the list of attributes that OWL actually translates

## [IMP] tools: add missing ARIA attributes to OWL_TRANSLATED_ATTRS
https://github.com/odoo/owl/pull/1679 made human-readable ARIA attributes translated by Owl.
This commit updates OWL_TRANSLATED_ATTRS so that ARIA attributes are also correctly exported for translation, and will therefore be fully translatable when the next version of Owl is released.

## ~~[IMP] tools: make 'confirm-label' and 'cancel-label' translatable~~
~~'cancel-label' and 'confirm-label' are missing from the list of attributes to export for translation. This commit adds them to the list.~~

Forward-Port-Of: odoo/odoo#208861
Forward-Port-Of: odoo/odoo#204692

Currently, when we are accessing the `parent_ids` of an archived company with code `company.sudo().parent_ids`, it will return an empty record, and an error will be generated when code tries to access `max()` from that empty record at code line [1]. ``` >>> company = self.env['res.company'].browse(2) >>> company res.company(2,) >>> company.active False >>> company.sudo().parent_ids res.company() >>> max(c.hard_lock_date or date.min for c in company.sudo().parent_ids

Currently, when we are accessing the `parent_ids` of an archived company
with code `company.sudo().parent_ids`, it will return an empty record, and an
error will be generated when code tries to access `max()` from that empty
record at code line [1].

```
  >>> company = self.env['res.company'].browse(2)
  >>> company
  res.company(2,)
  >>> company.active
  False
  >>> company.sudo().parent_ids
  res.company()
  >>> max(c.hard_lock_date or date.min for c in company.sudo().parent_ids)
  Traceback (most recent call last):
    File "/usr/lib/python3.12/code.py", line 90, in runcode
      exec(code, self.locals)
    File "<console>", line 1, in <module>
  ValueError: max() iterable argument is empty
  >>> max(c.hard_lock_date or date.min for c in 
  company.sudo().with_context(active_test=False).parent_ids)
  datetime.date(1, 1, 1)
  >>> 
  >>> 
```
This commit fixes the above issue by setting `active_test=False`, which
allows access to `archived (inactive)` parent companies, ensuring that
`company.sudo().parent_ids` includes them and avoids passing an empty
sequence to max()

[1] - https://github.com/odoo/odoo/blob/ac3924508016178427c7962fa3b8e645e7e03835/addons/account/models/company.py#L393

sentry-6581609140

Forward-Port-Of: odoo/odoo#208526

Description of the issue/feature this PR addresses: Some of our clients have reported that the company logo on printed invoices is too small. This PR slightly increases its size and adds a small bottom margin. Current behavior before PR: The height in logo is 45px Desired behavior after PR is merged: Increases to 65px --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209155

Description of the issue/feature this PR addresses:
Some of our clients have reported that the company logo on printed invoices is too small. This PR slightly increases its size and adds a small bottom margin.

Current behavior before PR:
The height in logo is 45px

Desired behavior after PR is merged:
Increases to 65px



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

Forward-Port-Of: odoo/odoo#209155

Description of the issue/feature this PR addresses: mailing.mailing model is reused between Mail Marketing and SMS Marketing apps, however warning message defined in Mail Marketing about incorrect mail server is not relevant for SMS Marketing. Affected versions : 16.0+ (probably since v13.0 but older versions not maintained anymore) Current behavior before PR: In some cases, you can end up with a warning on SMS mailing form stating "This email from can not be used with this mail server.[..

Description of the issue/feature this PR addresses:
mailing.mailing model is reused between Mail Marketing and SMS Marketing apps, however warning message defined in Mail Marketing about incorrect mail server is not relevant for SMS Marketing.
Affected versions : 16.0+ (probably since v13.0 but older versions not maintained anymore)

Current behavior before PR:
In some cases, you can end up with a warning on SMS mailing form stating "This email from can not be used with this mail server.[...]"

For instance you can end up in this case if : 
- You have defined an ir.config_parameter mass_mailing.mail_server_id
- from_filter from this mail_server does not match email_from from user creating SMS Marketing

Desired behavior after PR is merged:
The above warning is only relevant for Mail marketing but not for SMS marketing.

This PR therefore proposes to generate warning message only if mailing_type == "mail"




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

Forward-Port-Of: odoo/odoo#205912

After [this commit][1], a warning message was added when trying to submit a survey. However, its content was not translated because the `survey` module didn't load its translations on the frontend. This fix makes the translations available in the frontend. Another bug we encountered is that the regex to determine a survey frontend URL (added in [this commit][2]) did not take into account all possible language codes in Odoo. Therefore, some languages resulted in a 404 page when trying to us

After [this commit][1], a warning message was added when trying to submit a survey. However, its content was not translated because the `survey` module didn't load its translations on the frontend.

This fix makes the translations available in the frontend.

Another bug we encountered is that the regex to determine a survey frontend URL (added in [this commit][2]) did not take into account all possible language codes in Odoo. Therefore, some languages resulted in a 404 page when trying to use them.

This fix adapts the regex to support all language codes in Odoo.

[1]: https://github.com/odoo/odoo/commit/d8ba7013b0f059c157ee172088200c6fc99e0c26
[2]: https://github.com/odoo/odoo/commit/4b4bf6a121d0eb66267b10cb9bafb04c9d3a72ff

[opw-4747797](https://www.odoo.com/odoo/project.task/4747797)

Forward-Port-Of: odoo/odoo#208762

Scenario: create a long blog page article and enable comments Result: there is a grey unusable textarea with o-mail-Composer-fake over the blog content. Issue: in 7710c3331ebd22f8396870bd0731f8c1152d9c41 the fake textarea used to compute the height of the real textarea, had a position of -10000px, which make sense in the backend to make it hidden. But in 18.0 with 368eb78a9cedfce0802b64fd2782e1c018541e40 we use the backend composer on portal, where a page could be higher than 10000px and the f

Scenario: create a long blog page article and enable comments

Result: there is a grey unusable textarea with o-mail-Composer-fake
over the blog content.

Issue: in 7710c3331ebd22f8396870bd0731f8c1152d9c41 the fake textarea
used to compute the height of the real textarea, had a position of
-10000px, which make sense in the backend to make it hidden. But in
18.0 with 368eb78a9cedfce0802b64fd2782e1c018541e40 we use the backend
composer on portal, where a page could be higher than 10000px and the
fake textarea can be shown.

Fix: hide it better (also to the left, and in case there was a
10000x10000 pixels page with comment at the bottom right, make it
invisible).

opw-4719975

Forward-Port-Of: odoo/odoo#207054

Since #203903 the user `im_status` is sent directly from the identity model in order to take into account other module overrides without having to re-establish them client side. This commit removes the method patching `updateImStatus` as the value arrives client side already patched from `hr_holidays`. Forward-Port-Of: odoo/odoo#207471

Since #203903 the user `im_status` is sent directly from the identity model in order to take into account other module overrides without having to re-establish them client side.

This commit removes the method patching `updateImStatus` as the value arrives client side already patched from `hr_holidays`.

Forward-Port-Of: odoo/odoo#207471

This commit removes the z-index priority of kanban groups, headers and quick create over the no-content helper since it became useless with https://github.com/odoo/odoo/pull/148138 and can now cause display issues when these elements are on top of each other (which can happen with the quick create column). task-4778356 Forward-Port-Of: odoo/odoo#209059 Forward-Port-Of: odoo/odoo#208795

This commit removes the z-index priority of kanban groups, headers and quick create over the no-content helper since it became useless with https://github.com/odoo/odoo/pull/148138 and can now cause display issues when these elements are on top of each other (which can happen with the quick create column).

task-4778356

Forward-Port-Of: odoo/odoo#209059
Forward-Port-Of: odoo/odoo#208795

Currently, an exception is raised when a user attempts to import an attachment with an invalid TypeCode in the XML file. Steps to Reproduce: 1. Install the `account_edi_ubl_cii` module. 2. Navigate to Invoice Module -> Customers -> Invoices. 3. Attempt to upload an attachment with an invalid TypeCode in the XML file. 4. An error occurs. Error: `TypeError cannot unpack non-iterable NoneType object ` This issue [1] occurs when a user imports an attachment with an invalid TypeCode

Currently, an exception is raised when a user attempts to import an attachment with an invalid TypeCode in the XML file.

Steps to Reproduce:

1. Install the `account_edi_ubl_cii` module.
2. Navigate to Invoice Module -> Customers -> Invoices.
3. Attempt to upload an attachment with an invalid TypeCode in the XML file.
4. An error occurs.

Error:
`TypeError
cannot unpack non-iterable NoneType object
`

This issue [1] occurs when a user imports an attachment with an invalid TypeCode in the XML file [2]. The function returns None, which cannot be assigned to multiple variables, leading to an error.

[1] - https://github.com/odoo/odoo/blob/29206fb5f9c733ec8751d8d4910e4df686f29506/addons/account_edi_ubl_cii/models/account_edi_common.py#L262

[2] - https://drive.google.com/file/d/1Ww1D302rvMwM2OQBAZJNnTcI0n0xUGWQ/view

This fix resolves the issue by ensuring that if an invalid move_type_code is found, it returns None, None, preventing the error.

sentry-6303716506

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

Forward-Port-Of: odoo/odoo#208821
Forward-Port-Of: odoo/odoo#197927

- saas-17.4 issue 2: ### Steps to Reproduce: - Install the hr_timesheet module. - Create a portal user. - Create a project, task, and sub-task (with timesheet entries). - Share the project with the portal user. - Log in as the portal user. - Open the shared project and navigate to the task. - Open timesheet. ### Issue: When a portal user tries to open the timesheet of a shared project task from a mobile device, an error occurs. ### Cause: The po

- saas-17.4

issue 2:
###  Steps to Reproduce:
   - Install the hr_timesheet module.
   - Create a portal user.
   - Create a project, task, and sub-task (with timesheet entries).
   - Share the project with the portal user.
   - Log in as the portal user.
   - Open the shared project and navigate to the task.
   - Open timesheet.

### Issue:
   When a portal user tries to open the timesheet of a shared project task from a mobile device,
   an error occurs.

### Cause:
   The portal user does not have access to the analytic account, which triggers this error.  The form view for analytic.line 
   in the analytic module includes analyti_account_id.

### Solution:
   In this commit, we have used the `timesheet_view_form_portal_user` form view. This view  does not include 
   analytic_account_id, which prevents the access error from occurring.

task-4369891

Forward-Port-Of: odoo/odoo#208889
Forward-Port-Of: odoo/odoo#168847

- Introduced `canBeRemoved` property in `PosOrderline` to simplify zero-qty line removal logic. - Updated payment screen to use `canBeRemoved` for cleaner filtering. - Added reusable tour helpers: `clickDropDownItemText` and `clickSettleOrderName`. See also: odoo/enterprise#84117 Task [link](https://www.odoo.com/odoo/project/967/tasks/4751971) task-4751971 Forward-Port-Of: odoo/odoo#207444

- Introduced `canBeRemoved` property in `PosOrderline` to simplify zero-qty line removal logic.
- Updated payment screen to use `canBeRemoved` for cleaner filtering.
- Added reusable tour helpers: `clickDropDownItemText` and `clickSettleOrderName`.

See also: odoo/enterprise#84117

Task [link](https://www.odoo.com/odoo/project/967/tasks/4751971)
task-4751971

Forward-Port-Of: odoo/odoo#207444

Currently, an error occurs on reopening a POS session if its 'Login Number Sequence' record has been deleted. This results in preventing the user from accessing the session. **Steps to produce:** - Install the `point_of_sale` module (with demo data). - Open the register of the **Furniture Shop** from the POS dashboard. - Now, without closing the register of shop, Navigate to: `Settings > Technical > Sequences & Identifiers > Sequences (list)`. - Delete the `Login Number Sequence of Sess

Currently, an error occurs on reopening a POS session if its 'Login Number Sequence' record has been deleted. This results in preventing the user from accessing the session.

**Steps to produce:**
- Install the `point_of_sale` module (with demo data).
- Open the register of the **Furniture Shop** from the POS dashboard.
- Now, without closing the register of shop, Navigate to:
 `Settings > Technical > Sequences & Identifiers > Sequences (list)`.
- Delete the `Login Number Sequence of Session 3` sequence record.
- Reopen that shop session again.
- Observe the error at the backend.

**Error:**
```
UndefinedFunction
operator does not exist: integer = boolean
LINE 1: SELECT number_next FROM ir_sequence WHERE id=false FOR UPDAT...
                                                    ^
HINT:  No operator matches the given name and argument types. You might need
to add explicit type casts.
```

The error occurs because the system attempts to access the `login_number_seq_id` of the POS session at [1], but it is unavailable as the user has already deleted it.

This commit adds validation to prevent deletion of the 'Login Number Sequence' if the associated POS session is not closed.

[1] - https://github.com/odoo/odoo/blob/948f6c5afdf76b9a25daa120fec1edd21c5c08d6/addons/point_of_sale/models/pos_session.py#L404-L406

Sentry-6276299189


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

Forward-Port-Of: odoo/odoo#197715

[FIX] base: fix error message partner form This commit will fix two things: - Currently, the error message if you have a duplicate tax id or a duplicate company registry in the partner form displays the label of the concerned field twice. With this commit, we display the label of that field only once. From : "Potential duplicates: Partner A (Same Tax ID Tax ID)" To : "Potential duplicates: Partner A (Same Tax ID)" - Currently, the error message shows only 1 partner even if the Tax ID

[FIX] base: fix error message partner form

This commit will fix two things:
- Currently, the error message if you have a duplicate tax id or a
duplicate company registry in the partner form displays the label of the
concerned field twice. With this commit, we display the label of that
field only once.
From : "Potential duplicates: Partner A (Same Tax ID Tax ID)"
To : "Potential duplicates: Partner A (Same Tax ID)"

- Currently, the error message shows only 1 partner even if the Tax ID
is duplicated with a partner A and the Company Registry is duplicated
with a partner B. With this commit, the partner
with the same Tax ID and the partner with the same Company Registry are
both printed in the error message if they are different.
From : "Potential duplicates: Partner A (Same Tax ID Tax ID and Company
Registry Company Registry)"
To : "Potential duplicates: Partner A (Same Tax ID) and Partner B (Same
Company Registry)"

The choice to not display the value of the field (vat or company
registry) was done because of technical constraints : it would be too
much of a development for an information that's already displayed on the
screen a few lines further on.

task-4668697

runbot : https://runbot.odoo.com/runbot/bundle/saas-18-1-error-message-partner-form-roto-358947

Forward-Port-Of: odoo/odoo#208830
Forward-Port-Of: odoo/odoo#204733

Before PRs https://github.com/odoo/odoo/pull/154912 and https://github.com/odoo/odoo/pull/177079, _free_reservation preserved MTO links by retaining move_orig_ids, allowing Manufacturing Orders (MOs) to reserve components from replenishment pickings. PR https://github.com/odoo/odoo/pull/149054 added replenishment moves to the MO’s procurement.group and assigned move_dest_ids to link them to component moves, supporting 2-step manufacturing flows. PR https://github.com/odoo/odoo/pull/154912

Before PRs https://github.com/odoo/odoo/pull/154912 and https://github.com/odoo/odoo/pull/177079, _free_reservation preserved MTO links by
retaining move_orig_ids, allowing Manufacturing Orders (MOs) to reserve
components from replenishment pickings.
PR https://github.com/odoo/odoo/pull/149054 added replenishment moves to the MO’s procurement.group and
assigned move_dest_ids to link them to component moves, supporting 2-step
manufacturing flows.
PR https://github.com/odoo/odoo/pull/154912 introduced the stock.break_mto parameter to conditionally preserve
move_orig_ids, while PR https://github.com/odoo/odoo/pull/177079 removed it, making move_orig_ids clearing
unconditional for MTO-to-MTS transitions, reintroducing a regression due to
the move_dest_ids assignment.

Steps to Reproduce
===================
1. Create an MO with a component qty of 20 units and confirm it.
2. Scrap 5 units of the component with Replenish enabled.
3. Validate the replenishment transfer.
4. Check the MO component line. The component qty is reduced to 5.

Issue
=====
The move_dest_ids assignment to replenishment moves (from https://github.com/odoo/odoo/pull/149054) prevents
 _trigger_assign from reserving correct MO component quantities when
move_orig_ids are cleared (per https://github.com/odoo/odoo/pull/177079), as the link to the original MO
requirements is broken.

Fix
===
Removed the move_dest_ids assignment for replenish moves enabling trigger_assign
to automatically reserve the correct component quantities, while maintaining the
MTO-to-MTS transition (cleared move_orig_ids) and the procurement.group
assignment.

Task: https://github.com/odoo/odoo/commit/44437975bdaf1e7c4f5540a5cb789d9db0ec0b0b

Forward-Port-Of: odoo/odoo#204211

Before this commit: ================== The `Ship Later` date was displayed in an incorrect or broken format on the payment screen. After this commit: ==================== The `Ship Later` date is now displayed in the correct and readable format, consistent with how it appeared before the bug. Task: 4702375 Forward-Port-Of: odoo/odoo#204948

Before this commit:
==================
The `Ship Later` date was displayed in an incorrect or broken format on the payment screen.

After this commit:
====================
The `Ship Later` date is now displayed in the correct and readable format, consistent with how it appeared before the bug.

Task: 4702375

Forward-Port-Of: odoo/odoo#204948

This update is done without an upgrade because the old format will still work. But for cleanliness, templates should reflect what the editor will actually do, and since [This commit], files are `span` elements, not `div` anymore, and they are wrapped in a baseContainer (`div` or `p`). [This commit]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0 task-4745902 Forward-Port-Of: odoo/enterprise#83899

This update is done without an upgrade because the old format will still work. But for cleanliness, templates should reflect what the editor will actually do, and since [This commit], files are `span` elements, not `div` anymore, and they are wrapped in a baseContainer (`div` or `p`).

[This commit]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0

task-4745902

Forward-Port-Of: odoo/enterprise#83899

When updating a parent product, the MPS view will load ALL the components on the page even if it breaks the pager limit. Previously, there was a refresh at every change. It was annoying so it was removed. However this refresh made sure to reduce the number of records shown to the pager limit. The solution is to simply slice the received array of lines to the n first records, n being the value of `this.env.config.limit`. opw-4778588 Forward-Port-Of: odoo/enterprise#85159

When updating a parent product, the MPS view will load ALL the components on the page even if it breaks the pager limit.
Previously, there was a refresh at every change. It was annoying so it was removed. However this refresh made sure to reduce the number of records shown to the pager limit.
The solution is to simply slice the received array of lines to the n first records, n being the value of `this.env.config.limit`.

opw-4778588

Forward-Port-Of: odoo/enterprise#85159

Error message string is no longer present in workflow and can be removed in 18.3+. opw-4559772 Forward-Port-Of: odoo/enterprise#84469

Error message string is no longer present in workflow and can be removed in 18.3+.

opw-4559772

Forward-Port-Of: odoo/enterprise#84469

when the option is not set key error is raised , this due to when onchange is called the default value is not set but being also called with empty option build_error-107919 Forward-Port-Of: odoo/enterprise#82825

when the option is not set key error is raised ,
this due to when onchange is called the default value is not set but being also called  with empty option

build_error-107919

Forward-Port-Of: odoo/enterprise#82825

Commit odoo/odoo@abd909498e4fd relaxed the multi-company rule for hr.employee (more records are visible). Instead the action domains were updated to include the restricted company rules (see only from your company) The domains in the Employee dashboard was not updated though. It means the dashboard takes into account employees from other companies (as allowed by the ir.rule) opw-4777122 Forward-Port-Of: odoo/enterprise#84972

Commit odoo/odoo@abd909498e4fd relaxed the multi-company rule for hr.employee (more records are visible).

Instead the action domains were updated to include the restricted company rules (see only from your company)

The domains in the Employee dashboard was not updated though.

It means the dashboard takes into account employees from other companies (as allowed by the ir.rule)

opw-4777122

Forward-Port-Of: odoo/enterprise#84972

If the user deleted some leave types, the payroll app will not be able to function anymore, in this PR we fallback and only browse for the ones that were not deleted Forward-Port-Of: odoo/enterprise#85119

If the user deleted some leave types, the payroll app will not be able to function anymore, in this PR we fallback and only browse for the ones that were not deleted

Forward-Port-Of: odoo/enterprise#85119

This commit fixes the issue where the WhatsApp account was from another company and the related channel was not being read correctly. Adding a test to ensure that the WhatsApp account is read correctly even when the account is from another company. task-4775511 Forward-Port-Of: odoo/enterprise#84860

This commit fixes the issue where the WhatsApp account was from another company and the related channel was not being read correctly.

Adding a test to ensure that the WhatsApp account is read correctly even when the account is from another company.

task-4775511

Forward-Port-Of: odoo/enterprise#84860

To ease multi-company usage, we introduce the company_id field on insurance views since one insurance per company has to be created Forward-Port-Of: odoo/enterprise#85129 Forward-Port-Of: odoo/enterprise#84968

To ease multi-company usage, we introduce the company_id field on insurance views
since one insurance per company has to be created

Forward-Port-Of: odoo/enterprise#85129
Forward-Port-Of: odoo/enterprise#84968

The mx payment method on a payment should be the one from the pos payment method. Steps: - Have a PoS payment method with `l10n_mx_edi_payment_method_id` != `payment_method_transferencia` - Open a PoS session, make an order with this payment method and close the session - Look for the related payment --> `l10n_mx_edi_payment_method_id` == `payment_method_transferencia` With this commit, we override the compute to get the payment way from the pos payment method. opw-4699064 Forward-Port-

The mx payment method on a payment should be the one from
the pos payment method.

Steps:

- Have a PoS payment method with `l10n_mx_edi_payment_method_id` !=
  `payment_method_transferencia`
- Open a PoS session, make an order with this payment method and close
  the session
- Look for the related payment
--> `l10n_mx_edi_payment_method_id` == `payment_method_transferencia`

With this commit, we override the compute to get the payment way from
the pos payment method.

opw-4699064

Forward-Port-Of: odoo/enterprise#85043
Forward-Port-Of: odoo/enterprise#83323

In the community PR, we have used the timesheet_view_form_portal_user form view for the portal user. To ensure that the status bar is not visible to the portal user, we added a group restriction. An alternative approach would be to hide the status bar based on context, but I did not find it suitable. Therefore, we opted to use the group restriction. task-3969988 Forward-Port-Of: odoo/enterprise#84917 Forward-Port-Of: odoo/enterprise#74760

In the community PR, we have used the timesheet_view_form_portal_user form view for the portal user. To ensure that the status bar is not visible to the portal user, we added a group restriction.

An alternative approach would be to hide the status bar based on context, but I did not find it suitable. Therefore, we opted to use the group restriction.

task-3969988

Forward-Port-Of: odoo/enterprise#84917
Forward-Port-Of: odoo/enterprise#74760

Sometimes, when opening the documents folder, test folder is hidden on a second page, even if we open a parent folder first. With this fix, we search for the folder directly through search bar, eliminating undeterminism from the test. Forward-Port-Of: odoo/enterprise#85041 Forward-Port-Of: odoo/enterprise#83486

Sometimes, when opening the documents folder, test folder is hidden on a second page, even if we open a parent folder first. With this fix, we search for the folder directly through search bar, eliminating undeterminism from the test.

Forward-Port-Of: odoo/enterprise#85041
Forward-Port-Of: odoo/enterprise#83486

- This fix backport some of the changes made in the `master` PR (https://github.com/odoo/enterprise/pull/80267) to the `saas-18.2 branch`. - Multiples issues were appearing when invoicing a POS order containing settling lines. In this fix we put the quantity of the settling lines to 0 before sending it to the backend (as it's done in `master`), that way when invoicing the settling order it just act as a note and does not create a new debt. - When paying an order with customer account and gener

- This fix backport some of the changes made in the `master` PR (https://github.com/odoo/enterprise/pull/80267) to the `saas-18.2 branch`.
- Multiples issues were appearing when invoicing a POS order containing settling lines. In this fix we put the quantity of the settling lines to 0 before sending it to the backend (as it's done in `master`), that way when invoicing the settling order it just act as a note and does not create a new debt.
- When paying an order with customer account and generating an invoice from PoS, now we can pay (partially or not) the invoice from the backend, and it will be reflected in the PoS (as it's done in `master`).

First issue to reproduce (settle order with invoicing):
- Open PoS
- Select a customer
- Pay a product with customer account
- Open customer popup and search for this customer (he should have a debt based on the previous amount)
- Settle the due account
- Click "Payment"
- Enable "invoice"
- Pay with card
- => Open customer popup and look for this customer again, he still have a debt

Second issue to reproduce (paying invoice from backend):
- Open PoS
- Select a customer
- Pay a product with customer account
- Open customer popup and search for this customer (he should have a debt based on the previous amount)
- Close PoS session
- Open the backend and go to the customer invoice
- Open the invoice and pay it half of the amount
- Go back to PoS and open the customer popup
- Search for this customer and click settle due accounts
- The amount due from the PoS order is not the same (the amount paid from the backend is not reflected in the PoS)

task-id: 4751971

community PR: https://github.com/odoo/odoo/pull/207444

Forward-Port-Of: odoo/enterprise#84117

- Create a vendor bill with two lines at the exact same price. - Set the start and end dates to the same day, but in a different month than the bill date. Then confirm the bill. - In the Deferred Entries, there are only the deferral_moves and no moves_fully_deferred. The method _generate_deferred_entries was refactored by a71c38fa6325cd18c686352d8f68d350461d37d0 . However, inside the loop to remove deferred entries in the same month, the filter is used on move_fully_deferred.deferred_ori

- Create a vendor bill with two lines at the exact same price.
 - Set the start and end dates to the same day, but in a different month than the bill date. Then confirm the bill.
 - In the Deferred Entries, there are only the deferral_moves and no moves_fully_deferred.

 The method _generate_deferred_entries was refactored by a71c38fa6325cd18c686352d8f68d350461d37d0 . However, inside the loop to remove deferred entries in the same month, the filter is used on move_fully_deferred.deferred_original_move_ids.deferred_move_ids which contains deferral_moves + moves_fully_deferred. This means that when there are two lines with the same price, the current moves_fully_deferred is matched with the other in the filtered. This causes both moves_fully_deferred to be removed.

opw-4698646

Forward-Port-Of: odoo/enterprise#84776
Forward-Port-Of: odoo/enterprise#83791

- With l10n_mx_edi, create an invoice and send it to the cfdi. Download the cfdi xml. - Import the xml as a vendor bill. Confirm and click on Update SAT. - The vendor bill list view the l10n_mx_edi_cfdi_sat_state is set to false despite the l10n_mx_edi.document.sat_state being set. https://github.com/odoo/enterprise/commit/b34a4d105c67807628284257be51295e33da6bf0 added the ability to import cfdi xml as vendor bills and updated the selection for l10n_mx_edi.document.state with invoice_receiv

- With l10n_mx_edi, create an invoice and send it to the cfdi. Download the cfdi xml.
- Import the xml as a vendor bill. Confirm and click on Update SAT.
- The vendor bill list view the l10n_mx_edi_cfdi_sat_state is set to false despite the l10n_mx_edi.document.sat_state being set.

https://github.com/odoo/enterprise/commit/b34a4d105c67807628284257be51295e33da6bf0 added the ability to import cfdi xml as vendor bills and updated the selection for l10n_mx_edi.document.state with invoice_received. However the compute _compute_l10n_mx_edi_cfdi_state_and_attachment which depends on l10n_mx_edi.document.state was not updated to take into account that new possible selection.

opw-4673134

Forward-Port-Of: odoo/enterprise#84764
Forward-Port-Of: odoo/enterprise#83629

Extension of l10n_co_edi to allow creation of mandate invoices. - Adding mandate-related fields for product_template. - Adding relevant EDI XML section for mandate products. Task [link](https://www.odoo.com/odoo/project/967/tasks/4302423) task-4302423 Forward-Port-Of: odoo/enterprise#77673

Extension of l10n_co_edi to allow creation of mandate invoices.
- Adding mandate-related fields for product_template.
- Adding relevant EDI XML section for mandate products.

Task [link](https://www.odoo.com/odoo/project/967/tasks/4302423)
task-4302423

Forward-Port-Of: odoo/enterprise#77673

Before this commit, when the user is in `Timesheets > To Validate > All Timesheets` and group by `Sale Order Item`, a traceback is occurred because no fields are given for the group by of web_read_group made on `planning.slot`, the reason is because we just check if `project_id` and/or `employee_id` are used in row fields or section field of the grid view of timesheets to add additional data based on planning.slot in the same period of the grid view. This commit avoids calling the web_read_gr

Before this commit, when the user is in `Timesheets > To Validate > All Timesheets` and group by `Sale Order Item`, a traceback is occurred because no fields are given for the group by of web_read_group made on `planning.slot`, the reason is because we just check if `project_id` and/or `employee_id` are used in row fields or section field of the grid view of timesheets to add additional data based on planning.slot in the same period of the grid view.

This commit avoids calling the web_read_group on planning.slot model when no rows managed are found in the grid view since the result of the web_read_group will be useless in that case.

Steps to reproduce
------------------

0. Install `project_timesheet_forecast` module
1. Go to `Timesheets > To Validate > All Timesheets`
2. Go to the grid view
3. Group by `Sale Order Item`

Expected behavior
-----------------

The grid view should be loaded without any issue and show the so_line field as row.

Current behavior
----------------

A traceback is occurred inside the web_read_group on planning.slot model.

task-4782077

Forward-Port-Of: odoo/enterprise#85022

* quality_mrp, stock_barcode ### Steps to reproduce: - Create a product FP with a bom: - 1 x comp - Create a control check point per product for FP for the manufacturing operation type - Go to the barcode app - Scan the manufacturing operation type - Scan FP and set the qty_producing - Click quality check #### > Traceback ### Cause of the issue: By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As

* quality_mrp, stock_barcode

### Steps to reproduce:

- Create a product FP with a bom:
    - 1 x comp
- Create a control check point per product for FP for the manufacturing operation type
- Go to the barcode app
- Scan the manufacturing operation type
- Scan FP and set the qty_producing
- Click quality check
#### > Traceback

### Cause of the issue:

By scanning the manufacturing operation in the barcode we create a "New" manufacturing order that does not have a set id yet. As such, the `resId` the barcode `MainComponent` is `false`. However, this "id" is used in the orm call of the `checkQuality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L15-L19 As such, we launch a call of the `check_quality`:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/quality_mrp/models/mrp_production.py#L70-L72 that ends up raising an traceback since the `product_uom` is `False` on the "unexpected" record `mrp.production(False,)`.

### Fix:

Since we just saved the record and hence created the record prior to this call:
https://github.com/odoo/enterprise/blob/79f98e924d2f425535a7ac1919f96ff7ec4a34d8/stock_barcode_quality_control/static/src/components/main.js#L12-L15 we should rather rely on the new created id.

opw-4644128

Forward-Port-Of: odoo/enterprise#84601
Forward-Port-Of: odoo/enterprise#82688

The system fails when `ir. qweb. _ render ()` is called with a `values` argument that is not a dictionary but a `Response ' object. Steps to Produce: 1. Open `Sign` Module > Templates > Click on the `Sign Now` button of any template. 2. Copy url > delete sign reques > paste url in websie 3. The error will be visible on the terminal. Error: `AttributeError: 'Response' object has no attribute 'copy'` Solution: - Updated `get_document()` to check if `context` is not a `dict`. - If no

The system fails when `ir. qweb. _ render ()` is called with a `values` argument that is not a dictionary but a `Response ' object.

Steps to Produce:
1. Open `Sign` Module > Templates > Click on the `Sign Now` button of any template.
2. Copy url > delete sign reques > paste url in websie
3. The error will be visible on the terminal.

Error:
`AttributeError: 'Response' object has no attribute 'copy'`

Solution:
- Updated `get_document()` to check if `context` is not a `dict`.
- If not, the method now safely returns `request.not_found()`.

sentry - 6521023695

Forward-Port-Of: odoo/enterprise#82936

Somehow, translations files were lacking for this module. Done by Larissa (lman) 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#208579

Somehow, translations files were lacking for this module.

Done by Larissa (lman)

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