Users can now create or edit milestones directly from tasks linked to sales orders without hitting an error. This keeps billable project workflows smoother by removing a faulty display setting that was not needed in this view.

**Issue:**

When editing or creating a milestone from a task (linked to a sale order) form of a billable project, an error is caught

**Steps to Reproduce:**

 - Enable "Milestones" in Settings > Project.
 - Create a billable project.
 - From Sales, create a sales order using a service product and generate a task in the same project.
 - In the task form, attempt to create and edit a new milestone.

an error is caught due to the use of the widget 'Many2OneUomField'

The fix is about removing the widget as the view has no product field (also the widget might be useless here, as we're only displaying the sale line's UoM )

opw-4852849

Users now see a helpful notification instead of an error screen when clicking the view button on an empty sub-task entry. This makes task management smoother and avoids disruption from a preventable traceback.

Steps to reproduce:

- Open Project go to a task.
- Go to Sub-Tasks sub setting page.
- Don't fill anything click on view.

Issue:

- A trace-back instead of a sticky notification.

Reason:

- Missing notification service initialization.

Fix:

- Add the notification service initialization.

Issue from PR: https://github.com/odoo/odoo/pull/197629

task-4891134

This fixes an upgrade issue in the Belgian disallowed expenses module by updating only accounts that already exist. Businesses upgrading from older versions can now complete the upgrade without errors, while any missing accounts can still be added later by reloading the chart of accounts.

#### Issue
Upgrade `l10n_be_disallowed_expenses` from 18.0 to saas-18.3 fails

In the post-init script of `l10n_be_disallowed_expenses` we try to write the `disallowed_expenses_category_id` field on all the accounts with xmlids in the `data/template/account.account-be.csv` file.

However, some of the referenced accounts (e.g. `a241`) were added in saas-18.1, so they don't exist in 18.0.

#### Fix
Only write on the accounts that exist. The user can reload the CoA to create any accounts that don't exist yet if needed.

task-none

VoIP error messages now show formatted line breaks instead of displaying HTML tags as plain text. This makes error screens clearer and easier for users to read when something goes wrong during calls.

`<br>` tags in VoIP error messages are rendered as text. This is because the code uses t-esc instead of t-out, and t-esc never renders inner HTML.

This commit just replace t-esc with the proper t-out directive.

|Before|After|
|-|-|
|![image](https://github.com/user-attachments/assets/d23d1d6a-952b-49c1-b59f-3565459ddde6)|![image](https://github.com/user-attachments/assets/cadbcdeb-b62d-4ad3-8650-69e6683f308f)|

Users can now dismiss non-critical VoIP error messages by clicking on them as intended. This prevents minor softphone warnings from lingering on screen and disrupting normal work.

UI-wise, there are two types of VoIP errors: blocking and non-blocking. Blocking errors are unrecoverable, they're displayed at the top of the UI and prevent further use of the softphone. Non-blocking errors, on the other hand, can be dismissed by a simple click on the error screen.

Problem: the handler that hides the error screen in case of non-blocking errors wasn't attached to anything, and even if it was, its implementation was wrong! This commit makes it work as intended.

Part of [task-4891947](https://www.odoo.com/odoo/project/5778/tasks/4891947).

Spreadsheet users can no longer save a global filter without a label. This restores the expected validation behavior and helps prevent unclear or confusing filters in spreadsheets.

Since 5f001cbf0ea5e382f00602e3307ffd1fc2eb5bf1, it was possible to save a global filter with an empty label, which is not intended. This commit restore the previous behavior by preventing the saving of a global filter with an empty label.

Task: 4876003

This update adjusts an internal performance test after a related employee module change added one expected database query. It keeps automated checks accurate so teams can continue monitoring appointment performance reliably.

With the related Community PR [1], we made changes to the `hr.employee` module,
 which resulted in an increase of one additional query.

This commit adds the corresponding query count update to ensure test accuracy
and maintain performance visibility.

[1] - https://github.com/odoo/odoo/pull/210037

sentry-6600672947

Before this commit, peer offer filtering was not working as the reference to the store was incorrect. This wouldn't cause tracebacks or known connection issues as the error was caught and the filter was just ignored. Forward-Port-Of: odoo/odoo#215438 Forward-Port-Of: odoo/odoo#215349

Before this commit, peer offer filtering was not working as the reference to the store was incorrect.

This wouldn't cause tracebacks or known connection issues as the error was caught and the filter was just ignored.

Forward-Port-Of: odoo/odoo#215438
Forward-Port-Of: odoo/odoo#215349

The Italian Law requires cash payments to be rounded up to 5 cents (art. 13 del D.Lgs. 231/2007, updated in 2018). The exported XML invoice didn't have any cash rounding lines and so the sum was wrong in ImportoTotaleDocumento. This was happening because cash rounding lines (`display_type == 'rounding'`) were excluded during the export function's computation. This fix makes the function include `rounding` lines into the computation, making the invoice compliant. Steps: 1. Activate cash ro

The Italian Law requires cash payments to be rounded up to 5 cents (art. 13 del D.Lgs. 231/2007, updated in 2018). The exported XML invoice didn't have any cash rounding lines and so the sum was wrong in ImportoTotaleDocumento. This was happening because cash rounding lines (`display_type == 'rounding'`) were excluded during the export function's computation.

This fix makes the function include `rounding` lines into the computation, making the invoice compliant.

Steps:
1. Activate cash rounding management.
2. Create a `0.05E` cash rounding.
3. Create an invoice with a total that is not rounded.
4. Set up the cash rounding on the invoice:
      Other information > Cash rounding method
   An invoice cash rounding line will be created, the total will be rounded.
5. Generate the XML and download it.
6. The amount in `ImportoTotaleDocumento` tag will not match the total of the invoice.  


Task [link](https://www.odoo.com/odoo/project/967/tasks/4816355)
task-4816355

Forward-Port-Of: odoo/odoo#213337

**Issue** Duplicated Profit and Loss reports fail to open and raise an "invalid operation" error when accessed. **Steps to Reproduce** 1. Install the Accounting module and French localization. 2. Go to Accounting > Configuration > Accounting > Accounting Reports. 3. Duplicate the "Profit and Loss (2024)" report. 4. Navigate to Accounting > Reporting > Profit and Loss. 5. Attempt to open the duplicated report. 6. An error occurs. **Root Cause** During duplication, the label field of

**Issue**
Duplicated Profit and Loss reports fail to open and raise an "invalid operation" error when accessed.

**Steps to Reproduce**
1. Install the Accounting module and French localization.
2. Go to Accounting > Configuration > Accounting > Accounting Reports.
3. Duplicate the "Profit and Loss (2024)" report.
4. Navigate to Accounting > Reporting > Profit and Loss.
5. Attempt to open the duplicated report.
6. An error occurs.

**Root Cause**
During duplication, the label field of expressions is altered to include a " (copy)" suffix. Some formula expressions rely on exact label matches (e.g., i_1_2024.balance), so when "balance" becomes "balance (copy)", the lookup fails. This mismatch causes a KeyError when resolving subformulas like line_code.balance, breaking the report evaluation.

**Fix**
Prevent the duplication process from altering the label of expressions. There is no functional need to add " (copy)" to these internal labels, as they are not user-facing and must remain stable for formula resolution to work.

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

Forward-Port-Of: odoo/odoo#212777

**Current behavior** Having multiple employees on a workorder with overlapping work intervals will result in an inaccurate valuation value. **Expected behavior:** Accurate valuation. **Steps to reproduce:** 1. Create a BOM with an operation (workorder) for a finished product which is valuated 2. Create an MO for that BOM, assign multiple employees on the workorder with various (overlapping) working intervals 3. Process the MO -> look at the valuation generated -> its value is

**Current behavior**
Having multiple employees on a workorder with overlapping work
intervals will result in an inaccurate valuation value.

**Expected behavior:**
Accurate valuation.

**Steps to reproduce:**
1. Create a BOM with an operation (workorder) for a finished
product which is valuated

2. Create an MO for that BOM, assign multiple employees on the
workorder with various (overlapping) working intervals

3. Process the MO -> look at the valuation generated -> its
value is too high (because it counted the overlapping work
intervals)

**Cause of the issue**
A workorder's resource intervals are currently just naively
summed.

**Fix**
Use the `Intervals` class to find the union of all resources in
a workorder.

opw-4430375

Forward-Port-Of: odoo/odoo#213850
Forward-Port-Of: odoo/odoo#205154

## Commit 1 [FIX] point_of_sale, pos_sale: fix product loading in POS Before this commit, when loading additional products after the initial load, the PoS were not receiving all necessary data related to the products, for example product's precomputed taxes objects. This commit add a method which will load all necessary data for the products when loading them in the PoS. What's more, when a product was loaded via barcode, it didn't yet have its associated pricelists, as these were

## Commit 1
[FIX] point_of_sale, pos_sale: fix product loading in POS

Before this commit, when loading additional products after the initial
load, the PoS were not receiving all necessary data related to the
products, for example product's precomputed taxes objects.

This commit add a method which will load all necessary data for the
products when loading them in the PoS.

What's more, when a product was loaded via barcode, it didn't yet have
its associated pricelists, as these were loaded in another RPC. This
commit unifies data reception via a single RPC.

Loyalty cards are not longer loaded at the beginning of the PoS since
they are loaded each time a partner is selected. Loyalty cards doesn't
works with offline mode anyway since some backend check must be done
before validating them.

Some debug information about loading times and records is now printed
in the console when the PoS is started in debug mode.

IndexedDB method is now debounced to avoid calling it too often when the
PoS is started. The create method is also batched to avoid putting large
amount of data in IndexedDB at once.

Loaded data includes:
- `product.product`
- `product.template`
- `product.combo`
- `product.combo.item`
- `product.uom`
- `product.pricelist`
- `product.pricelist.item`
- `product.template.attribute.value`
- `product.template.attribute.line`
- `account.tax`

## Commit 2

[PERF] point_of_sale: pricelist computations
Before this commit, when we were trying to compute pricelist item for
a product, we were iterating over all pricelist items of the pricelist
and checking if the product was in the item or if the item didn't
have any product set. This was very inefficient, especially when
there were many pricelist items and products.

This commit add a pre-computation of pricelist items for general rules
which eliminates the need to calculate rules on the fly.

Forward-Port-Of: odoo/odoo#214371

**Current behavior before PR:** - When a list contains content separated by **Shift+Enter** toggling the list would break these lines and create a separate base container for each segment separated by `<br>`. **Desired behavior after PR is merged:** - Only a single base container is created when toggling a list that contains **Shift+Enter** contents. task:4854372 Forward-Port-Of: odoo/odoo#214908 Forward-Port-Of: odoo/odoo#213546

**Current behavior before PR:**

- When a list contains content separated by **Shift+Enter** toggling the list would break these lines and create a separate base container for each segment separated by `<br>`.

**Desired behavior after PR is merged:**

- Only a single base container is created when toggling a list that contains **Shift+Enter** contents.

task:4854372

Forward-Port-Of: odoo/odoo#214908
Forward-Port-Of: odoo/odoo#213546

fix in version-18.0 Forward-Port-Of: odoo/odoo#215374

fix in version-18.0

Forward-Port-Of: odoo/odoo#215374

Before this commit, the logo and QR code images on receipts printed via the IoT printer did not appear. Now, the htmlToCanvas conversion waits until these images are fully loaded before proceeding. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214331

Before this commit, the logo and QR code images on receipts printed via the IoT printer did not appear. Now, the htmlToCanvas conversion waits until these images are fully loaded before proceeding.


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

Forward-Port-Of: odoo/odoo#214331

Versions -------- - saas-18.2 - saas-18.3 Fix on master in FW. Steps ----- 1. Add 1 item to your wishlist; 2. go to wishlist; 3. add item to cart. Issue ----- You don't get redirected to the cart. Cause ----- Commit c0f411cc7cf17 fixed an issue where products were removed from the wishlist before they were added to the cart via the product configurator by not passing a deferred redirect to `_removeWish`. An unintended side-effect is that the user no longer gets redirected

Versions
--------
- saas-18.2
- saas-18.3

Fix on master in FW.

Steps
-----
1. Add 1 item to your wishlist;
2. go to wishlist;
3. add item to cart.

Issue
-----
You don't get redirected to the cart.

Cause
-----
Commit c0f411cc7cf17 fixed an issue where products were removed from the wishlist before they were added to the cart via the product configurator by not passing a deferred redirect to `_removeWish`. An unintended side-effect is that the user no longer gets redirected when the wishlist is empty.

Solution
--------
After calling `_removeWish`, check if the wishlist is empty, and if so, call `_redirectNoWish` to restore previous behavior.

runbot-227042

Forward-Port-Of: odoo/odoo#215385

See odoo/odoo#214960 (master) The PR mentioned above adds fixes to connect to a DB that is part of a multi-DB instance. This includes saving a new configuration key, `db_name`, to keep track of the current database name. This commit backports just this functionality, making older versions compatible with the new pairing token that includes to DB name. This prevents a potential traceback if using this new token format. task-4815521 --- I confirm I have signed the CLA and read the PR

See odoo/odoo#214960 (master)

The PR mentioned above adds fixes to connect to a DB that is part of a multi-DB instance. This includes saving a new configuration key, `db_name`, to keep track of the current database name.

This commit backports just this functionality, making older versions compatible with the new pairing token that includes to DB name. This prevents a potential traceback if using this new token format.

task-4815521

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

Forward-Port-Of: odoo/odoo#215286
Forward-Port-Of: odoo/odoo#215243

Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title) With this change will show "% IVA" when printing in Spanish ### Description of the issue/feature this PR addresses: Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report 1. Install Argentinean - Accounting module 2. Install Spanish language 3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscr

Before this change, the column % VAT in Argentinean Legal PDF translation to Spanish was not working (Was always showing "% VAT" column title)

With this change will show "% IVA" when printing in Spanish

### Description of the issue/feature this PR addresses:

Bad Spanish translation on the Column % VAT in the Argentinean Legal PDF Report

1. Install Argentinean - Accounting module
2. Install Spanish language
3. Log into to one of the demo Argentinean Companys : (AR) Responsable Inscripto
4. Go to the Cutomer invoices menu and select any of the invoices already created in demo data
5. Go to the partner and change the Languaje to Spanish
6. Return to the invoice and print the PDF

### Current behavior before PR:

All the other terms are translated, but not the % VAT column
![image](https://github.com/user-attachments/assets/ba727710-5b15-45ed-83b6-fd285cf37697)

### Desired behavior after PR is merged:

All the terms are correctly translated
![image](https://github.com/user-attachments/assets/233ab5de-f00f-43df-aa24-3517f40cd5c7)


References LATM 1343 | ADHOC 50766
 
---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

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

Forward-Port-Of: odoo/odoo#214143
Forward-Port-Of: odoo/odoo#213501

Calling external resources can lead to random failures in tests test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect. Fixes the test by not following the 301 and checking the target instead. Forward-Port-Of: odoo/odoo#215232 Forward-Port-Of: odoo/odoo#215175

Calling external resources can lead to random failures in tests

test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect.

Fixes the test by not following the 301 and checking the target instead.

Forward-Port-Of: odoo/odoo#215232
Forward-Port-Of: odoo/odoo#215175

For general invoicing purposes, VAT of Taiwan is rounded per invoice level, not per invoice. Also, they do not separately compute the tax amount per each line to generate the final totals. They use total sales amount * tax. task - 4875546 Forward-Port-Of: odoo/odoo#215149 Forward-Port-Of: odoo/odoo#214698

For general invoicing purposes, VAT of Taiwan is rounded per invoice level, not 
per invoice. Also, they do not separately compute the tax amount per each line 
to generate the final totals. They use total sales amount * tax.

task - 4875546

Forward-Port-Of: odoo/odoo#215149
Forward-Port-Of: odoo/odoo#214698

Steps to reproduce - open a record from Contacts app - from chatter, click `send mail` , open full mail composer - add a attachment - schedule a message, by clicking '▼' on send message - Again from chatter, click on edit the same message - try to add another attachment Observation: A traceback is received Issue: Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static

Steps to reproduce
- open a record from Contacts app
- from chatter, click `send mail` , open full mail composer
- add a attachment
- schedule a message, by clicking '▼' on send message
- Again from chatter, click on edit the same message
- try to add another attachment

Observation:
A traceback is received

Issue:
Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static/src/core/web/mail_composer_attachment_selector.js#L25-L30

but in case message is scheduled, which is stored in `mail.scheduled.message` ,when editing it we do not have `res_ids` 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/wizard/mail_compose_message.py#L120

instead we have `res_id` field, 
https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/models/mail_scheduled_message.py#L46
hence a traceback is received when trying to json parse a `undefined` value.

Fix:
Adapt the `onFileUploaded` function to consider both, `res_ids` and `res_id`

opw-4839926


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

Forward-Port-Of: odoo/odoo#212960

Before this commit: - If pos_restaurant is not installed, then placing an order as 'Mark As Ready' in food delivery will lead to a traceback in retail POS. Following this commit: - Overridden method is moved to point_of_sale from pos_restaurant task-4889905 Forward-Port-Of: odoo/odoo#215375

Before this commit:
- If pos_restaurant is not installed, then placing an order as 'Mark As Ready' in food delivery will lead to a traceback in retail POS.

Following this commit:
- Overridden method is moved to point_of_sale from pos_restaurant

task-4889905

Forward-Port-Of: odoo/odoo#215375

When generating a credit note for an invoice with multiple lines of the same product (same product_id, name, and price_unit) but different discounts, the system incorrectly matches both credit note lines to the same invoice line. This commit solves this issue by adding line discount to the criteria used to match credit notes lines with invoices lines. task-4876849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo

When generating a credit note for an invoice with multiple lines of the same product
(same product_id, name, and price_unit) but different discounts,
the system incorrectly matches both credit note lines to the same invoice line.
This commit solves this issue by adding line discount to
the criteria used to match credit notes lines with invoices lines.

task-4876849




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

Forward-Port-Of: odoo/odoo#214779

Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click `Find Duplicate Transactions`. - Clear the `Starting Date` field and click save. `TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'` This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transa

Currently, an error occurs when finding duplicate transactions in the bank.

Steps to Reproduce:

 - Install the `accountant` module.
 - In `Accounting Dashboard`, click on `Bank`.
 - In Actions, click `Find Duplicate Transactions`.
 - Clear the `Starting Date` field and click save.

`TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'`

This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transactions, it tries to calculate the `prior_date` using `date_from - relativedelta(months=3)` [1]. However, since `date_from` is `False`, this raises an error.

[1] https://github.com/odoo/enterprise/blob/acdba5ecf89ee8920f82e07e16fac2a0f9659b12/account_online_synchronization/models/account_journal.py#L314

This commit ensures that if the Starting Date is empty when finding duplicate transactions, it uses today’s date as the Starting Date.

sentry-6653835511

Forward-Port-Of: odoo/enterprise#87000

Steps to reproduce: - Open Follow-up levels for 15 days -Check the option for “Automatic” - Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration. - Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic. - There will appear a red ribbon on the right corner that says “In need of action” - In another tab, open sch

Steps to reproduce:
- Open Follow-up levels for 15 days -Check the option for “Automatic”
- Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration.
- Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic.
- There will appear a red ribbon on the right corner that says “In need of action”
- In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup”
- Run this action manually

Issue:
Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address

Note:
This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses.

Cause:
When running the cron, the recipients aren't in the options

Solution:
Add an helper to find all necessary recipients from the template if no recipient ids in the options

opw-4527398

Forward-Port-Of: odoo/enterprise#87014
Forward-Port-Of: odoo/enterprise#83944

Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remain

Bug:
1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top.

2. Casual loading rate applies to Overtime hours.

Steps to reproduce:
1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week.
2. The created payslip is of correct amount with the standard 40-hours work week.
3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts.

Current behavior:
The total remains 2000 and the computed hourly rate becomes 2000/44=45.45

Expected behavior:
The hourly rate should remain the same 50.
The total should increase to be:
fixed_wage + hourly_rate * overtime hours
2000 + 50 * 4 = 2200

Fix:
1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate.

2.The casual loading rate should not apply to Overtime work entry types.

task-4617681

Forward-Port-Of: odoo/enterprise#83171

## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/213223 Forward-Port-Of: odoo/enterpris

## Pull Request HOOT (PRHOOT) 33

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

Community: https://github.com/odoo/odoo/pull/213223

Forward-Port-Of: odoo/enterprise#88211
Forward-Port-Of: odoo/enterprise#87476

After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are

After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different.

To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are checking.

runbot-115003

Forward-Port-Of: odoo/enterprise#87981
Forward-Port-Of: odoo/enterprise#81643

To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== r

To reproduce:
=============
- install documents_project
- create project
- go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload)
- open the share link in a new browser window and connect as portal user
- upload a document -> access error

Problem:
========
while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project

Solution:
========
read as `sudo`

opw-4782062

Forward-Port-Of: odoo/enterprise#87782
Forward-Port-Of: odoo/enterprise#87301

In this PR: ========== - We are improving the mobile view to make online orders more consistent and seamless. task-4585233 Forward-Port-Of: odoo/enterprise#88166 Forward-Port-Of: odoo/enterprise#80838

In this PR:
==========
- We are improving the mobile view to make online orders more consistent and seamless.

task-4585233

Forward-Port-Of: odoo/enterprise#88166
Forward-Port-Of: odoo/enterprise#80838

Before, a fix was done to round column for materials and payments columns but the method was HALF-UP. This should always be DOWN as specified here https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28 task-4881298 Forward-Port-Of: odoo/enterprise#88018

Before, a fix was done to round column for materials and payments columns but the method was HALF-UP.

This should always be DOWN as specified here
https://assets.publishing.service.gov.uk/media/5d53df0040f0b6098ead46c2/cis-qsbvr-v2.2.pdf page 28

task-4881298

Forward-Port-Of: odoo/enterprise#88018

Task: 4610586 If an operator is added in the side panel of Shop Floor, and an MO has multiple work orders, then after marking all of the steps as done, the selected user is assigned to all of them except the final one. This commit fixes the error, assigning the selected operator to all completed work orders. Forward-Port-Of: odoo/enterprise#84790

Task: 4610586

If an operator is added in the side panel of Shop Floor, and an MO has
multiple work orders, then after marking all of the steps as done, the
selected user is assigned to all of them except the final one.

This commit fixes the error, assigning the selected operator to all
completed work orders.

Forward-Port-Of: odoo/enterprise#84790

Test coverage for community-side diff about calculating a workcenter's cost in a way that omits counting duration within a working interval that was previously counted. opw-4430375 Forward-Port-Of: odoo/enterprise#87449 Forward-Port-Of: odoo/enterprise#81701

Test coverage for community-side diff about calculating a
workcenter's cost in a way that omits counting duration within a
working interval that was previously counted.

opw-4430375

Forward-Port-Of: odoo/enterprise#87449
Forward-Port-Of: odoo/enterprise#81701

**Current behavior:** A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields). **Expected behavior:** Can add rows to the MPS. **Steps to reproduce:** 1. Install `mrp_mps` with demo data 2. Edit "Demo" user access rights so they only have the mrp manager group 3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error **Cause of the issue:** Field is on `ResCompany` and the MPS us

**Current behavior:**
A user who can otherwise use the entire mps can not add 'rows' to the view (i.e., write on `ResCompany` `mrp_mps` fields).

**Expected behavior:**
Can add rows to the MPS.

**Steps to reproduce:**
1. Install `mrp_mps` with demo data

2. Edit "Demo" user access rights so they only have the mrp manager group

3. Open MPS -> click `Rows` dropdown (under search bar) and add/remove one -> access error

**Cause of the issue:**
Field is on `ResCompany` and the MPS user can't write to that model.

**Fix:**
Permit writes on `ResCompany` `mrp_mps` fields if they are on an mps field and the user has the mrp manager group.

opw-4591655

Forward-Port-Of: odoo/enterprise#87765
Forward-Port-Of: odoo/enterprise#80881

Removed the module as it was removed in fe442111dc22b5d0bb9717ff69a5f473e1e81d50, and mistakenly resurrected in 65ed1bddbb2d032f74ef84afc9add85a1503dec5 Forward-Port-Of: odoo/enterprise#87742

Removed the module as it was removed in fe442111dc22b5d0bb9717ff69a5f473e1e81d50, and mistakenly resurrected in 65ed1bddbb2d032f74ef84afc9add85a1503dec5

Forward-Port-Of: odoo/enterprise#87742

Before, The closing balance of saft export for the unaffected earnings account was always at zero which makes no sense. Now this is fixed as the closing balance should always be equal to the initial balance. Forward-Port-Of: odoo/enterprise#88096 Forward-Port-Of: odoo/enterprise#87419

Before, The closing balance of saft export for the unaffected earnings account was always at zero which makes no sense.

Now this is fixed as the closing balance should always be equal to the initial balance.

Forward-Port-Of: odoo/enterprise#88096
Forward-Port-Of: odoo/enterprise#87419

Issue / current behavior: In the gantt view of hr.attendance, the no content help screen will only show if there's no rows. In the case of a fresh database with only the Administrator employee, the help will not appear because the admin row exists by default. Required behavior: The gantt view should show the no content help screen if recordIds inside the single row is empty, meaning that there's no hr.attendance records. task-4874129 Forward-Port-Of: odoo/enterprise#87874

Issue / current behavior:
In the gantt view of hr.attendance, the no content help screen will only show if there's no rows. In the case of a fresh database with only the Administrator employee, the help will not appear because the admin row exists by default.

Required behavior:
The gantt view should show the no content help screen if recordIds inside the single row is empty, meaning that there's no hr.attendance records.

task-4874129

Forward-Port-Of: odoo/enterprise#87874

### Steps to reproduce: - Create 2 storable products: Product A, Product B - Create a control point pass/fail control by quantity on receipt and set both products on it. - Create and confirm a receipt with 2 moves: - 2 x Product A - 2 x Product B - Click on the "Quality Check" button and mark one unit of Product A as failed. > This should open the QC for product B. - Close the QC for prodcut B wihtout setting it as failed or passed. - Click on the "Quality Check" button ####

### Steps to reproduce:

- Create 2 storable products: Product A, Product B
- Create a control point pass/fail control by quantity on receipt and set both products on it.
- Create and confirm a receipt with 2 moves:
    - 2 x Product A
    - 2 x Product B
- Click on the "Quality Check" button and mark one unit of Product A as failed.
> This should open the QC for product B.
- Close the QC for prodcut B wihtout setting it as failed or passed.
- Click on the "Quality Check" button
#### > Nothing happends

### Expected behavior:

The QC for product B should open.

### Cause of the issue:

When the quality check is marked as failed, the related move is picked: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/quality.py#L438-L451 However, the move for your second porduct is not and hence, its product is not considered to be checkable by the `check_quality` action: https://github.com/odoo/enterprise/blob/679c81924e05e7544eecfdb960c9ed9611e9cdd5/quality_control/models/stock_picking.py#L61-L69
Since these lines were added in c83728f3a7f1504b272f4ef97e4187868338adb3 to not bypass the QC of the unpicked move at validation we should probably only add that filtering condition in that case and continue to consider the unchecked moves as checkable prior to validation.

opw-4765075

Forward-Port-Of: odoo/enterprise#84743

### Issue: Steps to reproduce: - In the settings enable packagings - Create a storable product P with Units as uom and a barcode - Inventory > Configuration > Product > Units & Packagings - Click on pack of 6 > Packaging Barcodes > New - Create one for your product with a different barcode - Go to barcode > Inventory count #### Issue 1: - Scan your packaging > It create a line for 1 Pack of 6 - Apply #### > If you check on the product form you have 1 on Hand unit #### Issue 2

### Issue:

Steps to reproduce:
- In the settings enable packagings
- Create a storable product P with Units as uom and a barcode
- Inventory > Configuration > Product > Units & Packagings
- Click on pack of 6 > Packaging Barcodes > New
- Create one for your product with a different barcode
- Go to barcode > Inventory count

#### Issue 1:

- Scan your packaging > It create a line for 1 Pack of 6
- Apply
#### > If you check on the product form you have 1 on Hand unit

#### Issue 2:

- Scan your packaging > It create a line for 1 Pack of 6
- Scan your product > Nothing happens rather than adding one unit

#### Issue 3:

- Scan your product > It create a line for 1 Unit
- Scan your packaging > Nothing happends rather than adding 6 units

### Cause of the issue:

The issue 1 is the most problematic as it introduce corrupted data. The issue has been introduced by Commit 188ad6980222a77168c462cf149cb79bf28ca2e6 where packagings have been merged with uoms. Prior to this commit, scanning a packaging would convert the barcodeData to to be expressed in the uom of the product:
https://github.com/odoo/enterprise/commit/188ad6980222a77168c462cf149cb79bf28ca2e6 The commit came with the additional feature of creating lines refering dirrectly to the packaging, for instance scanning a pack of 6 would create one line: 1 pack of 6. While this behavior make sense in the context of pickings since stock moves can bear different uoms than the product it self, it does not in the context of stock.quant's since the uom of the quant is necessarily the one of the product: https://github.com/odoo/odoo/blob/9f8e9ca2676f5e3ccc34522d444d1f02e2d21f92/addons/stock/models/stock_quant.py#L53-L55 
Now, the issue is that in inventory counts you edit quants via the barcode lines. When the barcode changes are applied in db, we provide the data's to write or create via these lines:
https://github.com/odoo/enterprise/blob/38e0ae75c2cfddfe76535847ff8b67823b0c6419/stock_barcode/static/src/models/barcode_model.js#L920-L928
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/static/src/models/barcode_quant_model.js#L307-L320
which can not provide to the backend the packaging uom in order to convert the related quantities (as it is not a quant field).
In particular, the Command.create and Command.update are simply populated expecting these qties to be expressed in the product_uom.

### Fix:

Converting the barcodeData's quantity in case a packaging is provided will solve all issues since all the save commands will be expressed in the expected uom and since the barcode machinery is already tailored to treat the addition of appropriate qties.

opw-4872894

Forward-Port-Of: odoo/enterprise#87999

The size of fields for Previous Payroll IDs was set to 20 characters. According to the STP xml schema, the max size is 200. This is already checked with the schema validation so the limit can be safely removed. This commit also adds a disclaimer for the users informing them regarding STP compliance. opw-4820852 Forward-Port-Of: odoo/enterprise#88248 Forward-Port-Of: odoo/enterprise#87068

The size of fields for Previous Payroll IDs was set to 20 characters. According to the STP xml schema, the max size is 200. This is already checked with the schema validation so the limit can be safely removed.

This commit also adds a disclaimer for the users informing them regarding STP compliance.

opw-4820852

Forward-Port-Of: odoo/enterprise#88248
Forward-Port-Of: odoo/enterprise#87068

Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550 Forward-Port-Of: odoo/enterprise#87356 Forward-Port-Of: odoo/enterprise#86870

Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice.

taskid: 4841550

Forward-Port-Of: odoo/enterprise#87356
Forward-Port-Of: odoo/enterprise#86870

When we enable the integer rounding option on this report, a traceback is raised at the report opening. It happens because integer rounding didn't support a groupby when a custom engine is used. opw-4688616 Forward-Port-Of: odoo/enterprise#87618 Forward-Port-Of: odoo/enterprise#86452

When we enable the integer rounding option on this report, a traceback is raised at the report opening. It happens because integer rounding didn't support a groupby when a custom engine is used.

opw-4688616

Forward-Port-Of: odoo/enterprise#87618
Forward-Port-Of: odoo/enterprise#86452