Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71216

Steps to reproduce the bug:
- Create a storable product “P1”:
   - UoM: Unit

- Create a transfer for one dozen of P1:
   - Mark it as "To Do"

- Go to the MPS:
   - Add the product “P1”
   - In the filter, add “Actual Demand”

Problem:
The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1.

opw-4199710

Forward-Port-Of: odoo/enterprise#71216

Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1. After this PR, overseas transactions with GST will no longer be shown in the spreadsheet. **Technical Reason:-** In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of t

Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1.

After this PR, overseas transactions with GST will no longer be shown in the spreadsheet.

**Technical Reason:-**
In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of those involving CGST and SGST, as these are not relevant for overseas transactions.

**Task**-4008149

Forward-Port-Of: odoo/enterprise#65280

Before this commit: In a recent commit to allow sendcloud to generate labels without having to fetch rates. When the returned value for field `price` is `None` it was set as `0.0` with datatype `float` when it should be `str`. After this commit: Added a check when setting price to make sure correct datatype is set. opw-4222636 Forward-Port-Of: odoo/enterprise#71367

Before this commit:

In a recent commit to allow sendcloud to generate labels without having to fetch rates. When the returned value for field `price` is `None` it was set as `0.0` with datatype `float` when it should be `str`.

After this commit:

Added a check when setting price to make sure correct datatype is set.

opw-4222636

Forward-Port-Of: odoo/enterprise#71367

The search functionality in the Recurring Plan view was not working when users entered text. While custom filters worked, the search field failed to respond to user input because no fields were defined in the search view. OPW-4116088 Forward-Port-Of: odoo/enterprise#70464

The search functionality in the Recurring Plan view was not working when users entered text. While custom filters worked, the search field failed to respond to user input because no fields were defined in the search view.

OPW-4116088

Forward-Port-Of: odoo/enterprise#70464

Add context key to be able to redefine the date used to select which subscription lines are invoiceable. This allows to generate invoices before the date of next invoice set on the subscription with the help of custom module. Forward-Port-Of: odoo/enterprise#70053

Add context key to be able to redefine the date used to select
which subscription lines are invoiceable.

This allows to generate invoices before the date of next invoice
set on the subscription with the help of custom module.

Forward-Port-Of: odoo/enterprise#70053

**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments) - Create a vendor with a special character in the name (e.g. a curly apostrophe `’`) - Configure a bank account for the vendor - Create a bill for that vendor - Confirm the bill - Register a payment with "A

**Steps to reproduce:**
- Install l10n_au_aba
- Switch to an Australian company (e.g. AU Company)
- Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments)
- Create a vendor with a special character in the name (e.g. a curly apostrophe `’`)
- Configure a bank account for the vendor
- Create a bill for that vendor
- Confirm the bill
- Register a payment with "ABA Credit Transfer" as payment method
- Go to the payments list
- Select the created payment and create a batch payment
- Validate it
- Download the generated ABA file
- Try to validate the file on an online [ABA validator](https://www.bcu.com.au/business-banking/payments/internet-banking/aba-file-validator/)

**Issue:**
The online ABA file validator finds an error because the accepted length for a row is not respected.

**Cause:**
Each row information is encoded with a specific number of characters where blank characters are added to reach that length. In this case, the name of the account holder is containing a special character that corresponds to 3 characters when converted to utf8 and too many blank characters are added.

**Solution:**
Compute the length in utf8 before adding the blank characters.

opw-4059837

Forward-Port-Of: odoo/enterprise#71351

Problem: Once we set the product ID in `WebsiteSaleDaterangePicker`, it doesn't get updated if it has a truthy value. However, it should update because a different variant (product ID) can be selected. Steps to reproduce: - Install a database with website, eCommerce, and Rental (ensure the "website_sale_stock_renting" module is installed). - Create a product that can be rented with 3 variants. - Add a daily rate of your choice. - In the Sales tab, untick the option "Continue selling if

Problem:
Once we set the product ID in `WebsiteSaleDaterangePicker`, it doesn't get updated if it has a truthy value. However, it should update because a different variant (product ID) can be selected.

Steps to reproduce:

- Install a database with website, eCommerce, and Rental (ensure the "website_sale_stock_renting" module is installed).
- Create a product that can be rented with 3 variants.
- Add a daily rate of your choice.
- In the Sales tab, untick the option "Continue selling if out-of-stock."
- Restock 1 quantity of each variant and publish the product on the website.
- From the shop, rent the product with variant size S for one week.
- Return to the shop and select another variant (M or L). The calendar will incorrectly show the rental days in red, as if M & L are also already rented. However, they can still be rented.

opw-4115519

Forward-Port-Of: odoo/enterprise#68832

On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-

On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration.

This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line.

In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New.

This commit fixes the issue by adding a sudo at the right place.

Source: post-Odoo.com migration feedback

Forward-Port-Of: odoo/odoo#176222

Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142

Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one.

Task id # 3758343

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

Forward-Port-Of: odoo/odoo#177142

Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177137

Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one.

Task id # 4122312

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

Forward-Port-Of: odoo/odoo#177137

Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913

Currently we always try to add a string informing about the used
declaration of intent to the invoice / sale order PDF.
I.e. it also happens when no declaration of intent is selected.

After this commit the string is only added in case there is
actually a declaration of intent selected.

opw-4237368

Forward-Port-Of: odoo/odoo#182913

This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was use

This commit fixes an issue that requires a very specific scenario to be reproduced:

Go to Settings > Technical > Server Actions
Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field
Save the dialog and save the record.

Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was used in the dialog. When the record was saved, it was also reloaded (via web_save), and the `update_related_model_id` field was unset (the business logic unsets it, I don't know why). This field being the `modelField` for the reference field (`resource_ref`), the latter was unset by the ReferenceField (via useRecordObserver), which called record.update. This produced an update command on a record that had been saved meanwhile but was still referenced as a new record (hence the virtual_id).

This commit fixes the issue by not reloading the record with web_save, as we're closing the dialog anyway, and that record is loaded for the x2many list view anyway. Moreover, we also ensure that if an update occurs on a record that was initially new but that has been saved meanwhile, the command is associated with the correct resId, not the virtualId.

Closes #178541

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

Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead.

Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all.

This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead.

Steps to reproduce:
- Install Website
- Drop a Popup inside the homepage
- Switch user to Spanish
- Edit the popup

=> The "Ocultar para" option did not display its value because "días" contains an accent.

- Switch user to Japanese
- Edit the popup

=> The "次のものに非表示" option did not display its value because "日" is not an alphabet letter.

opw-4200520

Forward-Port-Of: odoo/odoo#182637

Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have

Steps to reproduce:
- Project > New Task > Set 'Deadline' to today
- 'Repeat Every' 1 week Until tomorrow
- Save > Change task state to 'Done'

A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have previously been handled by the CRON at the appropriate date).

opw-4210251

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

Forward-Port-Of: odoo/odoo#182365

**Description of the issue/feature this PR addresses:** When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App. **Steps to Reproduce:** - Install the `lunch` module - Go to Lunch > Configuration > Locations - Delete all records - Access the Lunch App again **Traceback:** OwlError ``` Invalid props for component 'AutoComplete': 'value' is not a string ``` This error occurs at [1], where the given p

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

When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App.

**Steps to Reproduce:**
- Install the `lunch` module
- Go to Lunch > Configuration > Locations
- Delete all records
- Access the Lunch App again

**Traceback:** OwlError
```
Invalid props for component 'AutoComplete': 'value' is not a string
```
This error occurs at [1], where the given props are empty.

This commit will resolve the above error by displaying a text message instead of trying to build a `Many2XAutocomplete` with empty values.

opw-4104561

[1]- https://github.com/odoo/odoo/blob/503c0d6f8fad09f5de678d8692fc283feac1b061/addons/lunch/static/src/components/lunch_dashboard.xml#L61

**Current behavior before PR:**
Without any record in the `lunch.location` model, the Lunch App cannot be accessed

**Desired behavior after PR is merged:**
Without any record in the `lunch.location` model, the Lunch App can be accessed, but a message "_No lunch locations available._" will be displayed in spite of the location.

**Screenshots**
Behavior without fix, with locations not yet deleted:
![lunch locations](https://github.com/user-attachments/assets/637eb09e-0bad-4034-acb9-21bcb337ad32)
Behavior with fix, with all locations deleted:
![No locations](https://github.com/user-attachments/assets/920f1c3e-2600-4e60-9968-1f5045517502)

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

Forward-Port-Of: odoo/odoo#182332
Forward-Port-Of: odoo/odoo#176135

Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [

Issue:
======
mass mailing iframe size isn't correct.

Steps to reproduce the issue:
=============================
It doesn't alwyas happen because of race condition, so you may need to
try multiple times.

- Create a new mass mailing
- Add 3 `image-text` snippets
- You can't scroll down in the editable area because the size of the
  iframe is smaller than it's content.

Origin of the issue:
====================
The function that resizes the iframe in mass mailing is defined in [1].

In `onDragStart` in [2] we call `addStyle` on the iframe to make sure it
has `pointerEvents:auto` style.

Now when the drag ends there are 2 events executing in parallel which
are :

- `onPointerUp` in [3]: which will call `dragEnd` which itself will call
  `cleanup` so it will assign the old style attribute to the iframe.

- resizing of the iframe from the `_resizeObserver`

Now if `_resizeMailingEditorIframe` is called first then it will have
the new size and then the cleanup will assign the old style which have
the wrong size which makes the editable smaller than its content and we
can't scroll down the editable.

Solution:
=========
We use `addClass` instead of `addStyle`.

task-4041275

[1]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/mass_mailing/static/src/js/mailing_mailing_view_form_full_width.js#L19
[2]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web_editor/static/src/js/editor/drag_and_drop.js#L135
[3]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web/static/src/core/utils/draggable_hook_builder.js#L752

Forward-Port-Of: odoo/odoo#179605

The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235

The issue:
While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone.

The fix:
Adapt the timezone

runbot-56562

Forward-Port-Of: odoo/odoo#177235

Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does

Steps to reproduce:
- Have a draggable that uses an iframe
- The iframe must be offset from the page (0,0)
- The draggable must be outside of the iframe
- Yank the mouse fast over the iframe, such that the mouse goes over the
  iframe before the dragged item can catch up.

-> the dragged item is offset from the mouse so long as the mouse
remains over the iframe.

In 17.2 this issue affects the mailing editor inside marketing automation
when editing an activity. This is because it does not inherit pe-none
in that scenario, unlike inside form views.

Drag and drop relies on `clientX` and `clientY` being in the coordinates
of the viewport.

When entering an iframe, mouse event coordinates (other than screen-based) are
given relative to the viewport of the iframe.

This means the position of the drag and drop does not match
the position of the mouse.

This can be fixed by preventing the iframe from becoming the target of the event
using style="pointer-event: none;" on the iframe itself.

task-4160857

Forward-Port-Of: odoo/odoo#181812

The domain set on the list datasource did not exclude the draft and cancelled invoices as it was for the other datasources. task-3999225 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#182624

The domain set on the list datasource did not exclude the draft and cancelled invoices as it was for the other datasources.

task-3999225

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

Steps to reproduce: - Payroll > Configuration > Working Schedules - Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days -- 10:00-12:00, Attendance type, 0.25 days - Employees > Any with that schedule > Time Off - Take a day off on a Monday (Full day) - Time Off app > Management > Time Off - Try to validate this time off An error occurs when trying to read the morning's work entry type because both shifts have been merged (and thus the resulting s

Steps to reproduce:
- Payroll > Configuration > Working Schedules
- Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days
-- 10:00-12:00, Attendance type, 0.25 days
- Employees > Any with that schedule > Time Off
- Take a day off on a Monday (Full day)
- Time Off app > Management > Time Off
- Try to validate this time off

An error occurs when trying to read the morning's work entry type because both shifts have been merged (and thus the resulting shift has 2 entry types). This happens because of the use of Intervals in resource_calendar's '_attendance_intervals_batch' method.

When dealing with attendances we prefer using WorkIntervals which, unlike Intervals, keeps adjacent shifts separate. This is necessary to properly handle the entry type of leaves and attendances over contiguous periods.

This also removes the need for fdd9247cb86a01cc8c0903e69b85aae311e7c1ad, as the attendances have already been separated (Shifts cannot overlap any more than at their bounds) according to their type.

opw-4193334

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

Forward-Port-Of: odoo/odoo#182574

The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571

The aim of this commit is to prevent test from failing when the error is coming from a missing CoA.

We used this opportunity to add a docstring and a new assert.

task-id: None
Runbot-build-error: 100531

Forward-Port-Of: odoo/odoo#182571

The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee.

The error occurred when the user was going to check in but didn't find any employee.

Steps to reproduce:
- Install ``hr_attendance`` module(without demo)
- Employees > click on employee and remove ``Related User`` in ``HR Settings``
- Click on the ``systray`` button and ``Check-in``

Traceback: 
``Expected singleton: hr.employee()``

The error occurred at [1] because we couldn't find an employee.

This commit resolves the above error by disabling the button if there is no employee.

[1]- https://github.com/odoo/odoo/blob/b05e203aa8f6956d5bc6606d7df53d74442d727a/addons/hr_attendance/controllers/main.py#L164

sentry-5616192792

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

Forward-Port-Of: odoo/odoo#173829