Steps to reproduce: - Activate developer mode - Install website Google Maps module - Navigate to Website in edit mode - Drop the google maps snippet - Enter a correct API key - The dialog closes but the snippet is removed This is due to a promise not resolved when confirming the API key. Forward-Port-Of: odoo/odoo#204139

Steps to reproduce:

- Activate developer mode
- Install website Google Maps module
- Navigate to Website in edit mode
- Drop the google maps snippet
- Enter a correct API key
- The dialog closes but the snippet is removed

This is due to a promise not resolved when confirming the API key.

Forward-Port-Of: odoo/odoo#204139

Versions -------- - 16.0+ Steps ----- 1. Have a payment token saved via Flutterwave; 2. use token to pay for an order. Issue ----- Error: Provide a valid redirect url Cause ----- Flutterwave now mandates authorization for tokenized flows. They provide an authorization url for this, and expect to receive a redirect url value to return to afterwards. Solution -------- Solution partially based on the Ogone redirect flow added in 0ed92bcc9791 The authorization url is provid

Versions
--------
- 16.0+

Steps
-----
1. Have a payment token saved via Flutterwave;
2. use token to pay for an order.

Issue
-----
Error: Provide a valid redirect url

Cause
-----
Flutterwave now mandates authorization for tokenized flows. They provide an authorization url for this, and expect to receive a redirect url value to return to afterwards.

Solution
--------
Solution partially based on the Ogone redirect flow added in 0ed92bcc9791

The authorization url is provided in the notification data. Store this in the `provider_reference` field if the transaction is pending.

When processing the pending transaction, initiate a redirect flow, which redirects the user to the authorization url.

opw-4669110

Forward-Port-Of: odoo/odoo#204599
Forward-Port-Of: odoo/odoo#204322

In a form snippet, enabling the "Description" option for a field and then undoing this action caused the field to lose its styling and available customization options. Steps to reproduce: - Enter Edit mode. - Add a Form snippet. - Select any field (e.g., "Your Name"). - Enable the "Description" option from the customization panel. - Undo the action (Ctrl+Z). This results in the field losing its padding and the "Description" and other options being removed. Cause: A redundant line

In a form snippet, enabling the "Description" option for a field and then undoing this action caused the field to lose its styling and available customization options.

Steps to reproduce:
- Enter Edit mode.
- Add a Form snippet.
- Select any field (e.g., "Your Name").
- Enable the "Description" option from the customization panel.
- Undo the action (Ctrl+Z).

This results in the field losing its padding and the "Description" and other options being removed.

Cause:
A redundant line of code was adding an extra step in the mutation history. When undoing, this extra step caused the removal of essential classes from the field, leading to the loss of styling and options.

Fix:
Removed the redundant line to ensure undoing the action correctly restores the previous state without affecting the field’s styling or customization options.

task-4013551

Forward-Port-Of: odoo/odoo#179858

Steps to reproduce the bug: - Create a storable product, that is tracked by serial number - Add to in Hand the product and set the serial number to it - Create a quotation of this product and confirm to be a sale order - Open a pos session, and select quotations and orders from pos - Select the sales order created and settle the order - The order line will be imported without asking if serial number can be linked Issue: The function settleOrder in pos_sale/pos_store.js reads the sales

Steps to reproduce the bug:
- Create a storable product, that is tracked by serial number
- Add to in Hand the product and set the serial number to it
- Create a quotation of this product and confirm to be a sale order
- Open a pos session, and select quotations and orders from pos
- Select the sales order created and settle the order
- The order line will be imported without asking if serial number can be linked

Issue:
The function settleOrder in pos_sale/pos_store.js reads the sales order using this.data.read, this will read the sales order with the sale order line but without the information of the lot numbers and more info. These informations are returned in a read_converted function on sale.order.line inherited model on pos_sale, and this function is not used to read the sale order lines, hence no information related to the lots and the pop up that asks if the lot number may be linked will not appear anymore.

opw-4591887

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

Purpose ======= The Indian government updated its UOM code https://einvoice1.gst.gov.in/Others/MasterCodes (select UQC Codes) So In this commit, I have updated `l10n_in_code` in UOM Mili Meter and Square Foot. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204598

Purpose
=======
The Indian government updated its UOM code
https://einvoice1.gst.gov.in/Others/MasterCodes (select UQC Codes)

So In this commit, I have updated `l10n_in_code` in UOM  Mili Meter and Square Foot.

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

Forward-Port-Of: odoo/odoo#204598

Steps to reproduce the issue: - Enter Website edit mode. - Click on the "Theme" tab. - Pick a black color for the website background (4th color button). - Click on a link in the website navbar to make the link popover appear. - Bug: The popover background is black, and its buttons are not visible as they are also black. Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce ca

Steps to reproduce the issue:

- Enter Website edit mode.
- Click on the "Theme" tab.
- Pick a black color for the website background (4th color button).
- Click on a link in the website navbar to make the link popover appear.
- Bug: The popover background is black, and its buttons are not visible as they are also black.

Bug introduced by this commit [1], where popover colors were updated to match the website's theme. The goal was to align popovers, such as the one for the e-commerce cart button, with the theme colors. However, the change unfortunately also affected the link editing popover, which should remain neutral as it is part of the interface elements.

[1]: https://github.com/odoo/odoo/commit/0d96be06faf8aad1a92183bd2b6371253980c7e6

task-4422810

| Before  | After |
| ------------- | ------------- |
| ![image](https://github.com/user-attachments/assets/a217c886-9521-4347-a0db-7d6cd7b6029b)  | ![image](https://github.com/user-attachments/assets/f06e4618-e896-430c-8063-bbe3dd534055)  |

Forward-Port-Of: odoo/odoo#203958

Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added. opw-4573640 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.co

Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added.

opw-4573640

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#203564
Forward-Port-Of: odoo/odoo#203395

One issue remained for the 'Multiple choice: multiple answers allowed' option in this task: https://www.odoo.com/odoo/project.task/4663115 Task- 4663115 Forward-Port-Of: odoo/odoo#204603

One issue remained for the 'Multiple choice: multiple answers allowed' option in this task:
https://www.odoo.com/odoo/project.task/4663115

Task- 4663115

Forward-Port-Of: odoo/odoo#204603

Currently, a traceback occurs when the user tries to send multiple invoices to sign in the list view, which includes draft invoices. Error:- ``` TypeError: the JSON object must be str, bytes or bytearray, not bool ``` Cause:- When the user resets an Egyptian invoice to draft status, the value of `l10n_eg_eta_json_doc_id` is set to False as seen in the following line https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/accoun

Currently, a traceback occurs when the user tries to send multiple invoices 
to sign in the list view, which includes draft invoices.

Error:- 
```
TypeError: the JSON object must be str, bytes or bytearray, not bool
```

Cause:-

When the user resets an Egyptian invoice to draft status, the value 
of `l10n_eg_eta_json_doc_id` is set to False as seen in the following line

https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L66-L67

After that when the user attempts to sign the document through the list view, it leads to the  traceback.

This happens because we are passing self instead of the invoices to the method `action_sign_invoices`.
https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L73
https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/account_move.py#L106
As a result, self contains all draft invoices (if selected by the user), leading to the traceback since the value of l10n_eg_eta_json_doc_id is False for the reset draft invoice.

https://github.com/odoo/odoo/blob/26d8a505ab540dfff3ee20e9c83f43b61dc743a8/addons/l10n_eg_edi_eta/models/eta_thumb_drive.py#L34-L35

sentry-6448238266

Forward-Port-Of: odoo/odoo#203064

The domain was syntactically wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204532

The domain was syntactically wrong.

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

Forward-Port-Of: odoo/odoo#204532

Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the app

Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable.

Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users.

opw-3841495

Forward-Port-Of: odoo/odoo#178142

Currently, if a serialization error occurs right after sending an invoice to SDI, Odoo retries the submission. This causes issues as the move’s transaction ID will be updated to the second attempt, not the first. Additionally, SDI will detect a duplicate submission and return a "notificaScarto" status. Since only the second transaction ID is stored, Odoo will incorrectly display the invoice as rejected, even though the first submission was actually accepted. This fix ensures the move

Currently, if a serialization error occurs right after sending an invoice to SDI, Odoo retries the submission.

This causes issues as the move’s transaction ID will be updated to the second attempt, not the first.
Additionally, SDI will detect a duplicate submission and return a "notificaScarto" status.

Since only the second transaction ID is stored,
Odoo will incorrectly display the invoice as rejected, even though the first submission was actually accepted.

This fix ensures the move is locked before sending to SDI, preventing this issue.

opw-4643686

Forward-Port-Of: odoo/odoo#202693

**Current behavior:** `expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios. **Expected behavior:** Accurate price per unit of component. **Steps to reproduce:** 1. Create a finished product with a BoM: * has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final) * make component cost $100 for sake of example * has a workorder with a workce

**Current behavior:**
`expected_component_cost_unit` does not accurately reflect the per unit price of a component depending on the manufacturing order's quantity ratios.

**Expected behavior:**
Accurate price per unit of component.

**Steps to reproduce:**
1. Create a finished product with a BoM:
* has a 1:1 comp to final ratio with quantities greater than 1 (e.g., 2 units component producing 2 units final)
* make component cost $100 for sake of example
* has a workorder with a workcenter with capacity sufficient to handle full BoM quantity producing (so 2 if used 2 -> 2 on BoM)

2. Create & process MO for finished product

3. Open the Production Analysis pivot view in the mrp app

4. In the `Measures` dropdown, check the `Expected Component Cost / Unit` field -> see that it shows `$50 / unit` instead of the expected `$100 / unit`

**Cause of the issue:**
This per unit value is divided by the BoM `product_qty` 2x:
1: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_account_enterprise/reports/mrp_report.py#L184
2: https://github.com/odoo/enterprise/blob/ab86dadfcbe9662d611127546d9fb054759d325f/mrp_workorder_hr_account/report/mrp_report.py#L32

**Fix:**
Remove the additional division operation in
`mrp_workorder_hr_account`

opw-4474710

Forward-Port-Of: odoo/enterprise#80560

Versions -------- - saas-17.4+ Price already hidden in 17.0 & earlier. Steps ----- 1. Set website to prevent sale of zero-priced products; 2. create a zero-priced pricelist; 3. create a rental product; 4. set a rental price of $0 on the zero-priced pricelist; 5. go to rental product page on website. Issue ----- It displays "$0.00/day" above the "Not Available for Sale" text. Cause ----- The rental price element doesn't check whether zero-priced products should be made ava

Versions
--------
- saas-17.4+

Price already hidden in 17.0 & earlier.

Steps
-----
1. Set website to prevent sale of zero-priced products;
2. create a zero-priced pricelist;
3. create a rental product;
4. set a rental price of $0 on the zero-priced pricelist;
5. go to rental product page on website.

Issue
-----
It displays "$0.00/day" above the "Not Available for Sale" text.

Cause
-----
The rental price element doesn't check whether zero-priced products should be made available for sale.

Solution
--------
If the rental price is zero, and the website prevents sale of zero-priced products, hide the rental price element.

We can use `combination_info['prevent_zero_price_sale']` for this thanks to commit 1f827ac1fad


opw-4643155

Forward-Port-Of: odoo/enterprise#82535

[FIX] hr_appraisal: prevent TypeError for raw record data The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None. This occurred because the code attempted to create a set from the None value directly. Steps to reproduce: ------------------- * Open Appraisal app and click on an employee's card * Activate debug mode * From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+ > Observation: Fil

[FIX] hr_appraisal: prevent TypeError for raw record data

The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None.
This occurred because the code attempted to create a set from the None value directly.

Steps to reproduce:
-------------------
* Open Appraisal app and click on an employee's card
* Activate debug mode
* From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+

> Observation: 
  File "/data/build/enterprise/hr_appraisal/models/hr_appraisal.py", line 539, in read
    check_notes = set(fields) & {'note', 'assessment_note'}
                  ^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

Why the fix:
------------
set() requires an iterable. By adding this condition, we avoid iterating over NoneType. This maintains the intended default functionality while preventing the crash.

opw-4631142

Forward-Port-Of: odoo/enterprise#82711
Forward-Port-Of: odoo/enterprise#81758

Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time. Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite. runbot error 162039 Fix courtesy of @Xavier-Do Forward-Port-Of: odoo/enterprise#82810

Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time.

Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite.

runbot error 162039

Fix courtesy of @Xavier-Do

Forward-Port-Of: odoo/enterprise#82810

Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this

Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable.

Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users.

This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/178142

opw-3841495

Forward-Port-Of: odoo/enterprise#69036

Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user. **Steps to reproduce:** - Install the `account` and `l10n_hr_payroll` modules. - Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record. - In **Scheduled Actions**, manually execute `Payroll: Update data`. - Observer the backend error. **Error:** `ValueError - ParseError('while parsing /home/odoo/src/

Currently, an error is produced when updating payroll data if a referenced partner record in salary rules has been deleted by the user.

**Steps to reproduce:**
- Install the `account` and `l10n_hr_payroll` modules.
- Navigate to the **Vendors** view and delete the `Register for State Labour Welfare Fund Deduction` record.
- In **Scheduled Actions**, manually execute `Payroll: Update data`.
- Observer the backend error.

**Error:**
`ValueError - ParseError('while parsing /home/odoo/src/enterprise/saas-18.2/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data...`

The error occurs because the method at [1] attempts to load the `hr_salary_rule_ind_emp_data.xml` file that references a deleted `partner_id` [2], leading to a parsing error.

[1] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/models/hr_payslip.py#L44-L54
[2] - https://github.com/odoo/enterprise/blob/46f838403c8d60760a5b37cb5fe8d052d2307999/l10n_in_hr_payroll/data/salary_rules/hr_salary_rule_ind_emp_data.xml#L364

This commit ensures that `res_partner_data.xml` is loaded before `hr_salary_rule_ind_emp_data.xml`, preventing errors due to missing partners.

Sentry - 6429993371

Forward-Port-Of: odoo/enterprise#81917