People tend to install every new shiny release of Python but fail to realise that it usually takes a month or two before Odoo is made compatible with that shiny new version. In the meantime there is a surge of issues / tickets with bugs related to the new python version, wasting time of a lot of people (at least mine). Hardcode the officially maximum supported python version and emit a warning when the current python is more recent than that. We'll change the variable the next time we support

People tend to install every new shiny release of Python but fail to realise that it usually takes a month or two before Odoo is made compatible with that shiny new version. In the meantime there is a surge of issues / tickets with bugs related to the new python version, wasting time of a lot of people (at least mine).

Hardcode the officially maximum supported python version and emit a warning when the current python is more recent than that. We'll change the variable the next time we support a new python version.

Forward-Port-Of: odoo/odoo#174054
Forward-Port-Of: odoo/odoo#168911

When splitting MO there's a bug which causes more items to be reserved than we have on hand. Steps to reproduce: - Create a product TEST - Create BoM of a product (e.g. COMP1) - Set quantity of COMP1 to X - Create MO of TEST with quantity set to X + 1 (or more) - Split the MO It will cause X + 1 COMP1's to be reserved even though we only have X COMP1's on hand. To fix this we need to create move lines before reserving. Task: 3962125 Forward-Port-Of: odoo/odoo#171241

When splitting MO there's a bug which causes more items
to be reserved than we have on hand.

Steps to reproduce:

- Create a product TEST
- Create BoM of a product (e.g. COMP1)
- Set quantity of COMP1 to X
- Create MO of TEST with quantity set to X + 1 (or more)
- Split the MO

It will cause X + 1 COMP1's to be reserved even though we only
have X COMP1's on hand.

To fix this we need to create move lines before reserving.

Task: 3962125

Forward-Port-Of: odoo/odoo#171241

## Steps to reproduce: - Install POS app - Change the warehouse to a 2-step delivery method - Create a sales order for a product and confirm - Ensure the product is reserved for the picking transfer **as** the issue doesn't exist (all transfers are successfully cancelled) if there are no products reserved - Go to POS and settle the sales order - The delivery transfer is cancelled but the picking transfer (with product reserved) is not cancelled. although all transfers should be cancelled i

## Steps to reproduce:
- Install POS app
- Change the warehouse to a 2-step delivery method
- Create a sales order for a product and confirm
- Ensure the product is reserved for the picking transfer **as** the issue doesn't exist (all transfers are successfully cancelled) if there are no products reserved
- Go to POS and settle the sales order
- The delivery transfer is cancelled but the picking transfer (with product reserved) is not cancelled. although all transfers should be cancelled if the order is fully delivered!

## Investigation:
- When the product is already reserved, the picking transfer is in the **Ready/assigned** state
- When updating the steps, the **Ready/assigned** state is not taken into consideration and so the picking transfer is not updated to be **cancelled**

opw-3474929

Forward-Port-Of: odoo/odoo#170828
Forward-Port-Of: odoo/odoo#164753

When the stock_move_line and stock_move have the same UoM everything works as expected. However, in the process of setting the done quantity from the move, to the move line, there are 2 places the wrong value is used in the compute, leading to misaligned data. This can, in a worst case, make a move with a quantity as done, and no supporting move lines. And no backorder created. Description of the issue/feature this PR addresses: This was raised in Odoo Ticket https://www.odoo.com/my

When the stock_move_line and stock_move have the same UoM everything works as expected.

However, in the process of setting the done quantity from the move, to the move line, there are 2 places the wrong value is used in the compute, leading to misaligned data.

This can, in a worst case, make a move with a quantity as done, and no supporting move lines.  And no backorder created.

Description of the issue/feature this PR addresses:

This was raised in Odoo Ticket https://www.odoo.com/my/tasks/4033989

Current behavior before PR:

Creates mismatched moves

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

*loyalty, pos_loyalty, sale_loyalty Currently, archived products that are used in loyalty programs may cause the POS shop to crash. Steps to reproduce: ------------------- * Go to the **Point of Sale** App * Go to the products * Look for the product `Simple Pen` * Archive the product * Add some product to the order * Add a customer that has loyalty points (`Azure Interior`) > Observations: Blank screen. Error in the console: Cannot read properties of undefined (reading 'id') at P

*loyalty, pos_loyalty, sale_loyalty

Currently, archived products that are used in loyalty programs may cause the POS shop to crash.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Go to the products
* Look for the product `Simple Pen`
* Archive the product
* Add some product to the order
* Add a customer that has loyalty points (`Azure Interior`)

> Observations: Blank screen. Error in the console: Cannot read properties of undefined (reading 'id') at Proxy._computeUnclaimedFreeProductQty

> Doing an equivalent flow in sales, when you select `Promotions`, an error message appears saying: Invalid Operation. Invalid product to claim.

Why the fix:
------------
When loading the `loyalty.rewards` to the pos session we check if there is at least one active product. If there is none, we don't load the reward.

Explanation of the domain:
* We only filter in the case where the `reward_type` is `product`.
* Second condition:
  * We cannot have a condition like `('reward_product_id', '!=', False)`
  We could have a setting with both `reward_product_id` and `reward_product_ids` being set. In this condition it would skip the check on `reward_product_ids`
  * We connot have a condition like `('reward_product_ids', '!=', False)` as `reward_product_ids` is always at least an empty set, thus it will always be '`True`'
  * We put the condition on `reward_product_tag_id`. When there is one set the computation of `reward_product_ids` is triggered. `reward_product_ids` will always include `reward_product_id`. When there is no tag set, we will always, at least, have a `reward_product_id`.

opw-[3968140](https://www.odoo.com/web#id=3968140&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#174553
Forward-Port-Of: odoo/odoo#168442

Because of https://github.com/odoo/odoo/pull/170616 we relaxed the constraint of needing a chained original refund invoice in the case it is imported. But that way, we allowed to post a credit note without the original invoice and that would give problems later in the flow as the XML rendering will give an error. 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

Because of https://github.com/odoo/odoo/pull/170616 we relaxed the constraint of needing a chained original refund invoice in the case it is imported.  But that way, we allowed to post a credit note without the original invoice and that would give problems later in the flow as the XML rendering will give an error.

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

When the user adds a Kenyan phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number. Steps to produce: - Add a Kenyan phone number (e.g., '+254114627044'). - Try to send WhatsApp messages using this phone number. - This will throw an Invalid number error. Problem: when `phonenumbers` python library is used in odoo for parsing phone numbers, versions below `8.13.31` have problem with parsing some Ken

When the user adds a Kenyan phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number.

Steps to produce:
- Add a Kenyan phone number (e.g., '+254114627044').
- Try to send WhatsApp messages using this phone number.
- This will throw an Invalid number error.

Problem:
when `phonenumbers` python library is used in odoo for parsing phone numbers, versions below `8.13.31` have problem with parsing some Kenyian numbers because they aren't updated, therefore they can't identify prefix and throw an error.

task-3994165

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#174666
Forward-Port-Of: odoo/odoo#174568

If a quotation template is set on an order, and that template has a "Confirmation mail", it'll be used to send quotes on confirmation, regardless of the flow (backend/frontend). For frontend flows (portal/ecommerce), a confirmation mail is sent after the order confirmation: * after SO signature on portal (if no payment is required) * on payment post processing (payment on portal or ecommerce) * on free order confirmation (ecommerce) Issue: If a template (with confirmation mail)

If a quotation template is set on an order, and that template
has a "Confirmation mail", it'll be used to send quotes on
confirmation, regardless of the flow (backend/frontend).

For frontend flows (portal/ecommerce), a confirmation mail
is sent after the order confirmation:

* after SO signature on portal (if no payment is required)
* on payment post processing (payment on portal or ecommerce)
* on free order confirmation (ecommerce)

Issue:

If a template (with confirmation mail) is used in on the quote
in one of those flows, two mails would be sent on confirmation:

* the template confirmation mail
* the default confirmation mail (could be the same mail)

Solution:

Harmonize and factorize a bit the behavior, to only send 1 mail maximum.

In backend, only send a confirmation mail if there is one configured on
the quotation template (as before).

In frontend, always send one unique mail, either the default one, or the
quotation template one if one is set.

opw-3997315

Forward-Port-Of: odoo/odoo#174600
Forward-Port-Of: odoo/odoo#171059

**Current behavior before PR:** Long texts overflowed beyond the banner's boundaries. **Desired behavior after PR is merged:** Ensure that text remains within the banner's limits to improve readability and visual consistency. task-4037185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174514 Forward-Port-Of: odoo/odoo#172071

**Current behavior before PR:**

Long texts overflowed beyond the banner's boundaries.

**Desired behavior after PR is merged:**

Ensure that text remains within the banner's limits to improve readability and visual consistency.

task-4037185

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

Forward-Port-Of: odoo/odoo#174514
Forward-Port-Of: odoo/odoo#172071

Before this commit, search results for chats and channels on mobile show up in uppercase. This happens because of the class `text-uppercase` on a parent element. This commit fixes the issue by removing said class on the parent element. Before:  After:  Forward-Port-Of: odoo/odoo#174268 Forward-Port-Of: odo

Before this commit, search results for chats and channels on mobile show up in uppercase.

This happens because of the class `text-uppercase` on a parent element.

This commit fixes the issue by removing said class on the parent element.

Before:
![image](https://github.com/user-attachments/assets/5ca6c781-4355-47ed-8feb-c846b92d5334)

After:
![image](https://github.com/user-attachments/assets/0ef299b8-e137-4d5a-89ad-6ff9f0268096)

Forward-Port-Of: odoo/odoo#174268
Forward-Port-Of: odoo/odoo#174224

Current behavior before PR: When switching the checkbox direction from left to right and pressing tab, the checkbox would shift to the left while the text appeared on the right, and vice versa for RTL languages. Desired behavior after PR is merged: Commit [1] added the positioning of checklists in Right-to-Left (RTL) languages. Previously, only the direct child `li` elements of `ul` were styled because of the use of the child combinator selector (>), as the `dir` attribute was o

Current behavior before PR:

When switching the checkbox direction from left to right and pressing tab, 
the checkbox would shift to the left while the text appeared on the right, 
and vice versa for RTL languages.

Desired behavior after PR is merged:

Commit [1] added the positioning of checklists in Right-to-Left (RTL) languages. 
Previously, only the direct child `li` elements of `ul` were styled because of 
the use of the child combinator selector (>), as the `dir` attribute was only
applied to the outermost `ul` element. This commit  ensures uniform styling 
across various languages, including RTL languages.

[1]: https://github.com/odoo/odoo/commit/bb9c4b3892353901a2cf33bccf0d6324466fd1fa

task-3828737

Forward-Port-Of: odoo/odoo#160909

To reproduce the bug follow the instructions: - Have pos and sales app installed - Go to pos app setting and enable is a Restorant setting - Back to the dashboard you should have a new shop called Restorant - Go to the products from and create a product ('pencil' for instance), make it available in pos and in self-order and assign to it a category - Add another product ('paper') with the same options in pos side and assign to it the same category, then add the first product ('pencil') to it

To reproduce the bug follow the instructions:
- Have pos and sales app installed
- Go to pos app setting and enable is a Restorant setting
- Back to the dashboard you should have a new shop called Restorant
- Go to the products from and create a product ('pencil' for instance), make it available in pos and in self-order and assign to it a category
- Add another product ('paper') with the same options in pos side and assign to it the same category, then add the first product ('pencil') to its optional product in sales section
- Back to pos dashboard open a sessing in Restorant shop then go back again to the dashboard
- Click on the tree dots on the top right of the Restorant shop block and click on the mobile view
- Create a new order adding 'paper' to the command then go to checkout

Now the optional product 'pencil' should be shown but it's unavailable.

A feature was added in Odoo 17.1 and newer for the availibility of the product on the point of sale app. It filter the product based on the availability hours of its categories. This brought changes to ProductCard component witch (you can check product_list_page) in pos_self_order modul for that. The thing is that these change wasn't made is pos_self_order_sale modul witch made the product always shown as unavailable.

opw-3977238

Forward-Port-Of: odoo/odoo#170362
Forward-Port-Of: odoo/odoo#170119

Some valid URLs were not working before because since [1], we were only supporting 15-16 digits facebook page ID. We also wanted to give feedback to a user if their link did not work for some reason. [1]: https://github.com/odoo/odoo/commit/82c4393fd025f9ab50197c0d68d52f57eb55ded2 task-3995431 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174602 Forward-Port-Of: odoo/odoo#169928

Some valid URLs were not working before because since [1], we were only
supporting 15-16 digits facebook page ID.

We also wanted to give feedback to a user if their link did not work for
some reason.

[1]: https://github.com/odoo/odoo/commit/82c4393fd025f9ab50197c0d68d52f57eb55ded2

task-3995431

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

Forward-Port-Of: odoo/odoo#174602
Forward-Port-Of: odoo/odoo#169928

…x tags wizard After updating taxes, we didn't update already existing journal entries tags to map correctly into new reports. We let the user change his data which can be very time consuming. To tackle that we introduce a new wizard accessible in accounting settings in which user can set a date from which we will update tags on his journal entries for him. task-3330327 Forward-Port-Of: odoo/odoo#174594 Forward-Port-Of: odoo/odoo#127077

…x tags wizard

After updating taxes, we didn't update already existing journal entries tags to map correctly into new reports.
We let the user change his data which can be very time consuming. To tackle that we introduce a new wizard accessible in accounting settings in which user can set a date from which we will update tags on his journal entries for him.

task-3330327

Forward-Port-Of: odoo/odoo#174594
Forward-Port-Of: odoo/odoo#127077

Steps to reproduce: -Create a product. -Add an attribute with a long name. -Add a significant number of variants (around 15-20). -Create a SO with this product. Issue: The attribute name is not easily readable. Cause: The use of the w-lg-25 class sets a fixed width. Fix: Use col-lg-3 to ensure the width adjusts according to the grid system. Forward-Port-Of: odoo/odoo#173619

Steps to reproduce:
-Create a product.
-Add an attribute with a long name.
-Add a significant number of variants (around 15-20).
-Create a SO with this product.

Issue:
The attribute name is not easily readable.

Cause:
The use of the w-lg-25 class sets a fixed width.

Fix:
Use col-lg-3 to ensure the width adjusts according to the grid system.

Forward-Port-Of: odoo/odoo#173619

### Steps to reproduce: - Start with an empty DB - Install account_accountant - Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save - Go to Apps: Install stock #### > traceback ### Cause of the issue: The "_setup_utility_bank_accounts" method is called during the installation of the stock module. In this call, data about non-existing fields of the "account.account" model are added to the `account_data` dictionary, namely : `prefix` and `code_digits`: htt

### Steps to reproduce:

- Start with an empty DB
- Install account_accountant
- Open settings - Search "Default Accounts" - Clear Outstanding receipts - Save
- Go to Apps: Install stock

#### > traceback

### Cause of the issue:

The "_setup_utility_bank_accounts" method is called during the installation of the stock module. In this call, data about non-existing fields of the "account.account" model are added to the `account_data` dictionary, namely : `prefix` and `code_digits`:
https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L702-L708 Since the "Outstanding receipts" account was removed from the settings of the company, it is not removed from the `account_data` here: https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L749-L751 and the datas of these records will be loaded:
https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/chart_template.py#L756-L761 If the records were to be created, it would not be problematic because these datas are popped and used by the override of the `create` method of the `account.account` model:
https://github.com/odoo/odoo/blob/e80ff1c285ce633a75ce0de5a7cb8d3dcecd301f/addons/account/models/account_account.py#L701 However, in our case, the record linked to that xml_id already exists and is added to the list of the records to update. A `write` call will then be launched to update the non-existing `account.account` fields leading to the traceback:
https://github.com/odoo/odoo/blob/96d98792bb34772e7acc228dd093c56f2f18b483/odoo/models.py#L5045-L5046

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

Forward-Port-Of: odoo/odoo#170580

before this commit, wrong invisible conditions were added using attrs, which is already removed after this commit, valid invisible conditions are added --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172034

before this commit, wrong invisible conditions were added using attrs, which is already removed

after this commit, valid invisible conditions are added

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

Forward-Port-Of: odoo/odoo#172034

Before this commit, no API version was given to StripeJS. This could lead to discrepancies between the APIs. Now, the API version used will be the same client-side and server-side. Forward-Port-Of: odoo/odoo#174713 Forward-Port-Of: odoo/odoo#169786

Before this commit, no API version was given to StripeJS. This could lead to discrepancies between the APIs.

Now, the API version used will be the same client-side and server-side.

Forward-Port-Of: odoo/odoo#174713
Forward-Port-Of: odoo/odoo#169786

[FIX] website_profile: reorder conditions accessing users profile Before we were checking for karma requirenment even if for unpublished websites now we don't. [Reproduce] - Install website_forum - Set karma to 100 for a website - Open a profile page on a forum, unselect "Public Profile" - BUG: Opening a profile page as another user render msg: "Not have enough karma to view other users's profile" Instead of a message about profile beeing private opw-3972165 Forward-Port

[FIX] website_profile: reorder conditions accessing users profile

Before we were checking for karma requirenment even if for unpublished websites
now we don't.

[Reproduce]
- Install website_forum
- Set karma to 100 for a website
- Open a profile page on a forum, unselect "Public Profile"
- BUG: Opening a profile page as another user render msg:
	   "Not have enough karma to view other users's profile"
	   Instead of a message about profile beeing private

opw-3972165

Forward-Port-Of: odoo/odoo#170784

Before this commit, when resetting the Google Calendar account in Odoo, some events and recurrences were disappearing from Odoo when they shouldn't have. This was happening because we weren't removing the 'google_id' information from deleted recurrences or even unlinking events incorrectly on the Odoo side. In addition, synchronizing only “new” or “all existing” events was not being handled correctly because the “need_sync” field should change according to the “sync_policy” selected. Followin

Before this commit, when resetting the Google Calendar account in Odoo, some events and recurrences were disappearing from Odoo when they shouldn't have. This was happening because we weren't removing the 'google_id' information from deleted recurrences or even unlinking events incorrectly on the Odoo side. In addition, synchronizing only “new” or “all existing” events was not being handled correctly because the “need_sync” field should change according to the “sync_policy” selected.

Following this commit, we correctly removed the 'google_id' from the recurrences when deleting them and now correctly consider the 'sync_policy' of synchronizing only 'new' or 'all existing' events by updating the 'need_sync' status of all existing synchronized events.

task-3731683

Forward-Port-Of: odoo/odoo#167299

Before this commit, the "discount amount" was not displayed as a monetary field in the sales report. Additionally, the discount amount calculation was limited to discounts applied within the entire session included in the report period. This meant that partial reports within a single session failed to include any discounts. opw-4061831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174341

Before this commit, the "discount amount" was not displayed as a monetary field in the sales report. Additionally, the discount amount calculation was limited to discounts applied within the entire session included in the report period. This meant that partial reports within a single session failed to include any discounts.

opw-4061831

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

Forward-Port-Of: odoo/odoo#174341

Problem --- The `sequence` field of product attributes has no default, This causes ordering bugs in the frontend when using handles. Steps --- * go to product attributes list view * move the last element to the top (to ensure a full reordering) * create a new product attribute *PA* > go back to the list view * => it appears at the bottom of the list * => its sequence appears to be 0 to the frontend but is actually NULL * move it one place up * => *PA* and the item after it

Problem
---
The `sequence` field of product attributes has no default, This causes ordering bugs in the frontend when using handles.

Steps
---
* go to product attributes list view
* move the last element to the top (to ensure a full reordering)
* create a new product attribute *PA* > go back to the list view 
  * => it appears at the bottom of the list 
  * => its sequence appears to be 0 to the frontend but is actually NULL
* move it one place up 
  * => *PA* and the item after it now have the sequence numbers 0, 1
* refresh 
  * => the two last items move to the top, crisscrossing with the previous 2 first items which also have sequence 0, 1

Cause
---
The frontend always assume click-and-drag sortable lists are already sorted, but this assumption is wrong when we have a record with a NULL `sequence`, because it will appears at the end of the ORDERBY SQL query but be converted to 0 frontend-side.

opw-3937263

Forward-Port-Of: odoo/odoo#174582
Forward-Port-Of: odoo/odoo#174397

[FIX] website_crm_partner_assign: fix sitemap grades Context: when visiting the `/partners` url, the user has access to the "silver", "gold" and "platinum" grades. However, when generating the sitemap, the `/partners/grade/bronze-4` url is part of it but trying to access it leads to a 404 server answer. Another problematic behavior is that if the user deactivates a grade ("gold" for example), the grade is still accessible from `/partners` (but the `/partners/grade/gold-2` url is not on

[FIX] website_crm_partner_assign: fix sitemap grades

Context: when visiting the `/partners` url, the user has access to the
"silver", "gold" and "platinum" grades. However, when generating the
sitemap, the `/partners/grade/bronze-4` url is part of it but trying to
access it leads to a 404 server answer. Another problematic behavior is
that if the user deactivates a grade ("gold" for example), the grade is
still accessible from `/partners` (but the `/partners/grade/gold-2` url
is not on the sitemap anymore).

This can be explained as:
- When visiting the `/partners` url, the `partners` route searches for
grades from `request.env['res.partner']`. By doing so, it ensures that
grades are linked to at least one partner; this explains why the
"bronze" grade (not linked to any partner) is not shown at the
`/partners` url and why the deactivated "gold" grade is still
accessible (as a partner is still related to it).
- When the user tries to reach a `/partners` route, a 404 server answer
is returned if no partners are found for the route (e.g.
`/partners/grade/bronze-4`).
- When generating the sitemap, the system is searching for grades from
`env['res.partner.grade']`. Due to it, inactive grades (e.g. "gold") are
not shown on the sitemap and grades that are not linked to a partner
(e.g. "bronze") are shown on the sitemap.

The goal of this commit is to:
- Correct the `/partners` route so that it does not show inactive
grades.
- Generate the sitemap coherently from what is done in the `/partners`
route.

In the end, the `/partner` route only shows company website published
partners linked to active website published grades. The user has then
the possibility to filter the partners by grades or by country.

opw-3992340

Forward-Port-Of: odoo/odoo#174353
Forward-Port-Of: odoo/odoo#170582

This commit aims to convert QUnit tests which rely on hr_skills/test_utils to hoot. Part of Task-3818666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166816

This commit aims to convert QUnit tests which rely on hr_skills/test_utils to hoot.

Part of Task-3818666

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

Forward-Port-Of: odoo/odoo#166816

63a80c14f62e2a96e0a5dc9b33d1cf8c9e7a4b9a added support for safe_eval in python 3.12. However this added RETURN_CONST in _SAFE_OPCODES instead of _CONST_OPCODES. This stopped const_eval from returning const values. closes #174045 Task-4067772 Forward-Port-Of: odoo/odoo#174707 Forward-Port-Of: odoo/odoo#174510

63a80c14f62e2a96e0a5dc9b33d1cf8c9e7a4b9a added support for safe_eval in python 3.12. However this added RETURN_CONST in _SAFE_OPCODES instead of _CONST_OPCODES. This stopped const_eval from returning const values.

closes #174045

Task-4067772

Forward-Port-Of: odoo/odoo#174707
Forward-Port-Of: odoo/odoo#174510

To replicate the issue: 1. Go to Accounting app 2. Click on the Accounting menu => Journal Entries 3. Click the button Upload 4. After selecting a file, an error is raise, saying that "The journal in which to upload the invoice is not specified." Cause: In the view for Journal Entries, there isn't a particular journal associated with it, so there is no definition the journal in which the document should be uploaded. Before 17.0, the document was uploaded to a default journal. Without a d

To replicate the issue:
1. Go to Accounting app
2. Click on the Accounting menu => Journal Entries
3. Click the button Upload
4. After selecting a file, an error is raise, saying that "The journal in which to upload the invoice is not specified."

Cause:
In the view for Journal Entries, there isn't a particular journal associated with it, so there is no definition the journal in which the document should be uploaded. Before 17.0, the document was uploaded to a default journal. Without a default journal, the error is raised. This renders the button useless in this view, as it will always raise an error after the user has selected a file to upload.

Fix:
The button should not be shown in the Journal Entries view (through Accounting => Journal Entries). But if the user is in a specific journal (for example, navigating from Accounting Dashboard => Miscellaneous Operations), the button should be shown.

To do so, the account move list and kanban controllers in bills_upload check if the default move type is 'entry', and if so, whether there is an active id in the context. This allows differentiating between the specific journals or the general Journal Entries view.

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

Forward-Port-Of: odoo/odoo#174669
Forward-Port-Of: odoo/odoo#174561

Before this commit, attempting to create a new contact without any identification type available in the database would result in an error. This commit ensures that a new contact can be created even when no identification types are present. Enterprise PR: https://github.com/odoo/enterprise/pull/67328 opw-4068907 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174493

Before this commit, attempting to create a new contact without any identification type available in the database would result in an error. This commit ensures that a new contact can be created even when no identification types are present.

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

opw-4068907

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

Forward-Port-Of: odoo/odoo#174493

Before this commit, databases with a large number of products would load all products in `all_discount_product_ids` of rewards and `valid_product_ids` of rules due to automatic loading of missing products. This commit exempts these fields from being automatically loaded. opw-4061504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174432

Before this commit, databases with a large number of products would load all products in `all_discount_product_ids` of rewards and `valid_product_ids` of rules due to automatic loading of missing products. This commit exempts these fields from being automatically loaded.

opw-4061504

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

Forward-Port-Of: odoo/odoo#174432

**Version**: 16 **Description of the issue/feature this PR addresses**: A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in Wallet" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual". **Video showing how to replicate the bug**: https://drive.google.com/file/d/1hHntOd5sYz-I3sbrBZmUxlh66FYt_eTR/view **Steps

**Version**: 16

**Description of the issue/feature this PR addresses**:
A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in Wallet" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual".

**Video showing how to replicate the bug**:
https://drive.google.com/file/d/1hHntOd5sYz-I3sbrBZmUxlh66FYt_eTR/view

**Steps to reproduce**:

1) Log in with admin on runbot odoo enterprise 16 instance and install l10n_latam_check (Third Party and Deferred/Electronic Checks Management) module.

2) Go to "Accounting / Configuration /Accounting / Journals and create a new journal  of type "Cash" and add incoming payment method "New Third Party Checks".
![image](https://github.com/user-attachments/assets/a54fa13e-2224-43e6-aedb-96e8d26c9fc5)

3) Create a new customer payment with journal "Bank" and payment method "Manual" and save.
![image](https://github.com/user-attachments/assets/8af7fab3-db04-444d-b0c4-8af0e7a7654c)

4) Change journal to the same journal created on step 2, change payment method to "New Third Party Checks" and confirm.
![image](https://github.com/user-attachments/assets/ceb3e329-2c1a-4b78-9c04-b527fac9a127)

**Current behavior before PR**:
A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is marked as "Not in Wallet" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual".

**Desired behavior after PR is merged**:
A customer payment with journal of type "Cash" and Incoming payment method "New Third Party Checks" is "On hand" if prior to confirming the payment it was saved with a different journal and other payment method, such as a journal of type "Bank" and the payment method "Manual".

Ticket Adhoc side: 76561
Task Latam side: 1229

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

Forward-Port-Of: odoo/odoo#172652

It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais). opw-4076445 [1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods Forward-Port-Of: odoo/enterprise#67476

It turns out we've been sending the wrong value in the state field [1]. This hasn't caused issues for the majority of states, but some states reject invoices if they don't have the right code (e.g. Minas Gerais).

opw-4076445

[1] The specification mentions state *code*: https://avataxbr-docs.avalarabrasil.com.br/#/Invoice%20Goods/sendInvoiceGoods

Forward-Port-Of: odoo/enterprise#67476

Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967 Forward-Port-Of: odoo/enterprise#58901 Forward-Port-Of: odoo/enterprise#52999

Manual Fowardport

latam task 1097

Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754
Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967

Forward-Port-Of: odoo/enterprise#58901
Forward-Port-Of: odoo/enterprise#52999

Steps to Reproduce: ----------- - Install sale planning. - Create a sale order with a plan product. - Navigate to the Planning app > Schedule > By Resource. - Click on a cell in the "Open Shifts" line. - Select a resource. - Save and close. - Check the shift resource. Issue: ---------- The shift is not being created in the open shift section based on the parameters selected by the user. Fix: ---------- When creating a shift from the open shift section, it

Steps to Reproduce:
-----------
  - Install sale planning.
  - Create a sale order with a plan product.
  - Navigate to the Planning app > Schedule > By Resource.
  - Click on a cell in the "Open Shifts" line.
  - Select a resource.
  - Save and close.
  - Check the shift resource.

Issue:
----------
   The shift is not being created in the open shift section based on the parameters
   selected by the user.

Fix:
----------
  When creating a shift from the open shift section, it should generate shifts according
  to the parameters selected by the user, such as resource, date, etc.

task-3919549

Forward-Port-Of: odoo/enterprise#67196
Forward-Port-Of: odoo/enterprise#64203

With this PR : ========================== - Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components. - This change uses the reserved components instead of creating new ones. Task-id : 4012314 Forward-Port-Of: odoo/enterprise#65559

With this PR :
==========================
- Previously, when producing the entire quantity of a product, new component lines were created, ignoring reserved components.
- This change uses the reserved components instead of creating new ones.

Task-id : 4012314

Forward-Port-Of: odoo/enterprise#65559

Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector. Task-3999790 Forward-Port-Of: odoo/enterprise#65000

Before this fix, one couldn't move documents to the parents workspaces. This was due to a check on the 'active' class of the target's child elements and not only on his direct descendant. This commit fix this by adding ':scope > ' to the selector.

Task-3999790

Forward-Port-Of: odoo/enterprise#65000

Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`. This is because we format tokens and filter out special characters and then compare them t

Currently, if a user uses a sale order sequence that contains special characters like `/` (e.g. SO/2024/12/31/01), they do not see such a sale order in suggestions in bank reconciliation if the label doesn't match the name of the sale order exactly. That is, a label `SO/2024/12/31/01 test` would not much this sale order, but a label `SO2024123101 test` would much a sale order with a name `SO2024123101`.

This is because we format tokens and filter out special characters and then compare them to names.

With this commit, we'll compare names and tokens that are formatted the same way.

opw-3964898

Forward-Port-Of: odoo/enterprise#67176

Speed up the shop floor by drastically reducing the number of refresh calls. We try to avoid a refresh of data from the server as much as possible. If an update is still unavoidable, we try to only refresh the relevant MO. task-4048415 Forward-Port-Of: odoo/enterprise#66898

Speed up the shop floor by drastically reducing the number of refresh calls.
We try to avoid a refresh of data from the server as much as possible.
If an update is still unavoidable, we try to only refresh the relevant MO.

task-4048415

Forward-Port-Of: odoo/enterprise#66898

In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`. SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequenc

In Peru, we don't prevent invoices with the same name from being created. Invoices with the same name, same document type and same company RUC will be reported to SUNAT with the same `edi_filename`.

SUNAT rejects those invoices as duplicates, which is good. However, our fallback mechanism of retrieving the existing CDR for those invoices and marking the invoice as sent is not good in this situation. Indeed, the user should be notified that the invoice was rejected, prompting them to resequence their invoice. Instead, they get the impression that their invoice was correctly sent to SUNAT.

To fix this, we don't try to retrieve an existing CDR if an invoice was rejected as duplicate, but there already exists an invoice with the same edi_filename that was sent to SUNAT.

opw-3900393

Forward-Port-Of: odoo/enterprise#67161
Forward-Port-Of: odoo/enterprise#65520

- Added missing pot/po files/translations for l10_cl_edi_pos - Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs - Added missing pot file + added missing terms/translations to website_sale module opw-4044338 Forward-Port-Of: odoo/enterprise#67429

- Added missing pot/po files/translations for l10_cl_edi_pos
- Converted website_sale file from es_CL => es_419 so the translations will show for other LATAM countries/langs
- Added missing pot file + added missing terms/translations to website_sale module

opw-4044338

Forward-Port-Of: odoo/enterprise#67429

Problem --------- Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing. 1. Install l10n_ae for example 2. Switch to AE company 3. Update the account with code 201002 to 701002 4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation Objective ----

Problem
---------
Currently, if you install l10n_xx and update some specific account codes (depending on the localization) and then try to install the corresponding l10n_xx_hr_payroll_account hr module, you are struck with an error that cancels the installation as some accounts are missing.

1. Install l10n_ae for example
2. Switch to AE company
3. Update the account with code 201002 to 701002
4. Install l10n_ae_hr_payroll_account -> Error occurs during the installation

Objective
---------
Be able to install the module even when the account is missing.

Solution
---------
Log a warning instead of raising an error.

opw-3961798

Forward-Port-Of: odoo/enterprise#67345
Forward-Port-Of: odoo/enterprise#67241

Before this commit, attempting to create a new contact without any identification type available in the database would result in an error. This commit ensures that a new contact can be created even when no identification types are present. Community PR: https://github.com/odoo/odoo/pull/174493 opw-4068907 Forward-Port-Of: odoo/enterprise#67328

Before this commit, attempting to create a new contact without any identification type available in the database would result in an error. This commit ensures that a new contact can be created even when no identification types are present.

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

opw-4068907

Forward-Port-Of: odoo/enterprise#67328

When the customer tries to create an asset for multiple journal items from different companies, a traceback will appear. Steps to reproduce the error: - Create an invoice with Company A - Create an invoice with Company B - Go to Accounting > Journal Items > select both invoice > Create Asset Traceback: ``` ValueError: Expected singleton: res.company(1, 5) File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1823, in _serve_db

When the customer tries to create an asset for multiple journal items from
different companies, a traceback will appear.

Steps to reproduce the error:
- Create an invoice with Company A
- Create an invoice with Company B
- Go to Accounting > Journal Items > select both invoice > Create Asset

Traceback:
```
ValueError: Expected singleton: res.company(1, 5)
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 42, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/account_asset/models/account_move.py", line 315, in turn_as_asset
    'default_company_id': self.company_id.id,
  File "odoo/fields.py", line 5183, in __get__
    raise ValueError("Expected singleton: %s" % record)
```

https://github.com/odoo/enterprise/blob/9373f9bac47839e3314a7823e05d4ef61af0b3e3/account_asset/models/account_move.py#L345 Here, When the user creates an asset for multiple journal items from
different companies, Self has multiple 'company_id'.
So it will lead to the above traceback.

sentry-5613448397

Forward-Port-Of: odoo/enterprise#67417
Forward-Port-Of: odoo/enterprise#66806