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

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

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#183585
Forward-Port-Of: odoo/odoo#178910

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

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

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

opw-4224602

Forward-Port-Of: odoo/odoo#183559

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

we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180312

we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f


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

Forward-Port-Of: odoo/odoo#180312

With this commit, the test test_ui is imported and runs smoothly. task-4143417 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#183241 Forward-Port-Of: odoo/odoo#181761

With this commit, the test test_ui is imported and runs smoothly.

task-4143417

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#183241
Forward-Port-Of: odoo/odoo#181761

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

Forward-Port-Of: odoo/odoo#183000

Forward-Port-Of: odoo/odoo#183000

when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#182859

when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case

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

**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

Issue 1: Previously, the chart was being overlapped by the navigation on smaller screen sizes. This commit fixes the issue by limiting the max-width for navigations and also hiding the button text for smaller screens. Issue 2: Previously, after a certain amount of data, the bar colors defaulted to black as the dataIndex exceeded the colors array. This commit fixes the issue by using the modulo operation on dataIndex with the colors array to repeat the colors, and also added additional color

Issue 1:
Previously, the chart was being overlapped by the navigation on smaller screen sizes. This commit fixes the issue by limiting the max-width for navigations and also hiding the button text for smaller screens.

Issue 2:
Previously, after a certain amount of data, the bar colors defaulted to black as the dataIndex exceeded the colors array. This commit fixes the issue by using the modulo operation on dataIndex with the colors array to repeat the colors, and also added additional colors referenced from reporting.

Task-4089537

Forward-Port-Of: odoo/odoo#183269
Forward-Port-Of: odoo/odoo#175704

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

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

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#71939
Forward-Port-Of: odoo/enterprise#71875

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

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

https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878

https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed 
how the chatter is added to a view and updated the codebase except for this module. 

This commit fixes this.

Forward-Port-Of: odoo/enterprise#71878