This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA

This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands.


task-3572344


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

Forward-Port-Of: odoo/odoo#180313

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

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

Forward-Port-Of: odoo/odoo#206289

Forward-Port-Of: odoo/odoo#206289

# 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

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

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

Steps to reproduce: 1. Install Indian E-waybill(`l10n_in_edi_ewaybill`) 2. Activate Unit of Measures 3. Create a Invoice with a move line product as default UOM as units. 4. Change the UOM on line to Dozens 5. Confirm and send the E-waybill On portal the E-waybill for that line is Unit instead of Dozens In this commit we fix the 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#206232 Forward

Steps to reproduce:
1. Install Indian E-waybill(`l10n_in_edi_ewaybill`)
2. Activate Unit of Measures
3. Create a Invoice with a move line product as default UOM as units.
4. Change the UOM on line to Dozens
5. Confirm and send the E-waybill

On portal the E-waybill for that line is Unit instead of Dozens

In this commit we fix the 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#206232
Forward-Port-Of: odoo/odoo#206191

In a form view with a many2one field using the res_partner_many2one widget (e.g. in the "Contacts" form view) where this field is set, remove the value. Before this commit, this didn't trigger a change in the model. As a matter of fact, the "save" button in the control panel (the small cloud) wasn't displayed. As a consequence, such a change couldn't be saved. This commit backports the fix made for version 18.0 for versions 17.0 and saas-17.4. The original fix is made in https://github.com/o

In a form view with a many2one field using the res_partner_many2one widget (e.g. in the "Contacts" form view) where this field is set, remove the value. Before this commit, this didn't trigger a change in the model. As a matter of fact, the "save" button in the control panel (the small cloud) wasn't displayed. As a consequence, such a change couldn't be saved.

This commit backports the fix made for version 18.0 for versions 17.0 and saas-17.4. The original fix is made in
https://github.com/odoo/odoo/pull/203277.

opw-4725006



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

Forward-Port-Of: odoo/odoo#206218

**Steps to reproduce:** - Create product as service based on milestone - Set user rights as: - Sales/Sales : User: Own documents Only - Services/Project: None - Make sale order and save it **Issue:** Milestone button `invisible` field in the sale order view was throwing an error due to `project_ids` not being defined for users with `project.group_project_milestone` enabled but not `project.group_project_user`. **Fix:** Added `project.group_project_milestone` group to `proje

**Steps to reproduce:**
- Create product as service based on milestone
- Set user rights as:
    - Sales/Sales : User: Own documents Only
    - Services/Project: None
- Make sale order and save it

**Issue:**
Milestone button `invisible` field in the sale order view was throwing an error due to `project_ids` not being defined
for users with `project.group_project_milestone` enabled but not `project.group_project_user`.

**Fix:**
Added `project.group_project_milestone` group to `project_ids` field.

opw-4563845

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

Forward-Port-Of: odoo/odoo#204998

**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product in

**Current behavior:**
When receiving product after having billed it already, if: A) the product is valuated,
B) the purchase is in a foreign currency,
C) there is an underlying exchange diff between time of bill and receiption

then the exchange difference account move will occur in the regular exchange account.

**Expected behavior:**
It should be for the stock valuation account.

**Steps to reproduce:**
*with anglo saxon accounting enabled*
1. Create a real-time valuated product invoiced on ordered qty
2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique)
3. Make a purchase for the product, invoice -> post
4. The next day, receive the product
5. Check the exchange journal to see the offending AMLs

**Cause of the issue:**
In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`*
https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's.

It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts.

**Fix:**
Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.)

opw-4655669

Forward-Port-Of: odoo/odoo#204505

steps to reproduce: 1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`) 2. create a time off type that can only be taken in days 3. create an accrual allocation with the plan and that time off type The calculation in the dashboard shows the amount of hours as days. The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case. task: 4076800 --- I confirm I have signed the CLA and read the PR

steps to reproduce:
1. create an accrual plan that is accrued in hours (`added_value_type = 'hours'`)
2. create a time off type that can only be taken in days
3. create an accrual allocation with the plan and that time off type

The calculation in the dashboard shows the amount of hours as days.

The issue is that the amount of time off allocated is shown for the time off type request which is not true in this case.

task: 4076800

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

Forward-Port-Of: odoo/odoo#176765

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

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

### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the i

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

Since c18a7d2dc36d33134c5bdb1569865bd554e04130, the rentable forecast for future dates ignores the `rented_qty_during_period` if the setting "Rental transfers" is enabled. This happens because that rented quantity during period is supposed to be absorbed by the stock forecast: https://github.com/odoo/enterprise/blob/8ea5f4f9a0a907c57844c6274688171193f6a904/sale_stock_renting/models/sale_order_line.py#L132-L134 
However, the stock forecast of the 'virtual_available' relies solely on deliveries and receipt happening prior to the start of the renting period. Therefore the rental orders that are planned to start during the renting period should still contribute to the
`rented_qty_during_period` in that use case.

opw-4552760

Forward-Port-Of: odoo/enterprise#82172

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

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

The SP-API doesn't support SKU containing commas, not even when escaping and listing them in a correct CSV like string, as they'll be considered as either separate SKU or a different one, thus leading to an error saying there are too many identifiers, or not recognizing them anyway. In order to let the synchronization continue for the other items, ensure their SKU are valid beforehand. As from Amazon side, using a comma is a valid value, we can't constrain the SKU either. opw-4710435

The SP-API doesn't support SKU containing commas, not even when escaping
and listing them in a correct CSV like string, as they'll be considered
as either separate SKU or a different one, thus leading to an error
saying there are too many identifiers, or not recognizing them anyway.
In order to let the synchronization continue for the other items, ensure
their SKU are valid beforehand.

As from Amazon side, using a comma is a valid value, we can't constrain
the SKU either.

opw-4710435

Forward-Port-Of: odoo/enterprise#83367

### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of material for a final product FP with one raw: - 3 x COMP (storable product with 10 units in stock) - Create and confirm an MO for 1 unit of FP. > This create a picking from stock to preprod for 3 unit of COMP - In the shopfloor on your MO click on the 3 dots and add components - Register

### Step to reproduce:

- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
    - 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units

### Cause of the issue:

When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case  there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.

opw-4562965

Forward-Port-Of: odoo/enterprise#81818