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

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