### steps to reproduce: - Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2 - Create and confirm an MO using that bom - Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product #### > Invalid Operation: You should provide a lot/serial number for the final product ### Expected behavior: You should be able

### steps to reproduce:

- Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2
- Create and confirm an MO using that bom
- Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product

#### > Invalid Operation: You should provide a lot/serial number for the final product

### Expected behavior:

You should be able to validate the operations of the MO without assigning an SN but you should not be able to mark the MO as done without assigning the SN to the final product.

Note: if no component were consumed in an operation, the invalid operation would not be raised.

### Cause of the Issue:

The invalid operation is raised because of these lines: https://github.com/odoo/enterprise/blob/1b0435a92492d85f28549a207fcdb7224b457c66/mrp_workorder/models/mrp_workorder.py#L433-L434 However, the existence of "self.move_raw_ids" only indicates that a component has to be consumed in this opration rather than the existence of a move requiring a the SN of the final product to be set.

## opw-3987022

Forward-Port-Of: odoo/enterprise#65075

Steps: - Install social_demo, crm - Open social marketing app - Open instagram ost - Create a lead from comment Actual result: - issue due to the demo data with invalid date format - demo date is not ISO8601 compliant Expected result - Lead wizard is opened opw-3975423 opw-4019390 Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142 Forward-Port-Of: odoo/enterprise#64204

Steps:
- Install social_demo, crm
- Open social marketing app
- Open instagram ost
- Create a lead from comment

Actual result:
- issue due to the demo data with invalid date format
- demo date is not ISO8601 compliant

Expected result
- Lead wizard is opened

opw-3975423
opw-4019390

Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142

Forward-Port-Of: odoo/enterprise#64204

## Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. ## After this PR The Sample Values will now update according to the selected WhatsApp Template. Task-3996935 Forward-Port-Of: odoo/enterprise#65198

## Before this PR
In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template.

## After this PR
The Sample Values will now update according to the selected WhatsApp Template.

Task-3996935

Forward-Port-Of: odoo/enterprise#65198

In this commit, we test the feature implemented in this PR: https://github.com/odoo/enterprise/pull/50383 task-3874263 Forward-Port-Of: odoo/enterprise#66019 Forward-Port-Of: odoo/enterprise#61329

In this commit, we test the feature implemented in this PR: https://github.com/odoo/enterprise/pull/50383

task-3874263

Forward-Port-Of: odoo/enterprise#66019
Forward-Port-Of: odoo/enterprise#61329

This commit moves the generic `_with_locked_records` from `l10n_mx_edi.document` in `l10n_mx_edi` -> `res.company` in `account` This allows multiple EDIs to use the same generic method for locking their record before using them in requests. This prevents 2 (or more) users to send the same invoice at the same time. Affected EDIs: l10n_mx_edi, l10n_ro_edi task-id: 3595436 related community PR: https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/enterprise#65602

This commit moves the generic `_with_locked_records` from `l10n_mx_edi.document` in `l10n_mx_edi` -> `res.company` in `account`

This allows multiple EDIs to use the same generic method for locking their record before using them in requests. This prevents 2 (or more) users to send the same invoice at the same time.

Affected EDIs: l10n_mx_edi, l10n_ro_edi

task-id: 3595436
related community PR: https://github.com/odoo/odoo/pull/144061

Forward-Port-Of: odoo/enterprise#65602

30% Exemption field shows on all contracts although it should only show on dutch employees contracts. This change restricts the 30% Exemption to only show on dutch contracts. task-3946599 Forward-Port-Of: odoo/enterprise#65790

30% Exemption field shows on all contracts although it should only show on dutch employees contracts.

This change restricts the 30% Exemption to only show on dutch contracts.

task-3946599

Forward-Port-Of: odoo/enterprise#65790

This PR makes the employees always appear in alphabetical order in the planning overlap warning. This fixes a test breaking when the order changes, and prevents potential problems caused by a nondeterministic order. Task-4037741 Forward-Port-Of: odoo/enterprise#66154

This PR makes the employees always appear in alphabetical order in the planning overlap warning. This fixes a test breaking when the order changes, and prevents potential problems caused by a nondeterministic order.

Task-4037741

Forward-Port-Of: odoo/enterprise#66154

Before this commit the timesheet_mail_employee_nextdate and timesheet_mail_manager_nextdate Were calculated only when a change was made on timesheet_mail_employee_delay, timesheet_mail_employee_interval or timesheet_mail_manager_delay, timesheet_mail_manager_interval fields, even tho those two have a default value Now the _timesheet_postprocess method will always call _calculate_timesheet_mail_employee_nextdate and _calculate_timesheet_mail_manager_nextdate method when called from the res.com

Before this commit the timesheet_mail_employee_nextdate and timesheet_mail_manager_nextdate Were calculated only when a change was made on timesheet_mail_employee_delay, timesheet_mail_employee_interval or timesheet_mail_manager_delay, timesheet_mail_manager_interval fields, even tho those two have a default value

Now the _timesheet_postprocess method will always call _calculate_timesheet_mail_employee_nextdate and _calculate_timesheet_mail_manager_nextdate method when called from the res.company.create method

Seems to work even if the delay and interval fields don't have default value

Following this PR > https://github.com/odoo/enterprise/pull/48096

15.0 > master

Task-3714293

Forward-Port-Of: odoo/enterprise#65564
Forward-Port-Of: odoo/enterprise#55546

This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Community PR: https://github.com/odoo/odoo/pull/171264 opw-4004765 Forward-Port-Of: odoo/enterprise#65952

This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates.

Community PR: https://github.com/odoo/odoo/pull/171264

opw-4004765

Forward-Port-Of: odoo/enterprise#65952

Steps to reproduce ================== - Install website_studio - Open any app - Open studio - Click on the website tab - Create a new listing type and confirm - Click on the three dots - View in website => TypeError: Cannot read properties of undefined (reading 'action') Cause of the issue ================== Before https://github.com/odoo/enterprise/pull/49809/commits/7980155915f25128e7cb8d5a0af91ffe45bb44c7 ```xml <t t-set="onItemClicked" t-value="page.page_type === 'lis

Steps to reproduce
==================

- Install website_studio
- Open any app
- Open studio
- Click on the website tab
- Create a new listing type and confirm
- Click on the three dots
- View in website

=> TypeError: Cannot read properties of undefined (reading 'action')

Cause of the issue
==================

Before https://github.com/odoo/enterprise/pull/49809/commits/7980155915f25128e7cb8d5a0af91ffe45bb44c7

```xml
<t t-set="onItemClicked" t-value="page.page_type === 'listing' ? this.openPageUrl.bind(this, page) : this.onConfigurePage.bind(this, page)" />
<t t-set="openPageUrl" t-value="page.page_type === 'listing' ? onItemClicked : null" />
<DropdownItem t-if="openPageUrl" onSelected="openPageUrl" href="'#'">View in website</DropdownItem>
```

in the new version, `t-if="openPageUrl"` was always true because `openPageUrl` refers to the function and not the template variable.

The function was also not bound to `this`.

Solution
========

- The "View in Website" button should only be displayed for pages of listing type.
- We add the this to the function call

opw-3987521

Forward-Port-Of: odoo/enterprise#64691

### Steps to reproduce: - Install quality_mrp and uninstall mrp_workrder - Create products A, B, and C - Product A: Storable, Manufacturing: - BOM: - 1 x product B - Product B: Storable, tracked by Lot, Manufacturing route with: - BOM: - 1 x Product C - Quality check: Op manufacturing and Control Per Quantity - Product C: Storable, On hand quantity of 10 - Create MO for product B and complete it with a Lot id - Create MO for product A > confirm #### > Trace

### Steps to reproduce:

- Install quality_mrp and uninstall mrp_workrder
- Create products A, B, and C 
  - Product A: Storable, Manufacturing: 
    - BOM: - 1 x product B 
  - Product B: Storable,  tracked by Lot, Manufacturing route with: 
    - BOM: - 1 x Product C
    - Quality check: Op manufacturing and Control Per Quantity 
  - Product C: Storable, On hand quantity of 10
- Create MO for product B and complete it with a Lot id
- Create MO for product A > confirm

#### > Traceback error

### Cause of the issue:

The `move_id` field of the `quality.check` model is used in the `_update_lot_from_lot_line` method of that same model. However, the method is defined in the `quality_mrp` module while the `move_id` field is defined in the `mrp_workorder` module.

Since `quality_mrp` depends on `mrp` and since `mrp_workorder` is auto installed when `mrp` is installed, this should not be an issue. However, since `mrp_workorder` is not a strict dependency of the `quality_mrp` module, the later in not uninstalled when `mrp_workorder` is. As such, it is possible to not have a `move_id` field on the `quality.check` model while the filed is used in the call of the `_update_lot_from_lot_line` mdethod defined in `quality_mrp`.

### For the posterity:

The method was introduced by commit 8ab6c56 in saas-16.4 for a fix and was later an later updated by commit 801ff42 for an other fix.

opw-3994004
---

Forward-Port-Of: odoo/enterprise#66063

Versions -------- - 16.0+ Steps ----- 1. Create an open slot in a planning; 2. publish & send an email to an employee who could fill it; 3. open the planning link sent via email; 4. open the same URL while logged out. Issue ----- The datetimes of the open slot are displayed in UTC. Cause ----- Commit cf256e94d333 modified the planning template to use the `datetime` widget to format the dates instead of the `format_datetime` function provided by the `ShiftController`. Doing so

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

Steps
-----
1. Create an open slot in a planning;
2. publish & send an email to an employee who could fill it;
3. open the planning link sent via email;
4. open the same URL while logged out.

Issue
-----
The datetimes of the open slot are displayed in UTC.

Cause
-----
Commit cf256e94d333 modified the planning template to use the `datetime` widget to format the dates instead of the `format_datetime` function provided by the `ShiftController`. Doing so, it lost access to the `employee_tz` value, derived from the email recipient, and hence defaulted to UTC.

Solution
--------
Format the dates using `format_datetime`.

opw-3967787

Forward-Port-Of: odoo/enterprise#66231
Forward-Port-Of: odoo/enterprise#66015

Steps to reproduce: Create a Subscription order in a different currency (THS) than the main currency (USD). Bug: We consider that the MRR is a "living amount". The customer will continue to pay the amount is TSh. This amount is converted into the currency of the company at the order date rate (from TSH to USD) which means, the TSh value is fixed at order date which is not correct as customer will continue to pay in TSh and the rate evolve. opw-3813197 Forward-Port-Of: odoo/enterprise#6

Steps to reproduce:
Create a Subscription order in a different currency (THS) than the main currency (USD).

Bug:
We consider that the MRR is a "living amount". The customer will continue to pay the amount is TSh.
This amount is converted into the currency of the company at the order date rate (from TSH to USD) which means, the TSh value is fixed at order date which is not correct as customer will continue to pay in TSh and the rate evolve.

opw-3813197

Forward-Port-Of: odoo/enterprise#61872

[FIX] l10n_dk_reports: fix account type of DK report tests By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore task-id#3983710 odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838) Forward-Port-Of: odoo/enterprise#66202

[FIX] l10n_dk_reports: fix account type of DK report tests

By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost
the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore

task-id#3983710

odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838)

Forward-Port-Of: odoo/enterprise#66202

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This PR provides a helper to convert the locales from the Python side for use on the JavaScript side.

Task-4014022

Community: https://github.com/odoo/odoo/pull/171837

Forward-Port-Of: odoo/enterprise#66092
Forward-Port-Of: odoo/enterprise#66061

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to

Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin.

To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin.

Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale.

This PR provides a helper to convert the locales from the Python side for use on the JavaScript side.

*: payment_adyen

Task-4014022

Forward-Port-Of: odoo/odoo#172001
Forward-Port-Of: odoo/odoo#171176

Steps: - Add "rate" field via Studio in the currency form - Try to create a currency Actual result: - Traceback due to rate computation ```python currency.rate = (currency_rates.get(currency.id) ) / currency_rates.get(to_currency.id) TypeError: unsupported operand type(s) for /: 'NoneType' and 'float' ``` Expected result: - Default rate value is 1.0 (cf 16.0) opw-4039324 Caused-By: https://github.com/odoo/odoo/commit/9353a6f9ba81926c7002b3ca5b53ac66fed9aebd --- I confirm

Steps:
- Add "rate" field via Studio in the currency form
- Try to create a currency

Actual result:
- Traceback due to rate computation
```python
currency.rate = (currency_rates.get(currency.id) ) / currency_rates.get(to_currency.id)
TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'
```

Expected result:
- Default rate value is 1.0 (cf 16.0)

opw-4039324

Caused-By: https://github.com/odoo/odoo/commit/9353a6f9ba81926c7002b3ca5b53ac66fed9aebd

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

Forward-Port-Of: odoo/odoo#172211

Versions -------- - 17.0+ Steps ----- 1. Go to working schedules; 2. try to modify duration days. Issue ----- Any change gets undone immediately. Cause ----- Commit https://github.com/odoo/odoo/commit/bbae19cc630cb629adabbc54e7fa96f23a4359d8 added `calendar_id.hours_per_day` to the dependent fields of the `_compute_duration_days` method. Because modifications happen on temporary records, any modification will now trigger a recompute, overwriting the manual values. Solution

Versions
--------
- 17.0+

Steps
-----
1. Go to working schedules;
2. try to modify duration days.

Issue
-----
Any change gets undone immediately.

Cause
-----
Commit https://github.com/odoo/odoo/commit/bbae19cc630cb629adabbc54e7fa96f23a4359d8 added `calendar_id.hours_per_day` to the dependent fields of the `_compute_duration_days` method. Because modifications happen on temporary records, any modification will now trigger a recompute, overwriting the manual values.

Solution
--------
Remove `calendar_id.hours_per_day` from `api.depends`. Having the fields editable is preferable over triggering recomputes ASAP.

opw-3999825

Forward-Port-Of: odoo/odoo#171109

[FIX] l10n_dk: fix some accounts' type Some accounts are set as "Expense" but it should be "Cost of revenue" Change them to 'expense_direct_cost' type task-id#3983710 enterprise-pr#[66202](https://github.com/odoo/enterprise/pull/66202) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168838

[FIX] l10n_dk: fix some accounts' type

Some accounts are set as "Expense" but it should be "Cost of revenue"

Change them to 'expense_direct_cost' type

task-id#3983710

enterprise-pr#[66202](https://github.com/odoo/enterprise/pull/66202)

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

Forward-Port-Of: odoo/odoo#168838

Purpose ======= Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed. Specification ============= The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not. Fixing the issue by checking if the path value is correctly set,

Purpose
=======
Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed.

Specification
=============
The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not.

Fixing the issue by checking if the path value is correctly set, if it is, displaying the default value view, else closing the popover.

related PR: odoo/odoo#117951

Task-4001976

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

Forward-Port-Of: odoo/odoo#171697

task-3744319 Forward-Port-Of: odoo/odoo#171570 Forward-Port-Of: odoo/odoo#171021

task-3744319

Forward-Port-Of: odoo/odoo#171570
Forward-Port-Of: odoo/odoo#171021

-fix and issue when adding a product to the cart (in debug mode only) an error pops up because freeze and refresh functions are missing from the props and the warning prop is not set as optional. opw-4016928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171912

-fix and issue when adding a product to the cart (in debug mode only)
 an error pops up because freeze and refresh functions are missing
 from the props and the warning prop is not set as optional.

opw-4016928


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

Forward-Port-Of: odoo/odoo#171912

Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 I

Steps to reproduce:
-Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save
-Go to Bills oF Materials -> create a new one w/ any product -> Save

Issue:
-There will be an error "One or more lines require a 100% analytic distribution."

Cause:
When saving the BoM, it leads to a constraint check
https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50

In this method, we first try to find the relevant plans:
https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L103-L107

To do so, we take all existing plans, evaluate them with a score, and take the one with the higher score. Here is the issue: when evaluating *Projects*, since we didn't provide any business domain and since the plan has a company, we assign a 0.5 score to the plan instead of skipping it:
https://github.com/odoo/odoo/blob/f17b37b14cad8f353443586cc9c4ecaf86e476da/addons/analytic/models/analytic_plan.py#L310-L319
Which does not make sense as the business domain of *Project* is *Purchase Order* and here the user is dealing with a BoM...

As a result, back to `_validate_distribution`, we check the distribution for this plan and realize there isn't any, hence the error:
https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L115-L117

Solution:

BOM: We don't restrict anymore the creation of a BOM. Setting an analytic distribution is only a tool to facilitate the definition of the analytic distribution on the MO but the creation should not be constrained
Workcenter: we correct the flowing by specifying the business domain restricting the creation of a workcenter if any relevant rule is present

Forward-Port-Of: odoo/odoo#168688

We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache. [opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187) Forward-Port-Of: odoo/odoo#172355

We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache.

[opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187)

Forward-Port-Of: odoo/odoo#172355

Version 17.0 steps to produce: - open 'hr_employees_view_kanban' in debug mode by searching in 'open view' - open hr attendance kanban view - click on kanban record - The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee' issue: faced with a traceback cause: 'action_employee_kiosk_confirm' action was removed from hr.employee.public solution: remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view. task-4022620 Forwar

Version 17.0
steps to produce:

- open 'hr_employees_view_kanban' in debug mode by searching in 'open view'
- open hr attendance kanban view
- click on kanban record
- The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee'

issue:
faced with a traceback

cause:
'action_employee_kiosk_confirm' action was removed from hr.employee.public

solution:
remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view.

task-4022620

Forward-Port-Of: odoo/odoo#171471

To reproduce the bug: - Go to Accounting app -> Customers -> Invoices - Click on an invoice or create a new one - Click on the Preview button - Chcek due in days. It has number after the decimal point. This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0. opw-3957112 Forward-Port-Of: odoo/odoo#169217

To reproduce the bug:
- Go to Accounting app -> Customers -> Invoices
- Click on an invoice or create a new one
- Click on the Preview button
- Chcek due in days. It has number after the decimal point.

This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0.

opw-3957112

Forward-Port-Of: odoo/odoo#169217

Prior to this commit, the QR code size on some receipts was too small to be scanned effectively. opw-4008280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171503

Prior to this commit, the QR code size on some receipts was too small to be scanned effectively.

opw-4008280

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

Forward-Port-Of: odoo/odoo#171503

This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Enterprise PR: https://github.com/odoo/enterprise/pull/65952 opw-4004765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171264

This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates.

Enterprise PR: https://github.com/odoo/enterprise/pull/65952

opw-4004765

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

Forward-Port-Of: odoo/odoo#171264

**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add any storable product - Delivery date: Tomorrow - Confirm the PO - Go to the Scheduled Actions: Purchase reminder - Run it Manually - Come back to the Dashbord > Emails - Select the email for Azure interior: - Try to click on “YES” **Problem:** A tra

**Steps to reproduce the bug:**
- Go to contact and select azure interior:
    - Sales & purchase tab:
        - Enable “Receipt Reminder” 1 day

- Create a purchase order:
    - Select azure interior as vendor
    - add any storable product
    - Delivery date: Tomorrow

- Confirm the PO

- Go to the Scheduled Actions: Purchase reminder
- Run it Manually
- Come back to the Dashbord > Emails
- Select the email for Azure interior:
    - Try to click on “YES”

**Problem:**
A traceback is triggered: `AttributeError: type object 'datetime.datetime' has no attribute 'from_string'`

When the “YES” button is clicked, we retrieve the “confirmed_date” from the arguments as a string and then call the `confirm_reminder_mail` function https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase/controllers/portal.py#L117

This date will be localized to the PO timezone using the `get_localized_date_planned` function: https://github.com/odoo/odoo/blob/a0be5ea52aeff3520f8f1a92206a5aad38fdaa82/addons/purchase/models/purchase.py#L823

We then get the timezone and use the `astimezone` function to transform this date, but since it is in string format, an error is triggered.

opw-4028362

Forward-Port-Of: odoo/odoo#172267

## Issue: Right now we will be showing as Attemtps (under the website profile in attempts tab) any attempt, even whe we didn't even started the certification yet. ## Steps to reproduce: 1. Install website_slide_survey. 2. Create or go to an existing course logged in. 3. Create or use an exsiting certigication and press the 'Begin certification' and don't start the certification after the redirect. 4. Go to your profile and check for the attemtps. ## Solution: It will make more

## Issue:

Right now we will be showing as Attemtps (under the website profile in attempts tab) any attempt, even whe we didn't even started the certification yet.

## Steps to reproduce:

1. Install website_slide_survey.
2. Create or go to an existing course logged in.
3. Create or use an exsiting certigication and press the 'Begin certification' and don't start the certification after the redirect.
4. Go to your profile and check for the attemtps.

## Solution:

It will make more sense that we only show the actual attempts, which means that we shouldn't show here the attempts that are not finished, since how user_inputs works and are always created at the time of the link creation, we could just filter out the user_inputs that are not actually valid to show here and show only the proper ones.

opw-3781323

Forward-Port-Of: odoo/odoo#161456

A traceback is occuring in the backend when the `method` is undefined while using the `POS`. Error:- ``` KeyError: 'method' File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1818, in _serve_db ro = ro(self.registry, request) File "addons/web/controllers/dataset.py", line 23, in _call_kw_readonly method_name = params['method'] ``` During an `ORM` call with dynamic method and model, at some point somehow, `metho

A traceback is occuring in the backend when the `method` is undefined while using the `POS`.

Error:- 
```
KeyError: 'method'
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1818, in _serve_db
    ro = ro(self.registry, request)
  File "addons/web/controllers/dataset.py", line 23, in _call_kw_readonly
    method_name = params['method']
```

During an `ORM` call with dynamic method and model, at some point somehow, 
`method` value getting undefined with the model as `pos.session`.

This leads to a traceback in the backend side.

After applying this commit it will resolve this issue by handling 
the traceback on the `JS` side when the method is undefined.

sentry-5285015466

Forward-Port-Of: odoo/odoo#170676

Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania con

Romania requires its companies to send all invoices to a specific web
service on their E-Factura platform. Now that we can generate the file
(CIUS-RO XML), our next obvious step is to send them to their SPV (the
ANAF platform).

This commit implements 2 big part:

- the full OAUTH/authentication process and its token generation
- sending/fetching/downloading data to and from the SPV

---

The Authentication

To be able to generate the token needs a special USB key from Romania
connected with an ANAF account. The full process on what needs to be
done is explained in the settings view, in the "Romanian E-Factura"
block.

Once a token is generated, we'll be able to use it in all of our request
to send/fetch/download data to/from ANAF.

---

The Full Sending E-Factura Flow (requires access token)

- Upload invoice/credit note to SPV -> get "loading ID"
- The invoice gets processed by ANAF (State: "sending")
- After some time, fetch the invoice using the acquired loading ID.
- If processed, there will be 2 kind of answer: "OK" or "NOK" (not ok)
- Either way, we will get a "download ID", which we can then use to
  download the answer.
  - If "NOK" -> "Error". Read the zip file and display the error message
  - If "OK" -> "Sent". Save the zip file attachment

task-id: 3595436
related enterprise PR: https://github.com/odoo/enterprise/pull/65602

Forward-Port-Of: odoo/odoo#144061

In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record. With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in. Closing #171703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---

In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record.

With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in.

Closing #171703

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#172289
Forward-Port-Of: odoo/odoo#172233

Before this commit, when a fiscal position was mapped to a tax that is included in the price, the computation did not work correctly. This commit ensures that prices are accurately recalculated when taxes included in the price are affected by fiscal position mappings. opw-3995279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171962

Before this commit, when a fiscal position was mapped to a tax that is included in the price, the computation did not work correctly. This commit ensures that prices are accurately recalculated when taxes included in the price are affected by fiscal position mappings.

opw-3995279

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

Forward-Port-Of: odoo/odoo#171962

### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is

### Steps to reproduce the issue:

1. Create a Tax Based On Payment with a Cash Basis Transition Account
2. Create an Expense Paid By Company and add previously created Tax
3. Create the report, submit it, approve it then Post Journal Entries
4. Go to the Journal Entry (until you see the Journal Items)
5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created

### Explanation:

When using the company to pay the expense, the payment is immediate. When the employee took care of the payment, a Bill and a Caba Entry are created because the company still needs to reimburse the employee.

### Suggested fix:

Adding a Caba Entry is not necessary since there is no need to record the transaction in a transitional account, sending the transaction in the final Account would also match the use case when using Taxes Based On Invoice.
`account_id` is selected between the `cash_basis_transition_account_id` of the tax and the `account_id` of the repartition line depending on the values of `tax_exigibility` and `caba_no_transition_account`.
https://github.com/odoo/odoo/blob/0c0f0b58aa49cff1efafcc1d4c5a9091e99f2ff4/addons/account/models/account_tax.py#L640-L642 The latter is a context key and is only used in this check, meaning it is most likely harmless to add it in the context of the method.

opw-3946362

Forward-Port-Of: odoo/odoo#172196
Forward-Port-Of: odoo/odoo#169255

Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 For

Steps to reproduce the bug:
- Create a storable product “P1”
- Create a delivery for P1
- Click on “Detailed operation” smart button
- select the move line
- click on “put in pack”

Problem:
Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result.

Note that this function cannot handle multiple move lines with different pickings.

opw-4029393

Forward-Port-Of: odoo/odoo#172235
Forward-Port-Of: odoo/odoo#172068

When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172317

When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model)

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

Forward-Port-Of: odoo/odoo#172317

Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270

Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction.

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

Forward-Port-Of: odoo/odoo#172316
Forward-Port-Of: odoo/odoo#172270