The Netherlands localization now includes account groups in its chart of accounts. This helps businesses organize financial accounts more clearly for reporting and day-to-day accounting setup.

This PR adds account groups to the COA for the Netherlands.


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

The time off calendar popover now avoids repeating the employee name and dates. This makes leave details easier to read and reduces clutter for users reviewing time off information.

The name of the employee and the dates were shown multiple times in the
popover. This commit aims at showing the relevant information only once.

TaskID: 2227158

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

The Vietnam localization’s chart of accounts has been updated and account names have been converted to English, with Vietnamese translations added. This helps businesses using Odoo in Vietnam work with clearer English labels while still supporting local-language use.

Task: https://www.odoo.com/web#id=2054159&action=333&active_id=1691&model=project.task&view_type=form&menu_id=4720

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

The community edition now supports the same keyboard shortcut for the Home menu that was already available elsewhere. This makes navigation more consistent and improves accessibility for users who rely on keyboard shortcuts.

Following the work on accesskeys on the website side with [1], there is
in fact no reason to have this in enterprise and not in community.
    
[1]: https://github.com/odoo/odoo/commit/0b0690a3934cedcab0d5e34373e8d40c2ab25660

Deleting a project stage that still contains tasks now gives users a guided option to move those tasks to another stage instead of blocking the action with an error. This reduces cleanup friction and helps teams reorganize project workflows without manually moving tasks first.

Before this commit, deleting a stage with tasks, the user received an
error.

With this commit, when deleting a stage containing tasks, a wizard
offers the choice to move the tasks to another stage.

TaskID: 1869030

Belgian payroll now better supports warrant salary calculations using the commission target set on an employee's contract. Payslip generation also limits work entry validation to the regular pay structure, helping avoid unnecessary checks for warrant salary processing.

A leftover debug message was removed from a purchasing and inventory test. This keeps automated test results cleaner and easier for teams to review, with no change to business functionality.

Remove forgotten debug print in test

This update prevents startup and routing failures caused by changes in a newer version of Werkzeug, a web component Odoo depends on. It also improves warning visibility so similar compatibility issues are easier to catch before they affect deployments.

Some more leftover deprecation warnings I missed in odoo/odoo#44164, which turned into errors when Werkzeug 1.0 was released, as well as a few other issues.

Before this commit, There would be an error due to the required field `name` which was not passed in vals when the user creates new Redirects through Manage Pages from Website, while the `name` field is required at the model level. In this commit, we pass 'name' field in the values of `website.rewrite` Followup on be8fc2296b3822baffe0bc68cb4b7efdfe53fa91 Description of the issue/feature this PR addresses: Current behavior before PR: ![screenshot-2040209-13-0-c53f1c runbot40 odoo co

Before this commit,  There would be an error due to the required field `name` which was not passed in vals when the user creates new Redirects through Manage Pages from Website, while the `name` field is required at the model level.

In this commit, we pass 'name' field in the values of `website.rewrite`

Followup on be8fc2296b3822baffe0bc68cb4b7efdfe53fa91

Description of the issue/feature this PR addresses:

Current behavior before PR:
![screenshot-2040209-13-0-c53f1c runbot40 odoo com-2020 04 04-14_38_05 (1)](https://user-images.githubusercontent.com/16624719/78423467-1f3be100-7684-11ea-8fdb-4a8b45be6bbf.png)
![screenshot-2040209-13-0-c53f1c runbot40 odoo com-2020 04 04-14_38_05](https://user-images.githubusercontent.com/16624719/78423470-219e3b00-7684-11ea-9bc8-65e1dd78e9ff.png)

Desired behavior after PR is merged: Able to create new Redirect




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

Forward-Port-Of: odoo/odoo#49000

Before this commit, It was not possible to copy An employee which is already linked to User due `user_uniq` constraints. Now we add `copy=False` on Related resource so Employee will be copied without linked User. 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#49805

Before this commit, It was not possible to copy An employee which is already linked to User due `user_uniq` constraints.

Now we add `copy=False` on Related resource so Employee will be copied without linked User.

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

Purpose ======= The fields `constr_mandatory` and `constr_error_msg` must be in the survey question form view. Task-2235528 Forward-Port-Of: odoo/odoo#49544

Purpose
=======
The fields `constr_mandatory` and `constr_error_msg` must be in the survey question form view.

Task-2235528

Forward-Port-Of: odoo/odoo#49544

Have a list view with an Owl field component (e.g. widget="badge"), visible. Open the optional field dropdown and make another field visible. Before this commit, the '_onToggleOptionalColumn' handler was executed twice, because two click events where triggered: one on the label, and one on its associated input (because of the for attribute, see [1]). As a consequence, the new field was added, and directly removed from the view. This could even cause subsequent crashes. The differe

Have a list view with an Owl field component (e.g. widget="badge"),
visible. Open the optional field dropdown and make another field
visible.

Before this commit, the '_onToggleOptionalColumn' handler was
executed twice, because two click events where triggered: one on
the label, and one on its associated input (because of the for
attribute, see [1]).

As a consequence, the new field was added, and directly removed
from the view. This could even cause subsequent crashes.

The difference between an Owl component and a legacy widget is
that the Owl component is async (more than a nextTick) as we wait
for the nextAnimationFrame to render. When the rendering is fast
enough (e.g. without Owl components), the click event isn't remap
to the input yet (because we empty the list HTML node), so the
handler is executed only once.

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label

Issue reported on task 2204306

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#49894
Forward-Port-Of: odoo/odoo#49847

During the upgrade of some databases to 13.0, the following traceback was reported: `psycopg2.errors.AmbiguousColumn: column reference "product_id" is ambiguous` This commit fixes this issue by prefixing product_id with the table name alias 'm'. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#49109

During the upgrade of some databases to 13.0, the following traceback
was reported:

`psycopg2.errors.AmbiguousColumn: column reference "product_id" is ambiguous`

This commit fixes this issue by prefixing product_id with the table name alias 'm'.

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

Forward-Port-Of: odoo/odoo#49109

TaskID: 2237599 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#49601

TaskID: 2237599

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

Before this commit, selecting an unsplash image on website, then going on a product page and selecting that same image in the media-dialog would not work, and upon saving, the image would be the image placeholder. A previous fix in odoo/odoo#31328 added handling so that you could choose unsplash images for a product, but it failed to account for unsplash images that had already been added on a public view (for example on a website page), which the user can choose in the media-dialog.

Before this commit, selecting an unsplash image on website, then going
on a product page and selecting that same image in the media-dialog
would not work, and upon saving, the image would be the image
placeholder.

A previous fix in odoo/odoo#31328 added handling so that you could
choose unsplash images for a product, but it failed to account for
unsplash images that had already been added on a public view (for
example on a website page), which the user can choose in the
media-dialog.

This was caused by the fix only searching for the unsplash attachment on
the current model, and not among public attachments, resulting in an
empty search result.

This commit fixes that by adding that the attachment we are looking for
should either be on the current model, or be a public attachment.

Forward-Port-Of: odoo/odoo#46112

Usecase to reproduce: - Install stock with demo data - Go on drawer form view. - The quantity forecasted and the report for forecasted quantity do not indicate the same quantity It happens because the quantity on forecast is wrong. It's due to the part that select the quants. The condition wh IS NOT NULL remove all the quants. Also using a not null on a table is probably not a good practice. Also complete the request is order to take quants in transit Description of the issue/fea

Usecase to reproduce:
- Install stock with demo data
- Go on drawer form view.
- The quantity forecasted and the report for forecasted quantity do not
indicate the same quantity

It happens because the quantity on forecast is wrong. It's due to the
part that select the quants. The condition wh IS NOT NULL remove all
the quants. Also using a not null on a table is probably not a good
practice.

Also complete the request is order to take quants in transit

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

Steps to reproduce the bug: - Login with demo user (no accounting app access) - Go to any product with Update Cost button and try to update it Bug: Error message "You don't have the access rights to post an invoice" even if the inventory valuation was manual. opw:2240513 Forward-Port-Of: odoo/odoo#49856 Forward-Port-Of: odoo/odoo#49780

Steps to reproduce the bug:

- Login with demo user (no accounting app access)
- Go to any product with Update Cost button and try to update it

Bug:

Error message "You don't have the access rights to post an invoice" even if
the inventory valuation was manual.

opw:2240513

Forward-Port-Of: odoo/odoo#49856
Forward-Port-Of: odoo/odoo#49780

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

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

When sale_product_configurator is installed, products created/chosen on sales order lines are product template and not product.product. When creating a product on the fly, the context on the product_template_id field is wrong because applied to the product.template AND the product.product. Contrary to the automatic creation of a template when a product.product is created (orm-side), we have custom code in product ensuring that when a template is created, product.product(s) are created.

When sale_product_configurator is installed, products created/chosen on
sales order lines are product template and not product.product.

When creating a product on the fly, the context on the product_template_id
field is wrong because applied to the product.template AND the product.product.

Contrary to the automatic creation of a template when a product.product is created (orm-side),
we have custom code in product ensuring that when a template is created, product.product(s)
are created.  But this step doesn't clear the context like the orm does.

This means that the default_lst_price=0 in the context won't be applied for the
product.template creation, but will be for the product.product creation:

1) product.template created
2) product.product creation, based on product.template vals
  * in the create, the call to _add_missing_default_values will give a
  default value for lst_price.
  * this will trigger the inverse_related for the field, resetting the
  template price.

To avoid this problem, we modify the view to specify list_price instead of lst_price in the context,
because this field will be protected by the orm because it is inherited from the product.template.





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

Forward-Port-Of: odoo/odoo#49934

Small bug introduced by [1]: now the website menu is loaded on demand to avoid useless page loading. This was done when hovering the toggle which induced two problems: not loaded if the user was already over the button when the JS is fully loaded and not loaded if the dropdown was opened via the keyboard. Also, the 'mouseover' event was used instead of the 'mouseenter' and the RPC was not checked for already pending ones. Both issues could lead to have the RPC performed multiple times f

Small bug introduced by [1]: now the website menu is loaded on demand
to avoid useless page loading. This was done when hovering the toggle
which induced two problems: not loaded if the user was already over the
button when the JS is fully loaded and not loaded if the dropdown was
opened via the keyboard.

Also, the 'mouseover' event was used instead of the 'mouseenter' and the
RPC was not checked for already pending ones. Both issues could lead to
have the RPC performed multiple times for no reason.

[1]: https://github.com/odoo/odoo/commit/4206c1f225f5b1c54a0cdd4913e1d8224a2e7889

Forward-Port-Of: odoo/odoo#49721

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

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

In 13.0 66ef641 the source field was removed. This would cause an error when gengo is updating a existing ir.translation record (eg. if we do two times gengo auto-translations). opw-2234713 Forward-Port-Of: odoo/odoo#49884

In 13.0 66ef641 the source field was removed.

This would cause an error when gengo is updating a existing
ir.translation record (eg. if we do two times gengo auto-translations).

opw-2234713

Forward-Port-Of: odoo/odoo#49884

Adapt gengo to change on translator editor classes and assets. opw-2234713 Forward-Port-Of: odoo/odoo#49978

Adapt gengo to change on translator editor classes and assets.

opw-2234713

Forward-Port-Of: odoo/odoo#49978

Before this commit, when re-activating a previously active notebook tab, the form renderer would assume that a tab was actually active. However this does not happen if no tab is visible or defined and it results in a crash instead. Now, if no active tab is found, a default active tab (0 = first) is set. This only helps to prevent the crash and does not affect the current behaviour. Forward-Port-Of: odoo/odoo#49932

Before this commit, when re-activating a previously active notebook tab, the form
renderer would assume that a tab was actually active. However this does not happen
if no tab is visible or defined and it results in a crash instead.

Now, if no active tab is found, a default active tab (0 = first) is set. This only
helps to prevent the crash and does not affect the current behaviour.

Forward-Port-Of: odoo/odoo#49932

Forward-Port-Of: odoo/odoo#49634

Forward-Port-Of: odoo/odoo#49634

Before this commit, if the user didn't use a specific package it's considered that he put everything inside a single package. But only the weight of the package was sent to easypost. Now, the predefined package and the parcel dimensions if exists are also sent. Fine-tuning of 6487e447ec8f925c04b72b0a5e355ab689ea7dfd opw-2209365 Forward-Port-Of: odoo/enterprise#10114

Before this commit, if the user didn't use a specific package it's
considered that he put everything inside a single package. But only the
weight of the package was sent to easypost.

Now, the predefined package and the parcel dimensions if exists are also
sent.

Fine-tuning of 6487e447ec8f925c04b72b0a5e355ab689ea7dfd

opw-2209365

Forward-Port-Of: odoo/enterprise#10114

Purpose ======= With all the demo data installed, the loading of the page could take more than 5 seconds, as the first loading loads all the work entries for all the employees on the given period. here, we generate several hundreds records. Specification ============= Load this month and the last month work entries, to avoid creating all those records when running the click all. TaskID: 2225365 Forward-Port-Of: odoo/enterprise#10110

Purpose
=======

With all the demo data installed, the loading of the page could take more than
5 seconds, as the first loading loads all the work entries for all the employees
on the given period. here, we generate several hundreds records.

Specification
=============

Load this month and the last month work entries, to avoid creating
all those records when running the click all.

TaskID: 2225365

Forward-Port-Of: odoo/enterprise#10110

Forward-Port-Of: odoo/enterprise#9989 Forward-Port-Of: odoo/enterprise#9954

Forward-Port-Of: odoo/enterprise#9989
Forward-Port-Of: odoo/enterprise#9954

When sale_product_configurator is installed, products created/chosen on sales order lines are product template and not product.product. When creating a product on the fly, the context on the product_template_id field is wrong because applied to the product.template AND the product.product. Contrary to the automatic creation of a template when a product.product is created (orm-side), we have custom code in product ensuring that when a template is created, product.product(s) are created.

When sale_product_configurator is installed, products created/chosen on
sales order lines are product template and not product.product.

When creating a product on the fly, the context on the product_template_id
field is wrong because applied to the product.template AND the product.product.

Contrary to the automatic creation of a template when a product.product is created (orm-side),
we have custom code in product ensuring that when a template is created, product.product(s)
are created.  But this step doesn't clear the context like the orm does.

This means that the default_lst_price=0 in the context won't be applied for the
product.template creation, but will be for the product.product creation:

1) product.template created
2) product.product creation, based on product.template vals
    * in the create, the call to _add_missing_default_values will give a
    default value for lst_price.
    * this will trigger the inverse_related for the field, resetting the
    template price.

To avoid this problem, we modify the view to specify list_price instead of lst_price in the context,
because this field will be protected by the orm because it is inherited from the product.template.

Forward-Port-Of: odoo/enterprise#10101

Steps to reproduce the bug: - Let's consider two companies A and B - Let's consider a user U in A and not aloowed in B - Let's consider a project P in B with a task T - Let's consider an employee E in B with several timesheets linked to T - Log as U and go to Project > Reporting > Timesheet and Planning Analysis Bug: The employee E was displayed even if E was in company B opw:2234497 Forward-Port-Of: odoo/enterprise#10023 Forward-Port-Of: odoo/enterprise#9956

Steps to reproduce the bug:

- Let's consider two companies A and B
- Let's consider a user U in A and not aloowed in B
- Let's consider a project P in B with a task T
- Let's consider an employee E in B with several timesheets linked to T
- Log as U and go to Project > Reporting > Timesheet and Planning Analysis

Bug:

The employee E was displayed even if E was in company B

opw:2234497

Forward-Port-Of: odoo/enterprise#10023
Forward-Port-Of: odoo/enterprise#9956