This fix ensures Belgian payroll meal voucher calculations use the latest work entry data before running. It helps avoid misleading test results and improves confidence that voucher computations are based on complete payroll information.

…chers

Purpose
=======

On some tests, it could lead to false positive if the work entries creation
and the meal vouchers computation are done during the same transaction.

TASKID: 2357771

edi_document_ids was ir.attachment but is now account.edi.document. 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#59345

edi_document_ids was ir.attachment but is now account.edi.document.


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

**Description of the issue/feature this PR addresses:** In case we have an account type which is allowed it is not needed to check the account allowed as it would fail although the account type is allowed before, so we need to do the check correctly as it was done in previous versions. Also improve the error messages as the user has no clue which account failed. **Current behavior before PR:** If you try to constrain by an account type and also with specific accounts the account type i

**Description of the issue/feature this PR addresses:**
In case we have an account type which is allowed it is not needed to check the account allowed as it would fail although the account type is allowed before, so we need to do the check correctly as it was done in previous versions.

Also improve the error messages as the user has no clue which account failed.


**Current behavior before PR:**
If you try to constrain by an account type and also with specific accounts the account type is just a useless contraint overruled by the specific account which might try to limit another field.

**Example**: 
- **Allowed Account Types**: Receivable
- **Allowed Accounts**: Specific expense accounts

**Desired behavior after PR is merged:**
Fix the refactored code that it does behave like it was in all the versions before.

Info: @wt-io-it


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

Forward-Port-Of: odoo/odoo#59376
Forward-Port-Of: odoo/odoo#58132

We are using term "Vendor" on all views. 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#58540

We are using term "Vendor" on all views.

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

Multiple issues with the search in the OrderManagementScreen: - Create 2 orders and assign the same customer to both - Create enough empty orders so that those 2 orders are now on the 3rd page - Search for this customer from the search bar: - The 1st page is empty - When you go to the next page, the number of total pages changes to 2 instead of 3 - There's only 1 result instead of 2 - https://drive.google.com/file/d/16131cACQbskbnaWh4oXRxpLSOs0S-d5l/view -- I confirm I have signed the

Multiple issues with the search in the OrderManagementScreen:
- Create 2 orders and assign the same customer to both
- Create enough empty orders so that those 2 orders are now on the 3rd page
- Search for this customer from the search bar:
- The 1st page is empty
- When you go to the next page, the number of total pages changes to 2 instead of 3
- There's only 1 result instead of 2
- https://drive.google.com/file/d/16131cACQbskbnaWh4oXRxpLSOs0S-d5l/view

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

Forward-Port-Of: odoo/odoo#57674

Bug === In the user profile view, we can see the certifications of the current user. If we click on the share button, we are redirected to the course instead of opening the share modal. Technical ========= Since 1f52435966edeb1d57ef8bccce7f82eb0b08a2ae we use an on-lick event to redirect the user when he click on the card. We use the JS event instead of an standard anchor because nested anchors are forbidden in HTML. That cause an issue if we click on a child anchor and if we sta

Bug
===
In the user profile view, we can see the certifications of the current user.

If we click on the share button, we are redirected to the course instead
of opening the share modal.

Technical
=========
Since 1f52435966edeb1d57ef8bccce7f82eb0b08a2ae we use an on-lick event to
redirect the user when he click on the card. We use the JS event instead
of an standard anchor because nested anchors are forbidden in HTML.

That cause an issue if we click on a child anchor and if we stay on the
same page (which is the case when we open a bootstrap modal) because the
on-click event will be triggered.

We can not just stop the click propagation otherwise the modal won't be
opened.

Also, as the bootstrap modal element (`website_slides.slide_share_modal`)
is inside the element with the on-click event, so, if we click anywhere
on the modal, we will be redirected...

So, the solution is to open manually the modal, to stop the click
propagation and to move the modal element.

Task-2337693

Forward-Port-Of: odoo/odoo#57844

Since 3d65424708d, if the homepage does not exists (no page with '/' as URL, no page set as homepage), it would loop between / controller and _serve_page. task-2250381 Forward-Port-Of: odoo/odoo#59530

Since 3d65424708d, if the homepage does not exists (no page with '/' as URL,
no page set as homepage), it would loop between / controller and _serve_page.

task-2250381

Forward-Port-Of: odoo/odoo#59530

Issue ----- Automatic assignation assign leads mostly based on country. So far the country need to be set manually on the lead. Solution -------- Since we have the information on the website vistor works, set the country on the lead from the visitor website. Unless the visitor is link to a partner with a country. In that case setting a country will cancel the address sync from the partner to the lead. -- I confirm I have signed the CLA and read the PR guidelines at www.od

Issue
-----
Automatic assignation assign leads mostly based on country.
So far the country need to be set manually on the lead.

Solution
--------
Since we have the information on the website vistor
works, set the country on the lead from the visitor
website. Unless the visitor is link to a partner
with a country. In that case setting a country
will cancel the address sync from the partner to the lead.





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

Forward-Port-Of: odoo/odoo#59528

- Create companies A & B - Switch to company B - Open a POS session in company B, but do not close it - Switch to company A - Set a Lock Date for Non-Advisers The error message 'Please close all the point of sale sessions...' is raised. The message shouldn't be raised since the session is not in the company we are setting a lock date. We filter the session based on the company. opw-2351930 Description of the issue/feature this PR addresses: Current behavior before PR:

- Create companies A & B
- Switch to company B
- Open a POS session in company B, but do not close it
- Switch to company A
- Set a Lock Date for Non-Advisers

The error message 'Please close all the point of sale sessions...' is
raised.

The message shouldn't be raised since the session is not in the company
we are setting a lock date.

We filter the session based on the company.

opw-2351930

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

If no bank journal with no account set can be found, we should return False instead of an empty record. Description of the issue/feature this PR addresses: opw-2355561 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#59572

If no bank journal with no account set can be found, we should return False
instead of an empty record.

Description of the issue/feature this PR addresses:
opw-2355561

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

Same issue than for commit 203bb4d9c11 but for dropship rules instead of missing dropship types. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#59566

Same issue than for commit 203bb4d9c11 but for dropship rules instead of
missing dropship types.

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

Forward-Port-Of: odoo/odoo#59566

Current behavior before PR: It is possible to create a BOM that has a BOM line that reference the same product as the BOM itself. This is undesirable as when we create a manufacturing order for this product we will have an error. It is a regression bug that was introduced in commit 575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13. Behavior after PR is merged: When saving a BOM it will validate that no product line references the same product, or the same product vari

Current behavior before PR:

It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself.  This is undesirable as when we create a
manufacturing order for this product we will have an error.

It is a regression bug that was introduced in commit
575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13.

Behavior after PR is merged:

When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself.  Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.

opw-2347941

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#59485
Forward-Port-Of: odoo/odoo#59181

- don't reset `stringifiedDomain` when changing thread (this led to the control panel displaying obsolete filters) - refresh non-main cache that are currently displayed when there is a known change of messages in the same thread's main cache - refresh non-main-cache on displaying them, to fetch potentially new messages - fix discuss "select all" conditions task-2171873 task-2282374 Forward-Port-Of: odoo/odoo#59139

- don't reset `stringifiedDomain` when changing thread (this led to the
  control panel displaying obsolete filters)
- refresh non-main cache that are currently displayed when there is a known
  change of messages in the same thread's main cache
- refresh non-main-cache on displaying them, to fetch potentially new messages
- fix discuss "select all" conditions

task-2171873
task-2282374

Forward-Port-Of: odoo/odoo#59139

The `_error_checking()` context manager is used to perform validation and cleanup after changes on work entries, and is implemented using a try/finally clause. This mechanism fails to take into account that the alteration operation can fail due to a concurrent update (in another transaction). In such a situation the db cursor becomes instantly invalid, and any attempt to use it will fail with: `psycopg2.InternalError: current transaction is aborted`. This exception will be raised in the `fi

The `_error_checking()` context manager is used to perform validation and cleanup after changes on work entries, and is implemented using a try/finally clause.

This mechanism fails to take into account that the alteration operation can fail due to a concurrent update (in another transaction). In such a situation the db cursor becomes instantly invalid, and any attempt to
use it will fail with: `psycopg2.InternalError: current transaction is aborted`.
This exception will be raised in the `finally` block, and will therefore discard the original TransactionRollbackException.

The result: instead of being silently retried as expected, the transaction fails and the user receives a cryptic error message.

Steps to repro: repeatedly click on the button to validate a leave

Solution: specifically handle PostgreSQL `OperationalError` exceptions and do not attempt to use the cursor when they occur - just let the exception bubble up.

Forward-Port-Of: odoo/odoo#59574

Before this commit, the option to open dropdown on hover did not work with mega menu. task-2312878 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#59593

Before this commit, the option to open dropdown on hover did not work
with mega menu.

task-2312878

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

- Activate debug mode - Go to Settings > Technical > Templates - Duplicate "Invoice: Send by email" and edit the copy (Name & Content) - Go to Accounting > Customers > Invoices and create an Invoice - Post it - Send & Print - In the wizard, select the duplicated template (the content will be updated) - Uncheck "Email" option, the re-check it The selected template is still the duplicated one, but the content is the one from the default template. opw-2345200 Description of the issue/

- Activate debug mode
- Go to Settings > Technical > Templates
- Duplicate "Invoice: Send by email" and edit the copy (Name & Content)
- Go to Accounting > Customers > Invoices and create an Invoice
- Post it
- Send & Print
- In the wizard, select the duplicated template (the content will be updated)
- Uncheck "Email" option, the re-check it
The selected template is still the duplicated one, but the content is the one from the default template.

opw-2345200

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

This reverts commit odoo/odoo@681306d4e76faeb119d363c263c54b287cb5c150. Adding groups on assets parts is not a good idea. Indeed as assets are compiled and optimized we do not want to serve different assets to different users. For example if you have several users in parallel on several workers those could try to regenerate assets for their users. As each user has different assets this could lead to big performance issue. As original commit tried to solve a race condition we can saf

This reverts commit odoo/odoo@681306d4e76faeb119d363c263c54b287cb5c150.

Adding groups on assets parts is not a good idea. Indeed as assets are
compiled and optimized we do not want to serve different assets to different
users.

For example if you have several users in parallel on several workers those
could try to regenerate assets for their users. As each user has different
assets this could lead to big performance issue.

As original commit tried to solve a race condition we can safely remove the
assets fix to avoid issues and work on a cleaner solution.

See original ref odoo/odoo#51804 and odoo/enterprise#10737

Forward-Port-Of: odoo/odoo#59578

Following [1]. The mentioned commit selectors were to be simplified and actually did not solve the problem in mobile affixed menu. Also, targeting "o_affix_enabled" to target the non-affix menu was wrong since when there is no affix menu, no header has the "o_affix_enabled" class as its names indicates it. So the mentioned commit fixed half of the problem and only when the website used the affix menu feature... Let's hope this new commit fixes everything. [1]: https://github.com/odoo/od

Following [1]. The mentioned commit selectors were to be simplified and
actually did not solve the problem in mobile affixed menu. Also,
targeting "o_affix_enabled" to target the non-affix menu was wrong since
when there is no affix menu, no header has the "o_affix_enabled" class
as its names indicates it. So the mentioned commit fixed half of the
problem and only when the website used the affix menu feature... Let's
hope this new commit fixes everything.

[1]: https://github.com/odoo/odoo/commit/21959599d1c25321865afabe7f70191efdda154e

Forward-Port-Of: odoo/odoo#59597
Forward-Port-Of: odoo/odoo#57709

This fixes a crash in some controllers with `auth='None'` where some updates are flushed with an environment where `uid=None`. When there is an environment with a real uid, preferably use it. Forward-Port-Of: odoo/odoo#59225

This fixes a crash in some controllers with `auth='None'` where some
updates are flushed with an environment where `uid=None`.  When there is
an environment with a real uid, preferably use it.

Forward-Port-Of: odoo/odoo#59225

- Create 2 companies A & B - Set a website on company A - Switch to company B - Open a done MO - Open the cost analysis An AccessError is displayed. The error arises in: https://github.com/odoo/enterprise/blob/923cbffe4e60572a5c17ee962d571c037e9cff44/mrp_account_enterprise/reports/mrp_cost_structure.py#L90 The root cause is coming from the call to `/report/html/`, which is called without any `data`. In this situation, the following adds an incorrect `allowed_company_ids` in the c

- Create 2 companies A & B
- Set a website on company A
- Switch to company B
- Open a done MO
- Open the cost analysis

An AccessError is displayed.

The error arises in:
https://github.com/odoo/enterprise/blob/923cbffe4e60572a5c17ee962d571c037e9cff44/mrp_account_enterprise/reports/mrp_cost_structure.py#L90

The root cause is coming from the call to `/report/html/`, which is
called without any `data`. In this situation, the following adds an
incorrect `allowed_company_ids` in the context:

https://github.com/odoo/odoo/blob/d1413a2f06bcb44b1fbb6dba8658e698c8da4018/addons/website/models/ir_http.py#L196-L205

Indeed, the `allowed_company_ids` is the one from the website, in this
case company A.

The issue doesn't occur when downloading a PDF from the interface since
in this case the `data` dictionary contains the appropriate context
which is set in:

https://github.com/odoo/odoo/blob/d1413a2f06bcb44b1fbb6dba8658e698c8da4018/addons/web/controllers/main.py#L1958

As a solution, something similar to what is done elsewhere:
https://github.com/odoo/odoo/blob/d1413a2f06bcb44b1fbb6dba8658e698c8da4018/addons/mail/controllers/main.py#L77
https://github.com/odoo/enterprise/blob/923cbffe4e60572a5c17ee962d571c037e9cff44/account_reports/controllers/main.py#L19-L21

opw-2341747

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#59632
Forward-Port-Of: odoo/odoo#59214

Issue - Create promotion program with product_x - Create new quotation - Add product_x on the first line - Add another product_x on the second line - Press "Promotions" button Cause The attribut reward_product_qty except singleton but order_line contain more than one element Solution Take the order line with the higher quantity opw-2350574 Forward-Port-Of: odoo/odoo#59434

Issue

    - Create promotion program with product_x
    - Create new quotation
    - Add product_x on the first line
    - Add another product_x on the second line
    - Press "Promotions" button

Cause

    The attribut reward_product_qty except singleton but order_line contain more than one element

Solution

    Take the order line with the higher quantity

opw-2350574

Forward-Port-Of: odoo/odoo#59434

When lines are loaded in the reconciliation widget, get_bank_statement_data and get_bank_statement_line_data both return the same object containing e.g. {st_line: [], reconciliation_proposition: [], lines: []}. Then, the value of 'lines' should be passed to _formatLine. However in loadData, which is called after reconciling an entry, and if an additional line should be loaded in the reconciliation widget, the value passed was incorrect. Before saas-12.3, res['lines'] was passed to _formatL

When lines are loaded in the reconciliation widget, get_bank_statement_data
and get_bank_statement_line_data both return the same object containing e.g.
{st_line: [], reconciliation_proposition: [], lines: []}.
Then, the value of 'lines' should be passed to _formatLine. However
in loadData, which is called after reconciling an entry, and if an additional
line should be loaded in the reconciliation widget, the value passed was
incorrect. Before saas-12.3, res['lines'] was passed to _formatLine. We
do the same change to ensure the correct value is passed to _formatLine.

opw 2299574

Forward-Port-Of: https://github.com/odoo/odoo/pull/59428

Forward-Port-Of: odoo/enterprise#13938

The files were quite old and contained sometimes outdated translations such as, in fr_BE.po ``` msgid "Send" msgstr "Envoyé ``` (instead of "Envoyer") Remove the entries from fr_*.po if: - no longer exists in .pot - do not have a translation - have a translation similar as in the fr.po file Forward-Port-Of: odoo/enterprise#13944 Forward-Port-Of: odoo/enterprise#13920

The files were quite old and contained sometimes outdated translations
such as, in fr_BE.po
```
msgid "Send"
msgstr "Envoyé
```
(instead of "Envoyer")

Remove the entries from fr_*.po if:
- no longer exists in .pot
- do not have a translation
- have a translation similar as in the fr.po file

Forward-Port-Of: odoo/enterprise#13944
Forward-Port-Of: odoo/enterprise#13920

task-2171873 task-2282374 Forward-Port-Of: odoo/enterprise#13849

task-2171873
task-2282374

Forward-Port-Of: odoo/enterprise#13849

FIX] account_reports: partner ledger and aml without partner … f3ab4e7 Prior to this commit, the partner ledger was failing at giving correct numbers in case of journal items on receivable/payable accounts not linked to any partner: - There was no section in the report at all showing those lines, which lead to a grand total of the partner ledger not matching the total of the receivable/payable accounts from the general ledger - Balances per partner were wrong as well, as invoices paid usin

FIX] account_reports: partner ledger and aml without partner …
f3ab4e7
Prior to this commit, the partner ledger was failing at giving correct numbers in case of journal items on receivable/payable accounts not linked to any partner:
 - There was no section in the report at all showing those lines, which lead to a grand total of the partner ledger not matching the total of the receivable/payable accounts from the general ledger
 - Balances per partner were wrong as well, as invoices paid using a line without partner would appear without their counterpart

In order to fix that,
 - a section 'Unknown Partner' was added in the report, as last line. It is not aligned because of the missing trust image, which I find OK.
 - the details and balances of partners now take in consideration the reconciliation made with lines having no partner. They appear in text-muted to show the difference (and a text-muted line can appear several times as it will be spread per its partial reconciliation amounts)
 - a test was added that describe the full use case

Forward-Port-Of: odoo/enterprise#13930
Forward-Port-Of: odoo/enterprise#13387

Issue Install project_timesheet_forecast Cause The parent selector is not defined Maybe its caused by the sass library Solution Remove parent selector call opw-2349942 Forward-Port-Of: odoo/enterprise#13917

Issue

    Install project_timesheet_forecast

Cause

    The parent selector is not defined
    Maybe its caused by the sass library

Solution

    Remove parent selector call

opw-2349942

Forward-Port-Of: odoo/enterprise#13917

[FIX] account_reports: fix infinite recursion when folding financial report line An infinite recursion happened in case a financial report line was using a groupby, and one of its children had the same id as its parent (which was possible because line ids were built from different models), when trying to fold the line. We now make the ids of the lines created by the groupby unique, and modify the caret options available on such grouped lines accordingly (that is, only the ones applicable to a

[FIX] account_reports: fix infinite recursion when folding financial report line

An infinite recursion happened in case a financial report line was using a groupby, and one of its children had the same id as its parent (which was possible because line ids were built from different models), when trying to fold the line. We now make the ids of the lines created by the groupby unique, and modify the caret options available on such grouped lines accordingly (that is, only the ones applicable to account.account, by design).

OPW 2301756

[FIX] account_reports: manage annotations correctly on groupby-created lines in case a group is repeated across multiple report lines.

This second bug also happened because those groups share the same id. The annotation made for one were shared between all of them. When making an annotation, we expect it to be displayed only on the line we click ("annotate") for, not to spread it on other lines sharing some characteristic with it (for example, the same account or partner).

Forward-Port-Of: odoo/enterprise#13916
Forward-Port-Of: odoo/enterprise#13767