**Problem**: When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab). If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange

**Problem**: 
When a RFQ is created automatically (MTO, reordering rule, manual replenish) for a product which has a different currency in general information (next to cost) and in the vendor line (in the pruchase tab).
If the conditions of the vendors pricelists aren't met (ex not enough quantity) the price on the RFQ will be the cost from the "general information tab" and the currency will come from the vendor in the purchase tab. This could be an issue especially if there's a high exchange rate between the currencies. 

**Steps to reproduce**:
- in settings, activate another currency (ex:kr)
- create a new product
- set the product type as "storable product"
- set a cost in the general information tab and a currency (ex:1000kr)
- in the inventory tab set the route as "Buy"
- in the pruchase tab add a vendor line, with a vendor name, a quantity (ex:10) and a price in another currency (ex:8$)
- click on the replenish button and set a quantity below the minimum quantity of the vendor line you just created

**Current behavior**:
A RFQ is created, with a price equal to the cost set in general information and the currency of the vendor in the purchase tab (here:1000$).

**Expected behavior**:
When the conditions of the vendor's pricelist aren't met the price should be 0 and the currency should be the one of the vendor

**Fix**:
I reversed the changes made in this commit
https://github.com/odoo/odoo/pull/158650/commits/caf4974b770b3295faebdaab5014a879760ccd67 and adapted the test
Now, if the seller variable is empty (which happens when no pricelist is matched), the price is set to zero
https://github.com/odoo/odoo/blob/953eb7cc241e290e3e5d1ef19048213a206a1947/addons/purchase/models/purchase_order_line.py#L599

opw-4547212

Forward-Port-Of: odoo/odoo#202011

A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com. Forward-Port-Of: odoo/odoo#206164 Forward-Port-Of: odoo/odoo#206040

A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com.

Forward-Port-Of: odoo/odoo#206164
Forward-Port-Of: odoo/odoo#206040

Steps to reproduce: 1. Install `l10n_in_ewaybill_stock` and `sale_management` 2. Activate Units of measure 3. Create SO and add SO line with a product uom having units 4. Set this parameter `Quantity -> 1`, `UoM -> Dozen`, `Price Unit -> 12` 5. Confirm SO and related picking delivery 6. Create and generate E-waybill 7. Print Receipt The actual Taxable amount should be Rs. 12 but instead it shows 144 In this commit we fix the following issue opw-4728253 --- I confirm I hav

Steps to reproduce:
1. Install `l10n_in_ewaybill_stock` and `sale_management`
2. Activate Units of measure
3. Create SO and add SO line with a product uom having units
4. Set this parameter `Quantity -> 1`, `UoM -> Dozen`, `Price Unit -> 12`
5. Confirm SO and related picking delivery
6. Create and generate E-waybill
7. Print Receipt

The actual Taxable amount should be Rs. 12 but instead it shows 144

In this commit we fix the following issue

opw-4728253



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

Forward-Port-Of: odoo/odoo#206094

It doesn't seem to be of any use, and neither module depends on account. It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve. If you only have community tho, it blows up in your face. Which I guess is what happens in the single a

It doesn't seem to be of any use, and neither module depends on account.

It happens to pass if enterprise is available because avatax is `auto_install=['payment']` and has a dependency on `account`, so you install a payment module which installs `payment` which auto_installs avatax which installs `account` and you have account's groups available for `account`'s test utilities to resolve.

If you only have community tho, it blows up in your face. Which I guess is what happens in the single app tests.

https://runbot.odoo.com/odoo/error/163117

Forward-Port-Of: odoo/odoo#206079

* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much 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#205196 Forward-Port-Of: odoo/odoo#188760

* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much

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#205196
Forward-Port-Of: odoo/odoo#188760

Replace the non-standard '🠖' (->) character with an arrow icon in the `_search_render_results()` method for consistent and proper rendering across browsers and platforms. Forward-Port-Of: odoo/odoo#205862

Replace the non-standard '🠖' (->) character with an arrow icon in the
`_search_render_results()` method for consistent and proper rendering
across browsers and platforms.

Forward-Port-Of: odoo/odoo#205862

Printing the E-Way Bill failed if the company logo was not configured, as the QWeb template attempted to render an image using a non-existent logo. Steps to reproduce: - Remove the company logo from the company settings - Try to print an E-Way Bill for any invoice Expected: - The E-Way Bill should be printed successfully without a logo Actual: - PDF generation fails due to a template rendering error Now: - The template checks for the presence of a logo before rendering it, allow

Printing the E-Way Bill failed if the company logo was not configured, as the QWeb template attempted to render an image using a non-existent logo.

Steps to reproduce:
- Remove the company logo from the company settings
- Try to print an E-Way Bill for any invoice

Expected:
- The E-Way Bill should be printed successfully without a logo

Actual:
- PDF generation fails due to a template rendering error

Now:
- The template checks for the presence of a logo before rendering it, allowing the E-Way Bill to print even if the logo is not set.


opw-4709233


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

Forward-Port-Of: odoo/odoo#206190

This PR introduces a regression test to ensure that the sitemap remains in the default language of the website, regardless of the language version being accessed. Tests 2 scenarios: - First, configure a website with English and French language. - Set the default language to French. - Access the sitemap at /sitemap.xml -> The sitemap should be displayed in French. - Second, let the default language to be English. - Navigate to the French version of the website at /fr. - Access t

This PR introduces a regression test to ensure that the sitemap
remains in the default language of the website, regardless of the
language version being accessed.

Tests 2 scenarios:

- First, configure a website with English and French language.
- Set the default language to French.
- Access the sitemap at /sitemap.xml -> The sitemap should be displayed
    in French.
- Second, let the default language to be English.
- Navigate to the French version of the website at /fr.
- Access the sitemap at /sitemap.xml -> The sitemap should now be
    displayed in English.

This test addresses an issue that was previously fixed in commit
https://github.com/odoo/odoo/commit/809854c5d10735fb280141f5291bdb84d8d36569, but lacked a corresponding test to prevent future
regressions. This test ensures the bug reported in task-3935135 does ``
not reoccur.

**Added test in website_blog as it has routes that were translated.
Reference:
[1]: https://github.com/odoo/odoo/pull/154993#pullrequestreview-1900639267

Forward-Port-Of: odoo/odoo#190779

### Issue: - In the Attendance Gantt view, users can see all employees in the company, including those they are not allowed to manage or view. - While access rules prevent users from seeing attendance records for these employees, the employees' names still appear in the Gantt view as group headers. - This creates a misleading user experience and potentially exposes restricted information (employee names). ### Steps To Reproduce: 1. Log in as Marc Demo. 2. Open the attendance App. 3. Obs

### Issue:
- In the Attendance Gantt view, users can see all employees in the company, including those they are not allowed to manage or view.
- While access rules prevent users from seeing attendance records for these employees, the employees' names still appear in the Gantt view as group headers.
- This creates a misleading user experience and potentially exposes restricted information (employee names).

### Steps To Reproduce:
1. Log in as Marc Demo.
2. Open the attendance App.
3. Observe that all employees are shown as group headers.

### Solution:
- Since Odoo 18.0, the `employee_id` field in `hr.attendance` was given a `group_expand='_read_group_employee_id'`. this method returns all employees in the allowed companies, without checking if the user actually manages them.
- We updated the `group_expand` method `_read_group_employee_id` to restrict the list of employees shown in the Gantt view.
Now, users will only see employees for whom they are set as the `attendance_manager_id`, unless they belong to the HR Officer group or are superusers, in which case they continue to see all employees.
- This ensures that group headers in the Gantt view match the user's actual access rights.

opw-4570867

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

Forward-Port-Of: odoo/odoo#205031

# Context: A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=', note_type.id`. After the PR, it now matches all messages as long as they have a subtype. In doing so, it didn't account for the fact that in some production database, you might have `mail.message` records that have **no** message_id set, i.e. `message_id == False`. In such cases a traceba

# Context:

A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=', note_type.id`.

After the PR, it now matches all messages as long as they have a subtype.

In doing so, it didn't account for the fact that in some production database, you might have `mail.message` records that have **no** message_id set, i.e. `message_id == False`.

In such cases a traceback would be generated when sending a message from a mail.thread having an ancestor without `message_id` set.

Example:
```
    references = ' '.join(m.message_id for m in (ancestors + message_sudo))
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: sequence item 1: expected str instance, bool found
```

While such records *should* not exist when using the ORM, they might be the result of:
* certain upgrade scripts that use direct SQL (cf https://github.com/odoo/upgrade/blob/06b9e7f3cd98c383698695d6028bb7adefb6f805/migrations/base_vat/saas~16.3.1.0/pre-migrate.py#L104-L120)
* direct SQL inserts by users or/and customisations

# Proposed solution:
Since there are no ad-hoc mecanismes to fix such records on productions, the next best thing would be to simply adapt the search domain for `ancestors` and ignore any records where `message_id == False`. Indeed, if there is no `message_id` it makes no sense to try to add it in the references header.

# Reproduction steps:
1) Setup database and install contacts
2) Pick a contact and post a log note
3) For this new `mail.message` write `message_id == False` in the backend 4) Try to send a new message to the contact
-> Traceback

OPW-4728399


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

Forward-Port-Of: odoo/odoo#206279

Forward-Port-Of: odoo/odoo#206289

Forward-Port-Of: odoo/odoo#206289

Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company. Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe. Ensure a supported country is set before ru

Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company.

Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe.

Ensure a supported country is set before running the test.

https://runbot.odoo.com/odoo/error/163118

Forward-Port-Of: odoo/odoo#206141
Forward-Port-Of: odoo/odoo#206066

`payment` does not depend on `account`, it thus can't unconditionally use `account` groups. Skip tests if `account` is not installed (matches `account_custom` behaviour). `account_custom` does not depend on `product`, so can't use `product.product` unconditionally. `setUpClass` doesn't seem useful so just remove it entirely. Forward-Port-Of: odoo/odoo#206196

`payment` does not depend on `account`, it thus can't unconditionally use `account` groups. Skip tests if `account` is not installed (matches `account_custom` behaviour).

`account_custom` does not depend on `product`, so can't use `product.product` unconditionally. `setUpClass` doesn't seem useful so just remove it entirely.

Forward-Port-Of: odoo/odoo#206196

In the calendar application, when clicking on an event, a window opens. In this window, we can select “yes,” “no,” or “maybe.” When one of the buttons is selected and the mouse hovers over the button to its right, the border of the selected button disappears. This commit fixes this display issue to ensure that all four borders remain visible when hovering over the button adjacent to the selected one. Current behavior before PR: <img width="430" alt="Screenshot 2025-03-31 at 18 14 31" src="ht

In the calendar application, when clicking on an event, a window opens. In this window, we can select “yes,” “no,” or “maybe.” When one of the buttons is selected and the mouse hovers over the button to its right, the border of the selected button disappears. This commit fixes this display issue to ensure that all four borders remain visible when hovering over the button adjacent to the selected one.

Current behavior before PR:
<img width="430" alt="Screenshot 2025-03-31 at 18 14 31" src="https://github.com/user-attachments/assets/803358b7-139d-44d3-a5b2-d381bd2fc998" />

<img width="434" alt="Screenshot 2025-03-31 at 18 14 35" src="https://github.com/user-attachments/assets/4a2ce979-1da5-4c19-8e82-0bfe651e9c27" />


Desired behavior after PR is merged:
<img width="430" alt="Screenshot 2025-03-31 at 18 13 11" src="https://github.com/user-attachments/assets/c9faf40d-e913-481a-ac57-fc341091d56b" />
<img width="436" alt="Screenshot 2025-03-31 at 18 13 06" src="https://github.com/user-attachments/assets/12c0745f-a02a-4e59-99f3-4d6a2c791162" />

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

Forward-Port-Of: odoo/odoo#204197

Purpose of this commit: This commit aims to restrict the log notes to not be squashed when posted on a record from a chat window. task-4718225 Forward-Port-Of: odoo/odoo#206114 Forward-Port-Of: odoo/odoo#205998

Purpose of this commit:
This commit aims to restrict the log notes to not be squashed 
when posted on a record from a chat window.

task-4718225

Forward-Port-Of: odoo/odoo#206114
Forward-Port-Of: odoo/odoo#205998

Currently, an error occurs when a user tries to duplicate more than one payment term at once from the list view. **Steps to produce:** - Install the `account` module. - Navigate to `Invoicing > Payment Terms` (list view). - Select at least two records and duplicate them. - Observe the error. `ValueError - Expected singleton: account.payment.term(3, 4, 5, 6, 7, 8, 9, 10)` An error occurs because the **copy** method accesses `self.name`, assuming a single record, when multiple records

Currently, an error occurs when a user tries to duplicate more than one payment term at once from the list view.

**Steps to produce:**
- Install the `account` module.
- Navigate to `Invoicing > Payment Terms` (list view).
- Select at least two records and duplicate them.
- Observe the error.

`ValueError - Expected singleton: account.payment.term(3, 4, 5, 6, 7, 8, 9, 10)`

An error occurs because the **copy** method accesses `self.name`, assuming a single record, when multiple records are duplicated, causing the `ValueError`.

[1] - https://github.com/odoo/odoo/blob/6b970a0bfbcdac92d05389aac994c0db36730a34/addons/account/models/account_payment_term.py#L270

This commit ensures that each duplicated payment term has its name individually updated after being copied.

Sentry - 6531350963

Forward-Port-Of: odoo/odoo#205650

Steps to reproduce: - Install `project` - Create a new `project` and `tasks` within it. - Share the project with the portal user with edit access mode. Issue: - The color picker is not accessible through the portal. Fix: - Hide the color picker for portal users when editing color in shared tasks. task-4495861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206253 Forward-Port-Of: odoo/odoo#2020

Steps to reproduce:

- Install `project`
- Create a new `project` and `tasks` within it.
- Share the project with the portal user with edit access mode.

Issue:

- The color picker is not accessible through the portal.

Fix:

- Hide the color picker for portal users when editing color in shared tasks.

task-4495861






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

Forward-Port-Of: odoo/odoo#206253
Forward-Port-Of: odoo/odoo#202058

to reproduce: ============= - with employee having attendace houre based contract - set in attendace settigns that overtime should be approved by manager - create attendace for this employee with overtime pending for approval - create payslip for this employee -> the overtime is included in the payslip even if it is not approved Problem: ======== unapproved overtimes are not filtred while computing payslip lines Solution: ========= - add a filter to exclude unapproved overtimes

to reproduce:
=============
- with employee having attendace houre based contract
- set in attendace settigns that overtime should be approved by manager
- create attendace for this employee with overtime pending for approval
- create payslip for this employee

-> the overtime is included in the payslip even if it is not approved

Problem:
========
unapproved overtimes are not filtred while computing payslip lines

Solution:
=========
- add a filter to exclude unapproved overtimes in payslip line computation

opw-4610454

Forward-Port-Of: odoo/enterprise#83449

Revert odoo/enterprise#81587 because errors are triggered on dry-run. Also see discussion here: ref: https://github.com/odoo/enterprise/pull/82900#issuecomment-2800848343 Forward-Port-Of: odoo/enterprise#83422 Forward-Port-Of: odoo/enterprise#83391

Revert odoo/enterprise#81587 because errors are triggered on dry-run.

Also see discussion here:
ref: https://github.com/odoo/enterprise/pull/82900#issuecomment-2800848343

Forward-Port-Of: odoo/enterprise#83422
Forward-Port-Of: odoo/enterprise#83391

Before this commit: ======================== - The customer name was not updated when an order was received from the same phone number but with a different name. - If the ZIP code remained the same, changes in the address were not reflected in Odoo. After this commit: ======================== - The customer name is now updated if it differs, even when the phone number is the same. - Address updates are now applied in Odoo, even if the ZIP code has not changed. --- task - 4714559 Fo

Before this commit:
========================
- The customer name was not updated when an order was received from the same phone number but with a different name.
- If the ZIP code remained the same, changes in the address were not reflected in Odoo.

After this commit:
========================
- The customer name is now updated if it differs, even when the phone number is the same.
- Address updates are now applied in Odoo, even if the ZIP code has not changed.

---
task - 4714559

Forward-Port-Of: odoo/enterprise#83141

Steps to reproduce: 1. Create a new BoM w/ a pass/fail operation step 2. Create a manufacturing order using that BoM 3. Go the the Quality app 4. Open the quality check created for the MO 5. Click on Pass (or Fail, does not matter) 6. Go back to the MO and click Produce All 7. The qty_passed/qty_failed is not computed on the quality check opw-4552103 Forward-Port-Of: odoo/enterprise#80291

Steps to reproduce:
1. Create a new BoM w/ a pass/fail operation step
2. Create a manufacturing order using that BoM
3. Go the the Quality app
4. Open the quality check created for the MO
5. Click on Pass (or Fail, does not matter)
6. Go back to the MO and click Produce All
7. The qty_passed/qty_failed is not computed on the quality check

opw-4552103

Forward-Port-Of: odoo/enterprise#80291

**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html) - Create an invoice: * Customer: Comercial Constructora los Patitos S.A. * Operation Type: [0101] Internal sale * Invoice Lines: - Product: [any with a UNSPSC Category] - Taxes: 18% - Terms and Conditions: [text containing special cha

**Steps to reproduce:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html)
- Create an invoice:
  * Customer: Comercial Constructora los Patitos S.A.
  * Operation Type: [0101] Internal sale
  * Invoice Lines:
    - Product: [any with a UNSPSC Category]
    - Taxes: 18%
    - Terms and Conditions: [text containing special characters like '/' or '.']
- Confirm the invoice
- Process UBL 2.1

**Issue:**
In the XML, the content of <cbc:Note> has been stripped of all special characters like [/\!?+-=%.,;:()].
Only "whitespace" special characters should be excluded (i.e. '\n', '\u00A0',...).

opw-4659655

Forward-Port-Of: odoo/enterprise#82787

Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group. Steps to reproduce: - Install l10n_mx_reports. - Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. - Go to trial balance and try exporting with "SAT (XML)". An error will occur (`AttributeError: 'bool' object has

Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group.

Steps to reproduce:
- Install l10n_mx_reports.
- Create an account_group with a more specific account, such as 401.01.01
    - The 4, 401, and 401.01 groups are created with demo data.
- Go to trial balance and try exporting with "SAT (XML)".

An error will occur (`AttributeError: 'bool' object has no attribute 'startswith'`) because the account is None, so account have no type.

opw-4716047

Forward-Port-Of: odoo/enterprise#83392
Forward-Port-Of: odoo/enterprise#83197

Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * Create a new Transfer * Add as customer a Contact that is part of a Company * Print Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ The name of the company has to be shown not the actual name of ths customer Legal requirement in Chile ref: https://www.sii.cl/factura_electronica/formato_dte.pdf https://github.com/odoo/odoo/pull/172793 opw-4676871 Forward-Port-Of: odoo/enterprise#83311

Steps to reproduce:
-------------------
* Install l10n_cl_edi_stock
* Create a new Transfer
* Add as customer a Contact that is part of a Company
* Print Delivery Guide SII DTE 52 (CL)
> Observation:

Why the fix:
------------
The name of the company has to be shown not the actual name of ths customer Legal requirement in Chile
ref: https://www.sii.cl/factura_electronica/formato_dte.pdf https://github.com/odoo/odoo/pull/172793

opw-4676871

Forward-Port-Of: odoo/enterprise#83311