Corrects a settings filter so it compares matching value types, avoiding unexpected results. This helps ensure the relevant configuration options are shown or hidden reliably for users.

Comparing integer and string does not have the expected result

This fix corrects the alignment of the confirmation message that appears when users validate their timesheets. The notification now displays in the proper centered position, improving the visual presentation and user experience when submitting timesheet entries.

Before this PR when we validate timesheet toast notification was not correctly centered.
After this PR when we validate timesheet toast notification is correctly centered.

task-3433667

This update removes an outdated field called "show_operations" from the manufacturing work order form view. The field was already removed from the core system, and this change ensures the enterprise version stays synchronized with that update, preventing display errors and maintaining consistency across the application.

In COM PR linked, `show_operations` field is removed from the form view inherited here.

COM PR: odoo/odoo#140898

This update prevents users from editing the follow-up report directly in Studio, since it's composed only of an email template. Users who need to customize follow-up communications can now edit the underlying email template instead, which is the proper way to modify this report's content.

opw-3551400

Forward-Port-Of: odoo/enterprise#50833

This update completes the cleanup process for the AvaTax accounting module to ensure it's properly neutralized in non-production environments. The fix removes residual production settings that could confuse users even when the module is disabled, bringing the system in line with how it's handled in earlier versions.

This commit adds a missing part of the neutralisation of the
account_avatax app. This brings it back in line with the complete
neutralisation script that is used on the PaaS and SaaS in versions < 16.0

Forward-Port-Of: odoo/enterprise#50889

This update restores a scroll test in the mail messaging system that was previously removed. The fix ensures that the automatic scrolling behavior in the message chatter works correctly and is properly validated through testing.

Fixes in community PR.

https://github.com/odoo/odoo/pull/142308

The aged payable audit helper text was displaying as plain text instead of formatted markup. This fix applies proper formatting to the helper content, improving readability and presentation of the audit information in the aged payable report.

This commit makes the helper of the auditing action of the aged payable report markup as it is currently not the case and its content is in plain text.

This update adds a verification check to ensure that helpdesk teams are properly found during testing. Previously, the system would attempt to update a helpdesk team without confirming it existed, which could lead to silent failures. This fix adds a safety check to catch and report any issues when helpdesk teams cannot be located.

Before this commit, the test does a search to fetch a helpdesk team to do a write but we don't check if the helpdesk is found

This commit adds an assert to be sure a helpdesk team is found with the search called.

runbot-21676

Forward-Port-Of: odoo/enterprise#50997

This update corrects how column labels appear in accounting reports. Previously, column labels were displayed in lowercase, making them harder to read. The fix now displays labels in proper formatting, improving the visual presentation and readability of financial reports for users.

Before this commit we use `column.name` as label of our columns for report lines in the report form view.
It caused that the label was in lower case.
The aim of this commit is using the `label` instead of the `name` to have the column `label` well formatted.

Before:
![image](https://github.com/odoo/enterprise/assets/6582885/8dfa8ccf-3faf-4f19-89a3-1f7bf0b15985)

After:
![image](https://github.com/odoo/enterprise/assets/6582885/a79d0046-0223-44a0-8a19-306a2aefbda7)


no task id

A recent update removed the "plan" button from the sales planning calendar view to reduce clutter. This fix updates the automated test to work with the new interface by clicking directly on the calendar cell instead of looking for the removed button. This ensures the test continues to work properly with the updated user interface.

Before this commit, a recent generic change removes the "add" and "plan" buttons in each gantt cell to avoid having too many elements available in the gantt view. That changes has not been adapted for the sale_planning tour and so the step failed because it no longer found plan button.

This commit removes the step failed and adapt the previous step to just click on the grid cell to display the plan dialog.

runbot-25881

Two automated tests in the Planning and Project Forecast modules were failing when run on weekends because the system's working schedule doesn't include weekends. This fix ensures these tests always run during weekdays by freezing the test execution time, making the tests reliable and consistent regardless of when they're run.

## [FIX] project_forecast: freeze time for test_shift_creation_from_project

Before this commit, the `test_shift_creation_from_project` test failed
during the weekend because the working schedule of the current company
considers the weekend is not a working day and so instead of creating a
planning template during 2 days, it will create a planning template during
one day.

This commit freezes the time to be sure, the test is executed during a
working day to stay valid and keep the same behavior to test.

runobt-41215

## [FIX] planning: freeze time for test_shift_creation_from_role

Before this commit, the `test_shift_creation_from_role` test failed
during the weekend because the working schedule of the current company
considers the weekend is not a working day and so instead of creating a
planning template during 2 days, it will create a planning template during
one day.

This commit freezes the time to be sure, the test is executed during a
working day to stay valid and keep the same behavior to test.

runobt-41977

Forward-Port-Of: odoo/enterprise#50999

Avoid getting the following warning when validating an XRechnung on https://erechnungsvalidator.service-bw.de/ : "[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen." issue-142127 Forward-Port-Of: odoo/odoo#142374

Avoid getting the following warning when validating an XRechnung on https://erechnungsvalidator.service-bw.de/ :

"[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen."

issue-142127

Forward-Port-Of: odoo/odoo#142374

When a product has been unbuilt and also (mistakenly) scrapped, it's impossible to reuse the serial number in production again, even if the product is unscrapped. This fixes the sanity check in a similar way to the _check_sn_uniqueness function, not just checking for removed stock move lines, but also unremoved stock move lines. A test case is also added to check this scenario. This is a similar fix to a previous commit we did (4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped int

When a product has been unbuilt and also (mistakenly) scrapped, it's impossible to reuse the serial number in production again, even if the product is unscrapped.

This fixes the sanity check in a similar way to the _check_sn_uniqueness function, not just checking for removed stock move lines, but also unremoved stock move lines. A test case is also added to check this scenario.

This is a similar fix to a previous commit we did
(4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped into a problem with the duplicate serial sanity check.

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

Forward-Port-Of: odoo/odoo#142492
Forward-Port-Of: odoo/odoo#139643

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

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

[FIX] mrp: clear move_raw_id when the product variant is changed Steps to reproduce the bug: - Create a storable product with two attribute “P1”: - Color: Red and Blue - Create a BoM: - Product template: P1 - BoM lines: - C1: 1 unit -> apply on variant P1 red - C2: 1 unit -> apply on variant P1 blue - Create a MO: - 1 unit of P1 red - Only the component C1 is added, which is correct. - Change the product to P1 blue. Problem: The C1 componen

[FIX] mrp: clear move_raw_id when the product variant is changed

Steps to reproduce the bug:
- Create a storable product with two attribute “P1”:
    - Color: Red and Blue

- Create a BoM:
    - Product template: P1
    - BoM lines:
        - C1: 1 unit -> apply on variant P1 red
        - C2: 1 unit -> apply on variant P1 blue

- Create a MO:
    - 1 unit of P1 red

- Only the component C1 is added, which is correct.
- Change the product to P1 blue.

Problem:
The C1 component is not removed because to clear the move_raw_id, we only check if the BoM is changed. However, in this case, it doesn't change.

opw-3591800

Forward-Port-Of: odoo/odoo#142370

If the option "Lock Posted Entries with Hash" is enabled on the inventory journal, it will be impossible to post a bill with a price difference (a `UserError` error will be raised) When there is a price difference, we create a SVL and validate its accounting entires: https://github.com/odoo/odoo/blob/724d88e3863b9e96069bc4a53bfd9081c30eb2b1/addons/purchase_stock/models/account_invoice.py#L167-L168 We will create and post a new AM and the SVL will be then linked to it. Then, we post the

If the option "Lock Posted Entries with Hash" is enabled on the
inventory journal, it will be impossible to post a bill with a price
difference (a `UserError` error will be raised)

When there is a price difference, we create a SVL and validate its
accounting entires:
https://github.com/odoo/odoo/blob/724d88e3863b9e96069bc4a53bfd9081c30eb2b1/addons/purchase_stock/models/account_invoice.py#L167-L168
We will create and post a new AM and the SVL will be then linked to it.
Then, we post the bill. Thanks to that, the bill has now a correct
name, and we use it in the SVL description and in the label of the AML
linked the SVL:
https://github.com/odoo/odoo/blob/8b37cd2960f748fa502c6c216f9db41ae93827ed/addons/purchase_stock/models/account_invoice.py#L178
But here is the issue: the AML is posted and since the journal is
locked, we can't change its label:
https://github.com/odoo/odoo/blob/39b44dbfef0d533722ce2c96d375ada113d32b00/addons/account/models/account_move_line.py#L1455-L1461

We need the name of the bill before posting the SVL, so we have to
post the bill first. And here is a new issue: when posting the bill, it
leads to the override in `/stock_account` where we try to reconcile
the anglo saxon AMLS:
https://github.com/odoo/odoo/blob/8444f5aae8b83c113e1cd2864ec11e92d836780a/addons/stock_account/models/account_move.py#L54
But it's too soon as we haven't yet validated the SVL's accounting
entries. So we need to prevent this reconciliation, validate the SVL
entries, and only then reconcile all AMLs.

Note: This will actually fix another use case. In some cases, when
validating a p_diff SVL, it does not generate any new AM:
https://github.com/odoo/odoo/blob/8b37cd2960f748fa502c6c216f9db41ae93827ed/addons/purchase_stock/models/account_invoice.py#L167-L168
https://github.com/odoo/odoo/blob/eb022e388b62856020d95e063ec0dfd4b786c4a9/addons/stock_account/models/stock_valuation_layer.py#L53
https://github.com/odoo/odoo/blob/3e2421982c229af44aa0f46dfd91bcff3fd729a0/addons/stock_account/models/stock_move.py#L557-L560
In such case, the SVL is still linked to the bill. As a result, we
wrote the bill name on all lines of that bill, which was incorrect.
See `test_pdiff_and_aml_labels` for more details

OPW-3446950
OPW-3550013

Forward-Port-Of: odoo/odoo#139200

Issue: ====== When choosing product with attributes that have attributes which have variant creation mode never it will not take into account the extra price. Steps to reproduce the issue: ============================= - Install pos , restaurant - Create a product which have `Size` attribute and add some values in it, 'S' and 'M' for example , then add extra prices in each one of them. Enable available in POS setting in Sales page of the product. - Got to point of sala , click on 3 d

Issue:
======
When choosing product with attributes that have attributes which have variant creation mode never it will not take into account the extra price.

Steps to reproduce the issue:
=============================
- Install pos , restaurant
- Create a product which have `Size` attribute and add some values in it, 'S' and 'M'  for example , then add extra prices in each one of them. Enable available in POS setting in Sales page of the product.

- Got to point of sala , click on 3 dots in restaurant and open mobile menu.
- Added the created product to cart and click review.
- The price shown is the original price of the product and not taking into account the extra price of the attribute.

Origin of the issue:
====================
This was not supported before

Solution:
=========
Using the selected_attributes value in the line we can calculate the extra_price of those attributes and add it to the price_unit so we can get taxed_amount and untaxed_amount correctly.

opw-3511374

Forward-Port-Of: odoo/odoo#142173

Steps: - Open Projects - Go to Tasks - Create a SOL on the fly - Create a new product on the fly (click on 'create', not on 'create and edit') - There is a field for delivered quantity which is editable Issue: - The 'delivered quantity' is editable when it shouldn't be Cause: - The readonly attribute was only given when delivered_quantity method is not manual. Fix: - By making delivered quantity field readonly for project task form view. Task: 3522113 Forward-P

Steps:
 - Open Projects
 - Go to Tasks
 - Create a SOL on the fly
 - Create a new product on the fly (click on 'create', not on 'create and edit')
 - There is a field for delivered quantity which is editable

 Issue:
 - The 'delivered quantity' is editable when it shouldn't be

 Cause:
 - The readonly attribute was only given when delivered_quantity method is not manual.

 Fix:
 - By making delivered quantity field readonly for project task form view. 
 
 Task: 3522113

Forward-Port-Of: odoo/odoo#137850

In Odoo, incoming contracts are defined as having state == 'draft' and kanban_state == 'done'. Currently, the employee contract calendars are synced when incoming contracts are created, and incoming contracts' calendars are changed. However, in many cases the incoming contracts are made for the future and do not reflect the current employee's working schedule. This causes there to be a calendar mismatch whenever incoming contracts are created/updated, despite being set only for the future.

In Odoo, incoming contracts are defined as having state == 'draft' and kanban_state == 'done'.

Currently, the employee contract calendars are synced when incoming contracts are created, and incoming contracts' calendars are changed.

However, in many cases the incoming contracts are made for the future and do not reflect the current employee's working schedule. This causes there to be a calendar mismatch whenever incoming contracts are created/updated, despite being set only for the future.

This fix checks the contracts_count field on the employee before syncing the calendar, since the only time an incoming contract should reflect the *current* calendar is if it's the only contract for the employee.

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

Forward-Port-Of: odoo/odoo#139753
Forward-Port-Of: odoo/odoo#138410

Due to the complication importing different files for version saas-16.4 in internal we decided to be consistent with the other versions and keep only one file payment_form.js instead of checkout_form.js and manage_form.js in stripe. opw-3590564 Forward-Port-Of: odoo/odoo#142292

Due to the complication importing different files for version saas-16.4 in internal we decided to be consistent with the other versions and keep only one file payment_form.js instead of checkout_form.js and manage_form.js in stripe.

opw-3590564

Forward-Port-Of: odoo/odoo#142292

Steps to reproduce: ------------------- - create several product categories on the ecommerce; - do not add products to these categories - go on a category; - go on an other category; Issue: ------ The message is the same for both categories: ``` No product defined in category "First Category". ``` Cause: ------ When we go to the first category, the template is cached according to the existing `t-cache` key containing the products. In this case, we have no products. When we g

Steps to reproduce:
-------------------
- create several product categories on the ecommerce;
- do not add products to these categories
- go on a category;
- go on an other category;

Issue:
------
The message is the same for both categories:
```
No product defined in category "First Category".
```

Cause:
------
When we go to the first category, the template is cached according to the existing `t-cache` key containing the products. In this case, we have no products.

When we go to the second category, which has no products, the current `t-cache` key doesn't detect changes and therefore uses the cached template from the first category.

Solution:
---------
Remove the category name because adding `category` to existing
`t-cache` key to detect a difference between categories
that may have the same t-cache key would add
complexity to the key and have a cost in terms of performance.

opw-3572953

Forward-Port-Of: odoo/odoo#140632

Node `/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` should be filled with the VAT rather than the Peppol Endpoint. Otherwise, a Peppol Bis 3 validator will raise: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’." opw-3589263 Forward-Port-Of:

Node `/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` should be filled with the VAT rather than the Peppol Endpoint.

Otherwise, a Peppol Bis 3 validator will raise:

"[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’."

opw-3589263

Forward-Port-Of: odoo/odoo#142330

Using the OdooEditor, the following use case arises often: - create an Element with document.createElement. - append that node into the DOM tree of an iframe. - spawn a popover with that node as target. The spec (https://developer.mozilla.org/en-US/docs/Web/API/Document/importNode) considers this a malpractice: `Before they can be inserted into the current document, nodes from external documents should either be: cloned using document.importNode(); or adopted using document.adoptNode().

Using the OdooEditor, the following use case arises often:
- create an Element with document.createElement.
- append that node into the DOM tree of an iframe.
- spawn a popover with that node as target.

The spec (https://developer.mozilla.org/en-US/docs/Web/API/Document/importNode) considers this a malpractice: `Before they can be inserted into the current document, nodes from external documents should either be: cloned using document.importNode(); or
adopted using document.adoptNode().

Note: Although Firefox doesn't currently enforce this rule, we encourage you to follow this rule for improved future compatibility.`

Before this commit, in debug mode, there was a crash because the class of the new Element did not match the class of the element's ownerDocument defaultView.

After this commit, we keep the check that says that the target should be an instance of the iframe's document's Element class, but we fallback onto the main Window Element class as well.

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

Before this commit, if the value of an image field is modified by an onchange and the record is saved manually, the old image is displayed. Why: ImageField's rawCacheKey, which is used to know if the image has been updated, is not updated. So we will reuse the old image. Solution: rawCacheKey becomes a getter that always returns the current value of __last_updated. How to reproduce: - Go to a form view with a char field and an image field - Edit the char field - An onchange is perf

Before this commit, if the value of an image field is modified by an onchange and the record is saved manually, the old image is displayed.

Why:
ImageField's rawCacheKey, which is used to know if the image has been updated, is not updated. So we will reuse the old image.

Solution:
rawCacheKey becomes a getter that always returns the current value of __last_updated.

How to reproduce:
- Go to a form view with a char field and an image field
- Edit the char field
- An onchange is performed and modifies the value of the image field
- The new image is displayed
- Click on the save button

Before this commit:
    The old image is displayed

After this commit:
    The new image is displayed

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#142297
Forward-Port-Of: odoo/odoo#141765

Steps: - Open Projects - Go to Tasks - Open Activity view - There is a button to assign a new user Issue: - The button to assign a new user should only be visible on hover Cause: - There was no css class added for button in activity record. Fix: - By making button visibility hidden by default and should be visible only on hover. Task: 3522113 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:

Steps:
 - Open Projects
 - Go to Tasks
 - Open Activity view
 - There is a button to assign a new user

 Issue:
 - The button to assign a new user should only be visible on hover

 Cause:
 - There was no css class added for button in  activity record.

 Fix:
 - By making button visibility hidden by default and should be visible only on hover. Task: 3522113

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

Issue: In a multi-language environment, the product description in sales orders defaults to English, regardless of the user's language preference. This issue occurs when the language of the partner is not set, leading to a mismatch between the user's expected language and the displayed language for product descriptions. Steps to Reproduce: 1. Ensure the database supports multiple languages. 2. Set the user's preferred language to a non-English language. 3. Create a new sale order for a pa

Issue:
In a multi-language environment, the product description in sales orders defaults to English, regardless of the user's language preference. This issue occurs when the language of the partner is not set, leading to a mismatch between the user's expected language and the displayed language for product descriptions.

Steps to Reproduce:
1. Ensure the database supports multiple languages.
2. Set the user's preferred language to a non-English language.
3. Create a new sale order for a partner whose language is not set.
4. Add a product and observe that its description is displayed in English instead of the user's preferred language.

Solution:
Modified the logic to default the product description to the user's language preference when the partner's language is not specified.

opw-3586451

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

Forward-Port-Of: odoo/odoo#141714

**Current behavior before PR:** - Power box uses Patience diff algorithm to check the text added by the user for search, it previously used the entire editable for differences, which caused the issue in collaborative. When one user type something on a different node, the change would affect the editable and be considered in diff, causing updates in other users powerbox. - The Patience diff algorithm now uses the text added in the `closestBlock` node to the node where the powerbox is ope

**Current behavior before PR:**

- Power box uses Patience diff algorithm to check the text added by the user for
search, it previously used the entire editable for differences, which caused
the issue in collaborative. When one user type something on a different node,
the change would affect the editable and be considered in diff, causing updates
in other users powerbox.
- The Patience diff algorithm now uses the text added in the `closestBlock` node to
the node where the powerbox is opened. If the user switched to a different block
using `ArrowLeft` or `ArrowRight` keys, it would result in the algorithm not
searching for the typed text in the other block.

**Desired behavior after PR is merged:**

- Instead of checking the entire editable for the diff, we now check the current
block node where the power box was opened. This prevents scenarios where other
users powerbox would update when one user would type on different block node.
- The powerbox will be closed if the keyup event occurs in a different block than
the one in which the powerbox was initially opened.

task-3212128

Forward-Port-Of: odoo/odoo#127706

pager does not need to be language dependent steps to reproduce: - have a lot of products on your e-commerce (more than 7 pages) - open mobile e-commerce before this commit: - pager is wider than the allowed space and width depends on the language (ex: "Siguiente" is longer than "Next") after this commit: - pager is always smaller and is language independent opw-3522688 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:

pager does not need to be language dependent

steps to reproduce:
- have a lot of products on your e-commerce (more than 7 pages)
- open mobile e-commerce

before this commit:
- pager is wider than the allowed space and width depends on the language (ex: "Siguiente" is longer than "Next")

after this commit:
- pager is always smaller and is language independent

opw-3522688

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

Forward-Port-Of: odoo/odoo#142391
Forward-Port-Of: odoo/odoo#140360

In accordance to the newest version of the UNECE, the term KTM is deprecated and replaced with KMT, which causes issues in the xml files. Reference: https://unece.org/trade/uncefact/cl-recommendations owp-3508745 Forward-Port-Of: odoo/odoo#138104 Forward-Port-Of: odoo/odoo#136741

In accordance to the newest version of the UNECE, the term KTM is deprecated and replaced with KMT, which causes issues in the xml files. Reference: https://unece.org/trade/uncefact/cl-recommendations

owp-3508745

Forward-Port-Of: odoo/odoo#138104
Forward-Port-Of: odoo/odoo#136741

Steps to reproduce: - Install eLearning - Create or go to an existing course. - Add Content - Fill the name and use Save & Close - Click again in the same content we have just created. - Click on website preview. Issue: Saving a record from a form view that is part of an x2many field would only reload the fields present in the list view. This led to incomplete data being loaded into the model. Solution: - Pass the `viewType` option to `_fetchRecord` to ensure that the recor

Steps to reproduce:

- Install eLearning
- Create or go to an existing course.
- Add Content
- Fill the name and use Save & Close
- Click again in the same content we have just created.
- Click on website preview.

Issue:

Saving a record from a form view that is part of an x2many field would
only reload the fields present in the list view. This led to incomplete
data being loaded into the model.

Solution:

- Pass the `viewType` option to `_fetchRecord` to ensure that the record
is reloaded in the context of the form view, thereby including all
fields.
- Add `viewType` to the `saveOptions` in the `basic_relational_model.js`
to ensure the correct view context is used during the save operation.

This ensures that all fields are reloaded into the model, providing a
complete view of the data.

opw-3330010

Forward-Port-Of: odoo/odoo#139346
Forward-Port-Of: odoo/odoo#136068

Was already signed in pallavisrivastavaa.md Forward-Port-Of: odoo/odoo#142343

Was already signed in pallavisrivastavaa.md

Forward-Port-Of: odoo/odoo#142343

When using a 'Group by' on the Accounting Dashboard, the Kanban cards representing the Journals are placed in columns. However, the columns were too narrow, causing text overflow. task-3530756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142221 Forward-Port-Of: odoo/odoo#138496

When using a 'Group by' on the Accounting Dashboard, the Kanban cards representing the Journals are placed in columns. However, the columns were too narrow, causing text overflow.

task-3530756

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

Forward-Port-Of: odoo/odoo#142221
Forward-Port-Of: odoo/odoo#138496

Before commit [1], anchors would not have a duplicate name as checks where in place to prevent it from happening. However, after [1], those checks were no longer valid. They would check in the global variable document, which was no longer the editable document. This commit fixes that by using the ownerDocument of the target, which should always return the correct document. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b Forward-Port-Of: odoo/odoo#139897

Before commit [1], anchors would not have a duplicate name as checks where in place to prevent it from happening. However, after [1], those checks were no longer valid. They would check in the global variable document, which was no longer the editable document.

This commit fixes that by using the ownerDocument of the target, which should always return the correct document.

[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

Forward-Port-Of: odoo/odoo#139897

Similar issue have been fixed for the create in 28a9e90 . This commits fixes the same issue for the write. _steps to reproduce:_ - create a fleet.vehicule with a res.users as driver_id - change value of plan_to_change_car _before this commit:_ access error on res.users _after this commit:_ field value is changed opw-3576960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142376 Forward-Port-Of: odoo/odoo#140

Similar issue have been fixed for the create in 28a9e90 . This commits fixes the same issue for the write.

_steps to reproduce:_
- create a fleet.vehicule with a res.users as driver_id
- change value of plan_to_change_car

_before this commit:_
access error on res.users

_after this commit:_
field value is changed

opw-3576960

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

Forward-Port-Of: odoo/odoo#142376
Forward-Port-Of: odoo/odoo#140956

Suppose a price_unit of 90.0034 and a fiscal position mapping a 10% price included tax to a 15% tax. Since the taxes computation was making a rounding, the computed price_unit was round(90.0034 / 1.10). This commit aims to remove such rounding for the price_unit computation in case of fiscal position. ticket: 3589921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141688

Suppose a price_unit of 90.0034 and a fiscal position mapping a 10% price included tax to a 15% tax.
Since the taxes computation was making a rounding, the computed price_unit was round(90.0034 / 1.10).
This commit aims to remove such rounding for the price_unit computation in case of fiscal position.

ticket: 3589921

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

Forward-Port-Of: odoo/odoo#141688

Some Odoo employees reported a traceback that appeared when saving a task in the Project app. It turned out that this was caused by an image having the class 'o_b64_image_to_save' even though the image was not in Base64 format. Although we couldn't reproduce the bug, we are addressing the result (the traceback) by preventing the saving of an image having the 'o_b64_image_to_save' class if the image is not in Base64. task-3576889 Forward-Port-Of: odoo/odoo#142432 Forward-Port-Of: odoo/odoo#14

Some Odoo employees reported a traceback that appeared when saving a task in the Project app. It turned out that this was caused by an image having the class 'o_b64_image_to_save' even though the image was not in Base64 format. Although we couldn't reproduce the bug, we are addressing the result (the traceback) by preventing the saving of an image having the 'o_b64_image_to_save' class if the image is not in Base64.

task-3576889

Forward-Port-Of: odoo/odoo#142432
Forward-Port-Of: odoo/odoo#140449

Reproduce: - Install `l10n_it_edi_withholding` - Have an invoice with lines with two taxes: . 4% INPS . 0% with exoneration and exoneration kind - Post - Send to Tax Agency - Tax Agency rejects it The Exoneration Kind tag is related to the VAT tax it is applied to, not to the Pension Fund tax itself, so we have to modify the template. A test has been added for the case. Task link: https://www.odoo.com/web#model=project.task&id=3495670 opw-3495670 Forward-Port

Reproduce:

- Install `l10n_it_edi_withholding`
- Have an invoice with lines with two taxes: 
        . 4% INPS 
        . 0% with exoneration and exoneration kind 
- Post
- Send to Tax Agency
- Tax Agency rejects it

The Exoneration Kind tag is related to the VAT tax it is applied to, not to the Pension Fund tax itself, so we have to modify the template.
A test has been added for the case.

Task link: https://www.odoo.com/web#model=project.task&id=3495670
opw-3495670

Forward-Port-Of: odoo/odoo#142398
Forward-Port-Of: odoo/odoo#142235

Since [this commit], the color of the links in the backend is set to the value of the variable `o-cc3-link`. This causes problems... Firstly, this variable is defined in the website module, but it is used in the web_editor module, which does not depend of website. Secondly, this variable declared in website is made to be modified by the website administrator via the edit panel (the theme tab). This commit corrects this by replacing the use of this variable with a hardcoded color. Steps to rep

Since [this commit], the color of the links in the backend is set to the value of the variable `o-cc3-link`. This causes problems... Firstly, this variable is defined in the website module, but it is used in the web_editor module, which does not depend of website. Secondly, this variable declared in website is made to be modified by the website administrator via the edit panel (the theme tab). This commit corrects this by replacing the use of this variable with a hardcoded color.

Steps to reproduce the bug fixed by this commit:
- Have website and project installed
- In the description of a project task, create a link
- Edit a website page
- Go to the theme tab
- Click on Colors Preset
- Open the 3rd preset
- Change the color for "Links" (to red for example)

=> Go back to the project task where you put a link. The link is now red (this may require a page refresh). But the website option should not change the links in the backend.

[this commit]: https://github.com/odoo/odoo/commit/5d598e4269431222ae28ac2196ff6f1f45466734

Enterprise PR: https://github.com/odoo/enterprise/pull/42455

task-3275134

Forward-Port-Of: odoo/odoo#142478
Forward-Port-Of: odoo/odoo#122097

Before this commit, an internal server error was shown when customers tried to tokenize Boleto. opw-3572673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142415

Before this commit, an internal server error was shown when customers
tried to tokenize Boleto.

opw-3572673

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

Forward-Port-Of: odoo/odoo#142415

Just like for `assertQueryCount`, we should not take into account queries that are not run after a warmup, for consistency. This allows to easily interchange both context managers for debugging purpose for instance. Forward-Port-Of: odoo/odoo#142255

Just like for `assertQueryCount`, we should not take into account queries that are not run after a warmup, for consistency. This allows to easily interchange both context managers for debugging purpose for instance.

Forward-Port-Of: odoo/odoo#142255

Add the following account groups: Code Prefix Start | Code Prefix End | Name --------------------------------------------------------------------------- 11 | 11 | Report à nouveau 12 | 12 | Résultat de l'exercice 416 | 416 | Clients douteux 74 | 74 | Subventions d'exploitation opw-3545765 Linked enterprise PR: https://github.com/odoo/enterprise/pull/50745

Add the following account groups:

 Code Prefix Start | Code Prefix End |            Name
---------------------------------------------------------------------------
         11        |        11       | Report à nouveau
         12        |        12       | Résultat de l'exercice
        416        |       416       | Clients douteux
         74        |        74       | Subventions d'exploitation

opw-3545765

Linked enterprise PR: https://github.com/odoo/enterprise/pull/50745


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

Forward-Port-Of: odoo/odoo#142509
Forward-Port-Of: odoo/odoo#142205

Linked enterprise PR: https://github.com/odoo/enterprise/pull/50689 opw-3579253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142494

Linked enterprise PR: https://github.com/odoo/enterprise/pull/50689

opw-3579253


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

Forward-Port-Of: odoo/odoo#142494

Small oversight in https://github.com/odoo/enterprise/pull/41063 caused auto_commit to always be disabled when using an external tax calculation service. opw-3562613 Forward-Port-Of: odoo/enterprise#50975

Small oversight in https://github.com/odoo/enterprise/pull/41063 caused auto_commit to always be disabled when using an external tax calculation service.

opw-3562613

Forward-Port-Of: odoo/enterprise#50975

## Updated fix ### [Context] This commit steams from the alignment issue where the external button link, was located below model selection dropdown, instead of next to it. After contacting studio team, it was found out that this button is not needed. ### [Reproduce Bug] Run odoo 16.3 with installed: web_studio,contacts, next: - Contacts/New: "Toggle Studio" - Drag&Drop many2one field in any place. - Select any model - Observe BUG: "Internal link" button aligned below model dropdown #

## Updated fix
### [Context]
This commit steams from the alignment issue where the external button
link, was located below model selection dropdown, instead of next to it.
After contacting studio team, it was found out that this button is not
needed.
### [Reproduce Bug]
Run odoo 16.3 with installed: web_studio,contacts, next:
- Contacts/New: "Toggle Studio"
- Drag&Drop many2one field in any place.
- Select any model
- Observe BUG: "Internal link" button aligned below model dropdown
### [Fix]
With this commit, the external link button is removed.
I also added test checking for button presence.

![image](https://github.com/odoo/enterprise/assets/33809926/2a6bc5b8-875e-4e0c-8bf8-431c14e4b72f)

## Original problem&fix
> ### [Reproduce Bug]
> Run odoo 16.3 with installed: web_studio,contacts, next:
> - Contacts/New: "Toggle Studio"
> - Drag&Drop many2one field in any place.
> - Select any model
> - Observe BUG: "Internal link" button aligned below model dropdown
> 
> ### [Fix]
> Add display property to .o_field_many2one_selection

opw-3468545

Forward-Port-Of: odoo/enterprise#49385

Since commit a0b24fc, a "Document not found" error could occur in databases using multiple IAP accounts for the `invoice_ocr` service. This only occurred when the update of the status of the extraction was performed through the "Update All Status" cron. It happened because there was a mismatch between the IAP account selected in the cron and the IAP account used when the document was sent. Now, we force the company set in the context to match the one set on the document so that the IAP

Since commit a0b24fc, a "Document not found" error could occur in databases using multiple IAP accounts for the `invoice_ocr` service.

This only occurred when the update of the status of the extraction was performed through the "Update All Status" cron.

It happened because there was a mismatch between the IAP account selected in the cron and the IAP account used when the document was sent.

Now, we force the company set in the context to match the one set on the document so that the IAP accounts selected will always be consistent.

Tickets: 3591259,3592713,3578945,3584204

Forward-Port-Of: odoo/enterprise#50845
Forward-Port-Of: odoo/enterprise#50722