1. Create Vendor bill and register payment 2. Create credit note for the vendor bill 4. Open the CABA entry created from vendor bill 5. Reverse Entry 6. Check DIOT report Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft. opw-4142232 Forward-Port-Of: odoo/enterprise#70223

1. Create Vendor bill and register payment
2. Create credit note for the vendor bill
4. Open the CABA entry created from vendor bill
5. Reverse Entry
6. Check DIOT report

Issue: DIOT report shows negative line, but it not allowed CABA Entries should not be reverted, as the reversal generate a document with negative tax grid. They will revert automatically after the original document is reset to draft.

opw-4142232

Forward-Port-Of: odoo/enterprise#70223

Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration

Set up Avatax environment
Create an Invoice with 2 lines:
- Prod A, Analytic Account A
- Prod B, Analytic Account B

Compute taxes
Now open one of the newly added taxes
On the repartition line click on the 3 dots menu, show 'Tax Closing Entry'
Disable 'Tax Closing Entry' on the invoice repartition line
Now go back to the invoice
Compute taxes again

Issue: Traceback will raise
'ValueError: Expected singleton: account.move.line(...'

This occurs because, with this tax configuration, on the move we will have 2 tax
lines for the same tax, as the lines needs a different analytic account
and cannot be grouped together.

When we compare the amount per tax we'll have a recordset and it will raise an error.

A solution is to acknowledge that we might have more than 1 line and
split the possible difference evenly on the tax lines

opw-3976597

Forward-Port-Of: odoo/enterprise#69090

In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Forward-Port-Of: odoo/enterprise#71421

In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records

Forward-Port-Of: odoo/enterprise#71421

In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue. Forward-Port-Of: odoo/enterprise#71682

In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the
backend nonfunctional.

This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue.

Forward-Port-Of: odoo/enterprise#71682

Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks

Steps to reproduce:
- Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting
- Timesheets app > Start timer
- Set your helpdesk project and any task (Do not add a description)
- Stop timer > Do it again with same the project and a different task
- Stop timer > Time is added to previous timesheet

The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks' are instead recorded in the 'helpdesk_ticket_id'. Since it is forbidden for a timesheet to have both a 'task_id' and 'helpdesk_ticket_id', it is guaranteed that task_id will be False for both of our entries, leading to a merge. Similarily we can use that property since adding helpdesk_ticket_id to the domain won't change the usual behavior (the field will always be False if the project is not from Helpdesk) to add an extra condition here. Source: we have a contraint '_check_no_link_task_and_ticket' which ensures that.

opw-4203678

Forward-Port-Of: odoo/enterprise#71784

…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960

…sales

Steps to reproduce::
[l10n_fr]
- create a customer, BE Company; delivery adress USA
- create an invoice for the customer
- Go to EC Sales Report

Issue:
The transaction is displayed

Solution:
When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries

opw-4131299

Forward-Port-Of: odoo/enterprise#69960

This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime mod

This commit targets to fix two errors:

1. With an invoice that has a sale order related to it, when using
the Addenda Autozone a traceback appeared.

In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object
to the strptime function of datetime which in reality it needs to receive a string
object instead. This raises a TypeError

Since the objective is to set a string date, we convert the date_order into a string date
using strftime function from datetime module

- Install 'Sales' application and 'l10n_mx_edi' module
- In a company with mexican localization selected go to Sales > Quotations and create a new Order
- Select a contact with the Addenda Autozone selected
- Confirm it and create the corresponding invoice
- Confirm the invoice and generate the CFDI

2. Traceback with invoice that have multiple sale order linked.

In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the
value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order
when we create a invoice for multiple sale orders

Initialize sale_id with the first order retrieved to use it

task-no

Forward-Port-Of: odoo/enterprise#71875

Steps to reproduce ================== - Install web_studio,account_accountant - Enable Analytic accounts in Accounting - Navigate to Accounting > Analytic items - Open studio - Toggle show invisible - Edit the label of the last column => Xpath `/tree/field[17]` has no match Cause of the issue ================== - x_plan_* fields are dynamically added in get_views - Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them - When

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

- Install web_studio,account_accountant
- Enable Analytic accounts in Accounting
- Navigate to Accounting > Analytic items
- Open studio
- Toggle show invisible
- Edit the label of the last column

=> Xpath `/tree/field[17]` has no match

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

- x_plan_* fields are dynamically added in get_views
- Studio receives those fields and expect them to be part of the original arch. It assigns xpaths to them
- When making an edit, studio create an inheriting view that is applied before the x_plan fields are added. => Xpaths do not match

Solution
========

When in studio, don't add x_plan_* fields

opw-4210657

Forward-Port-Of: odoo/odoo#183509

**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant wa

**Steps:**
- Create a product with two variants (e.g., Steel & White and Aluminum & White).
- Enable 'Product Reference Price' in the settings.
- Set the base_unit_price of the 'Steel & White' variant to 0.
- Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants.

**Issue:**
- The base_unit_price for product variants was not being displayed when the base_unit_price of one variant was set to 0. This caused the price to disappear for all variants in the template, even when other variants had valid base_unit_price values.

**Cause:**
The condition in the template was relying on a falsy check, which incorrectly evaluated 0 as a falsy value and prevented the display of base_unit_price for all variants, including those with valid prices.

**Fix:**
The condition in the template was updated to check for the existence of base_unit_price explicitly using if condition effectively. This ensures that even when base_unit_price is 0, it will still be displayed, while preventing the field from disappearing for other variants.

Affected Version: 17.0~master
opw-4061530

Forward-Port-Of: odoo/odoo#183281

Forward-Port-Of: odoo/odoo#183000

Forward-Port-Of: odoo/odoo#183000

The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545

The check is comparing an empty recordset to False, which is not equal.

Credits to @JZorko
https://github.com/odoo/odoo/pull/171478

task-no

Forward-Port-Of: odoo/odoo#183545

Before this commit, only the distribution for Invoices had the modulo 390 tax grids. This commit will add the tax grid of the modelo 390 for credit node. They are the exact opposite has the one on the invoice. task: 4180225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180029

Before this commit, only the distribution for Invoices had the modulo 390 tax
grids.
This commit will add the tax grid of the modelo 390 for credit node. They are
the exact opposite has the one on the invoice.

task: 4180225




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

Forward-Port-Of: odoo/odoo#180029

Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we forgot some use cases opw-4072691 Forward-Port-Of: odoo/odoo#183347 Forward-Port-Of: odoo/odoo#182791

Little improvement of bcaf8cb859dc2f7e975d180ba0fc49da20204557
as we forgot some use cases

opw-4072691

Forward-Port-Of: odoo/odoo#183347
Forward-Port-Of: odoo/odoo#182791

Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy be

Before this PR:
- The state field on the res_company form is not automatically populated based on the entered GST number
- On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown

After this PR:
- The state field on the res_company form now automatically populates based on the entered GST number
- A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy between the GST number and the corresponding state.

Task ID - 4055948

Forward-Port-Of: odoo/odoo#178910

A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302

A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey
`message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index.

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

Forward-Port-Of: odoo/odoo#183302

opw-4224602 Forward-Port-Of: odoo/odoo#183559

opw-4224602

Forward-Port-Of: odoo/odoo#183559

This PR contains three small commits: [FIX] hw_posbox_homepage: make homepage responsive The new OWL IoT homepage is currently not responsive on mobile due to a missing HTML meta tag. This PR adds that tag as well as tweaking the width to not be cutoff on small screens. [FIX] hw_posbox_homepage: show error messages The IoT box returns error messages when connecting to a server fails. The new OWL homepage currently does not show these or any other sign of failure, instead just

This PR contains three small commits:

[FIX] hw_posbox_homepage: make homepage responsive

The new OWL IoT homepage is currently not responsive
on mobile due to a missing HTML meta tag. This PR
adds that tag as well as tweaking the width to not be
cutoff on small screens.


[FIX] hw_posbox_homepage: show error messages

The IoT box returns error messages when connecting
to a server fails. The new OWL homepage currently
does not show these or any other sign of failure,
instead just seeming unresponsive.

This PR now shows the error messages again, as well
as disabling the 'Connect' button while loading.


[FIX] hw_posbox_homepage: allow new IoT connection tokens

This change backports the URL helpers from 18.0, and modifies
the homepage controller to allow the new type of IoT token.
The result of this is that IoT boxes on v17 can connect to v18
databases via the token.


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

Forward-Port-Of: odoo/odoo#183169

Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img

Issue:
======
webp images doesn't appear in outlook

Steps to reproduce the issue:
=============================
- Create a new mass mailing
- Add cover block and replace the background image with a .webp one
- Add text-image block and replace the image with a .webp one
- Test it and open the email with outlook desktop
- The images doesn't appear in the email.

Solution:
=========
We replace the .webp images when converting inline.

For image elements: we just create another img element with the png
version.

For background-image: we create the png image and we replace the url of
background-image style with the dataURL of the canvas.

opw-3776054

Forward-Port-Of: odoo/odoo#177216

In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421

In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records

Description of the issue/feature this PR addresses:
When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies

Current behavior before PR:

Desired behavior after PR is merged:

see also https://github.com/odoo/enterprise/pull/71421




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

Forward-Port-Of: odoo/odoo#182706

This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531

This commit will add an underscore to a dict key to avoid any problem that might arise in the future.

no task id

Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9


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

Forward-Port-Of: odoo/odoo#183531

Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to th

Steps
-----
- Install Employees app.
- Have a user with "Settings" Administration rights and no "Employees" rights.
- Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree.
** Access error for `message_main_attachment_id` field **

Cause
-----
We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to the private employee if that's the case.

However, this does't guarantee that the user has the `hr.group_hr_user` group necessary to access some fields that were added with `groups="hr.group_hr_user"`
https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L122

opw-4096073

Forward-Port-Of: odoo/odoo#182726

Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the to

Issue:
======
We can't click twice on the transform button.

Steps to reproduce the issue:
=============================
- Create a todo
- Add an image
- Select it
- Click on the transform button in the toolbar
- The toolbar disappears so we can't click another time

Origin of the issue:
====================
The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the toolbar.

Solution:
=========
Revert the old fix and instead we ignore any `keydown` event when the transform container is in the dom (which means we are currently transforming an image).

task-4235140

[1]: https://github.com/odoo/odoo/commit/463c248e291a53c80365ae606c7cf39e13cd290b

Forward-Port-Of: odoo/odoo#182723

Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, t

Steps to reproduce the issue:
- Have 2 different authenticated browser (one as `admin` and one as `demo`)
- With the `demo browser`, change your own language to French -> Reload the main menu page
- With the `admin browser`, update the demo user language from the Settings to English
- Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English

Details:
- Only the first query after the following step will have an issue, the problem corrects itself on the second refresh.
- Could not reproduce on the runbot but could do it locally and on Odoo.SH (in 16.0) and on `odoo.com` free database (18.0).

This issue was already discussed more than a year ago (https://github.com/odoo/odoo/pull/110207) but was finally closed without being merged. The problem can now be fully reproduced while previously, it was a bit blurry.

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

### Steps to reproduce: - In Settings, enable "Multi-Step Routes" - In the Routes, unarchive MTO - Create 2 storable products P1, P2 with routes MTO + Buy - Set a different vendor on P1/P2 and ensure you have 0 units in stock - Create and confirm a sale order with 2 lines: - 1 x P1 - 1 x P2 > A delivery and 2 purchase order were created (one for each product) - Cancel the purchase orderfor P2 (it will not work with P1 hehe) - Go back to the SO and decrease the qty of P2 to 0 ###

### Steps to reproduce:

- In Settings, enable "Multi-Step Routes"
- In the Routes, unarchive MTO
- Create 2 storable products P1, P2 with routes MTO + Buy
- Set a different vendor on P1/P2 and ensure you have 0 units in stock
- Create and confirm a sale order with 2 lines:
  - 1 x P1
  - 1 x P2
> A delivery and 2 purchase order were created (one for each product)
- Cancel the purchase orderfor P2 (it will not work with P1 hehe)
- Go back to the SO and decrease the qty of P2 to 0
#### > A return is created from patner to stock instead of updating the P2 move of the delivery

### Cause of the issue:

When the sale order was confirmed the moves created for the delivery were both used the same procurment group and their `procure_method` was set to `make_to_order`. When the purchase order for P2 is cancelled, the delivery move associated with the related sol is cancelled and its `procure_method` is set to `make_to_stock` here:
https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/purchase_stock/models/purchase.py#L148 Then, when you decrease the qty of the SOL from 0 to 1, a procurement for -1 unit of P2 will be created and run by the
`_action_launch_stock_rule`. A negative move will then be created and confirm with a `procure_method`: `make_to_stock` here: https://github.com/odoo/odoo/blob/c424fded8660de628bfcf3937806cc72c8410434/addons/stock/models/stock_rule.py#L275-L277 Because the `procure_method` used at the creation of the negative move is determined from the `procure_method` of the first move related to the procurement group with a positive qty (here the P1 move): https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 As such, the negative P2 move will have a different `procure_method` than the positive P2 move and they will not be merged here: https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_move.py#L1384

### Fix:

The fix proposed in commit 65d5e7900f41aa7f65159f8f4cdb0c6638eaf8ca and introducing the lines:
https://github.com/odoo/odoo/blob/1fd336e5f321e5256accff6b5a4032b237dce528/addons/stock/models/stock_rule.py#L257-L260 works perfectly fine in most situtations but should considers only the moves related to the procurment group that concerns the same product to also work in the above case.

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

Forward-Port-Of: odoo/odoo#183120
Forward-Port-Of: odoo/odoo#182802