Odoo Changelog — 2024-10-01

Tuesday, October 1, 2024

168 changes

Branch: saas-17.2

14 changes

Other(14)

Miscellaneous changes

[FW][FIX] sale: price rules form behavior

PR #182225

Coresaas-17.2product

Steps : - Set the company of the first pricelist in list view to false - Create a product and set it's company and the go to extra price tab and group by product - Now when adding a new, opens form view, try saving the record Issue : Returns a warning message not allowing to save Cause : The company for pricelist that is default selected and the product have different companies Fix : Updated the action so that it does not open form view as the pricelist tree view is multi-edit

Original PR description

Steps :
- Set the company of the first pricelist in list view to false
- Create a product and set it's company and the go to extra price tab and group by product
- Now when adding a new, opens form view, try saving the record

Issue :
Returns a warning message not allowing to save

Cause :
The company for pricelist that is default selected and the product have different companies

Fix :
Updated the action so that it does not open form view as the pricelist tree view is multi-edit

opw-3943830

Forward-Port-Of: odoo/odoo#171032

[FW][FIX] mrp: not unreserve twice during mass production

PR #181864

Coresaas-17.2mrp

### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock) - Create and confirm an MO for 10 units of P - Validate the delivery from stock to pre-production - Click on `Mass Produce` > `Generate` only 7 SN - Click No back order (split and generate only 7 MO's)

Original PR description

### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P…

### Steps to reproduce:

- Enable Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Change your warehouse settings to Manufacturing in 2 steps
- Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock)
- Create and confirm an MO for 10 units of P
- Validate the delivery from stock to pre-production
- Click on `Mass Produce` > `Generate` only 7 SN
- Click No back order (split and generate only 7 MO's)
#### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be
- validate one of the 7 MO
#### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be

### Cause of the issue:

By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines:
https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines:
https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice

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

Forward-Port-Of: odoo/odoo#181255

[FW][FIX] hr_holidays: accrual start gain time granted immediately

PR #182217

Coresaas-17.2hr_holidays

Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on the last day of the month > Save - Management > Allocations > New - Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan - Set the start date to today - 0 days of allocation for 'Time off type' of your choice > Validate - My time > Dashboard > Use 'Balance at the mm/

Original PR description

Steps to reproduce:
- Time off > Configuration > Accrual Plan > New
- Set 'Accrued Gain Time' to 'At the start'
- New Milestone > Set 'Milestone reached' to 0 days after...
- Accrue 1 day Monthly on the last day of the month > Save
- Management > Allocations > New
- Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan
- Set the start date to today
- 0 days of allocation for 'Time off type' of your choice > Validate
- My time > Dashboard > Use 'Balance at the mm/dd/yyyy'

The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead.

The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid re-computations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves.

This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute.

Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway.

opw-4192703

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

Forward-Port-Of: odoo/odoo#181115

[FW][FIX] mail: allow SA to send emails on any model

PR #182104

Coresaas-17.2mailtest_mail

odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it. Task-4203142 Forward-Port-Of: odoo/odoo#181763

Original PR description

odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread

This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it.

Task-4203142

Forward-Port-Of: odoo/odoo#181763

[FW][FIX] web: allow drag and drop elements in mass_mailing

PR #182204

Coresaas-17.2web

Issue: ====== We can't move elements in mass mailing. Steps to reproduce the issue: ============================= - Create a new mass mailing with a template that have some blocks - Try to drag one of the blocks to another position - When you click on the button to drag, the right sidebar refreches Origin of the issue: ==================== The issue was first introduced by [1]. The problem when we have the wysiwyg inside an iframe `document.activeElement` will be equal to the i

Original PR description

Issue:
======
We can't move elements in mass mailing.

Steps to reproduce the issue:
=============================
- Create a new mass mailing with a template that have some blocks
- Try to drag one of the blocks to another position
- When you click on the button to drag, the right sidebar refreches

Origin of the issue:
====================
The issue was first introduced by [1].

The problem when we have the wysiwyg inside an iframe
`document.activeElement` will be equal to the iframe element and the
`ev.target` is the button of dragging. In reality the button is inside
the iframe but the content of the iframe is like this `<iframe>
document <iframe>` so contains returns false.

Solution:
=========
When the `activeElement` is an iframe we search inside its
`contentDocument`.

opw-4196067

[1]: https://github.com/odoo/odoo/commit/ef97eaf9876bcf1712d4a6bfb91307875b0034ac

Forward-Port-Of: odoo/odoo#181143

[FW][FIX] account: keep valid attachments on bill

PR #182218

Coresaas-17.2account

To reporoduce: ============== 1. install "l10n_mx" 2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket) -> Odoo only retrieves the XML file and PDF is deleted Problem: ======== when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted. Solution: ========= process all files. opw-4054484 --- I confirm I hav

Original PR description

To reporoduce:
==============
1. install "l10n_mx"
2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket)
-> Odoo only retrieves the XML file and PDF is deleted

Problem:
========
when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted.

Solution:
=========
process all files.

opw-4054484

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

Forward-Port-Of: odoo/odoo#180576

[FW][FIX] website: prevent website search box cache

PR #182219

Coresaas-17.2website

__Current behavior before commit:__ When making a search through `/website/search`, the `website_search_box` view is cached. This includes the search term and the search count. Therefore when a user makes a search, a previous search term might be displayed. It may even be a search that another user made. This bug appeared since the search bar has been added to header templates [`7559626`][1]. __Description of the fix:__ Add `t-nocache` to the whole searchbox so that the search term a

Original PR description

__Current behavior before commit:__
When making a search through `/website/search`, the `website_search_box`
view is cached. This includes the search term and the search count.
Therefore when a user makes a search, a previous search term might be
displayed. It may even be a search that another user made.

This bug appeared since the search bar has been added to header
templates [`7559626`][1].

__Description of the fix:__
Add `t-nocache` to the whole searchbox so that the search term and the
search count is updated with each search.

__Steps to reproduce the issue in local:__
(For the issue to appear consistently everytime there should be only a
single worker)
1. Click on the search button in the website header and make a search
2. Do the same thing again with another search
3. Click again on the search button

The previous search term is shown inside the searchbar

opw-4114511

[1]: https://github.com/odoo/odoo/commit/7559626

Forward-Port-Of: odoo/odoo#180548

[FW][FIX] l10n_sa_edi, point_of_sale, account, account_edi_ubl_cii: disable tax check on combos

PR #182215

Coresaas-17.2accountaccount_edi_ubl_ciil10n_sa_edipoint_of_sale

Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Ta

Original PR description

Currently, some localizations are not able to invoice if a combo product was bought.

Steps to reproduce:
-------------------
* Install **l10n_sa_edi_pos**
* Switch to the **SA Company**
* Go to the **Point of sale** App
* Go to the products
* Select a combo product
* Navigate through all the products that can be selected in the combo and apply a tax on each
* Open shop session
* Add the combo product to the order
* Validate and invoice the order
> Observation: Invalid Operation: Taxes need to be assigned on all invoice lines

Why the fix:
------------
Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product.

We can treat the parent combo line as the note or sections we would put on a quotation.

opw-4090946

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

Forward-Port-Of: odoo/odoo#181068

[FW][FIX] mrp: fix _split_productions set consumed_qty 2

PR #182216

Coresaas-17.2mrp

### Steps to reproduce: - Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock) - Create and confirm an MO for 10 units of P - Click on the [+] button to generate one serial number of P > This steps updates the qty_producting to 1 and the set the consumed_qty of the raw move to 1. - Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN) > This generates 9 backorders each for 1 unit of P with a set SN ###

Original PR description

### Steps to reproduce:
- Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock)
- Create and confirm an MO for 10 units of P
- Click on the [+] button to generate one serial number of P
> This steps updates the qty_producting to 1 and the set the
consumed_qty of the raw move to 1.
- Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN)
> This generates 9 backorders each for 1 unit of P with a set SN
#### > However raw moves are **picked with a consumed_qty of 0**

### Cause of the issue:

Since the stockpocalypse commit 7dda6bb the `_split_productions` did not consume quantities anymore. This behavior was fixed by commit 4be8cac for mass production notably by the addittion of these lines: https://github.com/odoo/odoo/blob/6995d65437ba6b2cd0df7503d589260bedcce67d/addons/mrp/models/mrp_production.py#L1879-L1887 However, in our flow, when we assigned the firt serial number by clicking on the [+] button we had set the quantity of the `initial_move` to 1 and associated a `move_line` with the corresponding quantity to it. As such, none of the move line of the raw moves of the back order is going to be created and the issue remains.

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

Forward-Port-Of: odoo/odoo#179062

[FW][FIX] stock_dropshipping: wrong vendor selected

PR #181712

Coresaas-17.2purchase_stockstock_dropshipping

Steps to reproduce: - Create a product with 2 vendors: - First one: quantity 10, delay 10, price 5 - Second one: quantity 5, delay 5, price 10 - Select the dropship route on the product - Create an SO with that product (quantity 5) and confirm it - Go on the purchase order created Bug: The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well) Fix: In https://github.com/odoo/odoo/commit/a35be7b0dd52a5

Original PR description

Steps to reproduce:
- Create a product with 2 vendors:
	- First one: quantity 10, delay 10, price 5
	- Second one: quantity 5, delay 5, price 10
- Select the dropship route on the product
- Create an SO with that product (quantity 5) and confirm it
- Go on the purchase order created

Bug:
The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well)

Fix:
In https://github.com/odoo/odoo/commit/a35be7b0dd52a5a02b6811cb95ad3189483b7327, the partner passed to _select_seller will always have a value, but an incorrect one for dropshipping routes. The problem resides in https://github.com/odoo/odoo/blob/c04fe54bf45509660ea94a9d7d431c74f1c6023b/addons/product/models/product_product.py#L656. The partner_id is the SO buyer, and it's not possible to have the vendor == to the buyer. It thus default the vendor to the first known vendor which is incorrect.

task-id: 4207060

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

Forward-Port-Of: odoo/odoo#181542

[FW][FIX] product: catalog ux manual edit

PR #182110

Coresaas-17.2product

When a user clicks in the catalog record input to change the quantity manually the input content isn't autoselect and the user has to delete the former one to enter the desired value. Autoselecting the value seems more conveniant in the majority of cases. Also, after one of these edits, if the user click right away in the Back to order button, the redirection to the order form will too fast and it will miss the last edition. Current behavior before PR: ![Peek 12-09-2024 11-29](https://g

Original PR description

When a user clicks in the catalog record input to change the quantity manually the input content isn't autoselect and the user has to delete the former one to enter the desired value. Autoselecting the value seems more conveniant in the majority of cases.

Also, after one of these edits, if the user click right away in the Back to order button, the redirection to the order form will too fast and it will miss the last edition.

Current behavior before PR:

![Peek 12-09-2024 11-29](https://github.com/user-attachments/assets/7ab2d27a-5fc9-4d0c-af54-4f4bfa33c374)


Desired behavior after PR is merged:

![after](https://github.com/user-attachments/assets/e96f97a4-fb08-4b9f-bf60-45c6e0662210)


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

Forward-Port-Of: odoo/odoo#180003

[FW][I18N] l10n_ar*: add missing translations

PR #182214

Coresaas-17.2l10n_arl10n_ar_posl10n_ar_website_salel10n_ar_withholding

Some pot files were out of date/missing, some .po files were out of date/missing/missing translations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182056

Original PR description

Some pot files were out of date/missing, some .po files were out of date/missing/missing translations

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

Forward-Port-Of: odoo/odoo#182056

[FW] 17.0 opw 3977674 fix agr

PR #181281

Coresaas-17.2l10n_it_edi_withholding

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

Original PR description

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

[FW][FIX] account: no quick encoding on section/note

PR #182318

Coresaas-17.2account

**Steps to reproduce:** - Install Accounting - Go to Accounting settings - Set "Quick encoding" to "Customer Invoices and Vendor Bills" - Create an invoice - Set "Total (Tax inc.)" to any value - Add a section and a note - Check Journal Items **Issue:** A tax is set on the section and the note lines. opw-4204583 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181519

Original PR description

**Steps to reproduce:**
- Install Accounting
- Go to Accounting settings
- Set "Quick encoding" to "Customer Invoices and Vendor Bills"
- Create an invoice
- Set "Total (Tax inc.)" to any value
- Add a section and a note
- Check Journal Items

**Issue:**
A tax is set on the section and the note lines.

opw-4204583




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

Forward-Port-Of: odoo/odoo#181519

Branch: 18.0

86 changes

Improvements(6)

Enhancements to existing features

[IMP] mail: 'start a call' thread action becomes green on hover

PR #182389

Core18.0mail

The call action in mail discussions now turns green when users hover over it. This makes it clearer that selecting the button will immediately start a call, helping users avoid accidental actions.

Original PR description

This makes it more obvious that clicking on this button will start the call immediately, compared to all other thread actions that have a significantly lower level of commitment.

![Oct-01-2024 17-14-03](https://github.com/user-attachments/assets/459641f4-5707-4825-9660-bb8e4f4223b7)

#mail#calls#user interface

[IMP] website: skip outdated theme preview on theme switch screen

PR #182433

Core18.0website

The website theme switch flow now avoids showing preview screens that may contain outdated theme images. This helps users avoid confusion while Odoo continues to rely on the main website configurator, which provides up-to-date personalized previews.

Original PR description

The theme previews on `themes.odoo.com` website are not up-to-date. While waiting for them, skipping the preview screen if you were to reach the switch theme screen (it is not the main flow: using the configurator the preview is a SVG with user-related colors, text and images and those are up-to-date).

#theme#website#preview#user experience

[FIX] website: refine `AddPageConfirmDialog` interaction elements design

PR #182363

Core18.0websitetest_website

The website page creation dialog now has a simpler, more consistent design by removing an unnecessary template button and aligning its interaction elements with the snippet library modal. The blank page option also has a more polished placeholder, improving the page setup experience for website editors.

Original PR description

This PR removes the unnecessary "Use this template" button and refines interaction elements' design in order to achieve a visual result consistent with the snippet-library modal.

It also slightly improve the "Blank Page" placeholder for a better visual result.

task-4224057



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

#website#page creation#user interface

[IMP] web, account: improve carets visibility

PR #181636

Core18.0accountweb

This update makes dropdown and sortable column indicators easier to see and better positioned when text is crowded. Users benefit from clearer visual cues while navigating autocomplete fields and list views, with small usability improvements in accounting and general web screens.

Original PR description

This PR improves various carets of the autocomplete dropdown and the list view sortable columns. It improves it's visibility and saves space when it overlaps with text.

Task: [4170216](https://www.odoo.com/odoo/project/133/tasks/4170216)

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

#usability#visibility#dropdowns#list views

[IMP] html_editor: AI as alias to ChatGPT command

PR #182157

Core18.0html_editor

The HTML editor’s command search now supports extra keywords, making relevant tools easier to find. Users can type “AI” to quickly access the ChatGPT command, reducing friction when using AI writing assistance.

Original PR description

[IMP] html_editor: search keywords for powerbox commands
[IMP] html_editor: AI as alias to ChatGPT command

task-4207516

#AI#ChatGPT#editor#search

[IMP] Disable download of dashboard json file in list view

PR #70787

Enterprise18.0quality_controlspreadsheet_dashboard_edition

Dashboard JSON files can no longer be downloaded from list views in debug mode because those files may show outdated dashboard content. Users now receive a warning instead, reducing confusion and preventing reliance on incomplete dashboard versions.

Original PR description

When downloading a dashboard's json file in debug mode, we get the initial version of the dashboard file and not the latest (without the revisions). This commit's goal is to prevent downloading the dashboard's json file and displaying a warning message to the user.

task-4196930

#dashboard#download#warning#debug-mode

Bug Fixes(27)

Resolved issues and error corrections

[FIX] mail: DiscussSidebar hover doesn't flicker on mouse-hovering

PR #182394

Core18.0mail

This fixes a visual flicker on status icons when users hover over items in the compact Discuss sidebar. The change makes the interface feel steadier and more polished without changing any workflow or functionality.

Original PR description

Mouse-hovering items when discuss sidebar is compact result in some style flickering on im status icon.

This happens because the items are button and they need `bg-inherit`. Due to CSS specificity, however, the classname is not enough, so we need `!important` in CSS, which is what this commit does to fix the issue.

Before / After (see status of 3 items at the bottom while mouse-hovering)

![before](https://github.com/user-attachments/assets/f2ef3a89-d5b7-451c-92a5-5157c1283338) ![after](https://github.com/user-attachments/assets/0720aa65-948f-4131-8ca1-140aa899f58e)

#discuss#sidebar#hover#visual-fix

[FIX] website: disable view "Published" field in "Properties" menu

PR #182375

Core18.0website

The website page properties menu no longer shows a publishing option that could make pages appear unpublished while still leaving them in the sitemap. This avoids misleading website managers until a more reliable solution is available.

Original PR description

Commit [1] introduced the possibility to publish/unpublish "any route" by using the visibility and groups fields available on the rendered view. This obviously had its limitations, indeed the route…

Commit [1] introduced the possibility to publish/unpublish "any route"
by using the visibility and groups fields available on the rendered
view. This obviously had its limitations, indeed the route and the view
are independent (e.g. a same URL could lead to different views depending
on values in the database for example) but allowing to "unpublish" the
"current rendered page the user is seeing" seemed like a good first
improvement anyway.

However, the sitemap was forgotten... and it is proving difficult to fix
in a way that makes sense. It would mean saving the info of the URL
that was used to reach the "unpublished" *view* in the first place
somehow somewhere... and if it were to be possible, controllers with
parameters, or controllers that lead to different views depending on
some configuration would really be a problem.

We choose to disable the feature for now (keeping its code but just not
showing the possibility via the UI). We will revisit this later. In the
end [2] added the possibility to properly "unpublish the whole shop"
(not just one page), which is the main demand when it comes to
unpublishing controllers (funny enough, the sitemap was also forgotten
for that feature, before fixes [3] and [4]).

[1]: https://github.com/odoo/odoo/commit/e3b1ff6e25ecc71c9242d3826cee09c636bc465a
[2]: https://github.com/odoo/odoo/commit/5bde2e42c8ec5e943a779ad4b3e1b7142f2d2fcf
[3]: https://github.com/odoo/odoo/commit/0738e0210207397429826ab3c4b3760b3a4dff44
[4]: https://github.com/odoo/odoo/commit/eb14c1f401d5d09a1d906346a4a4cd494bb47628

#website#publishing#sitemap

[FIX] mail: call icon in DiscussSidebar lack spacing with border

PR #182377

Core18.0mail

The Discuss sidebar call icon now has better spacing when displayed with a border. This small visual fix makes the interface look cleaner and easier to scan for users.

Original PR description

Before / After
<img width="296" alt="Screenshot 2024-10-01 at 16 26 22" src="https://github.com/user-attachments/assets/b7b23378-b778-4610-ba8d-83f3219e7234">
<img width="299" alt="Screenshot 2024-10-01 at 16 25 57" src="https://github.com/user-attachments/assets/08cf20af-fb75-4ddf-ae25-3d5f5d1c241a">

#Discuss#sidebar#call icon#visual fix

[FIX] point_of_sale: change field name to the newer one

PR #182089

Core18.0point_of_sale

This fixes an issue in Point of Sale where floating orders were not listed alphabetically by their assigned names. The system now uses the current order name field, making it easier for staff to find and manage multiple open orders.

Original PR description

Steps to reproduce :
--------------------------
- Install the point_of_sale module.
- Place orders on two or more floating orders.
- Give the orders some name.

Issue :
---------
The floating orders are not sorted according to alphabet properly.

Cause :
----------
The field containg floating order name is changed but, at this place still try to sequence by old name.
[Referance PR](https://github.com/odoo/odoo/pull/175535)

Fix :
-----
Now updated the field name properly from note to floating_order_name.

#point of sale#floating orders#sorting

[FIX] html_editor: remove extended text style

PR #182373

Core18.0html_editor

The HTML editor no longer shows advanced text style options that are not currently supported in the website builder. This reduces confusion by hiding controls that are not relevant until the website builder moves to the new editor.

Original PR description

Currently, showExtendedTextStylesOptions are still displayed. Before the new editor (html_editor), it was only used by the website builder. The website builder still doesn't use html_editor, so we're going to disable them. We'll reintroduce them when the website builder uses html_editor.

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

#html editor#text styling#user interface

[FIX] mrp: manual consumption BOM line with operations

PR #182149

Core18.0mrp

Manufacturing orders now correctly treat BOM lines linked to an operation as manually consumed components. This prevents materials from being consumed automatically when an operation-specific component should be handled manually, improving production accuracy.

Original PR description

When an operation is added to a BOM line, it will be treated as a manual consumption component.





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

#manufacturing#bom#operations#consumption

[FIX] website, website_mass_mailing: add/remove snippets keywords

PR #181732

Core18.0websitewebsite_mass_mailing

Website editor building blocks now have more accurate keywords, making it easier for users to find the right content elements. Keywords that are no longer useful after the sidebar search removal were also cleaned up, reducing maintenance noise without changing business workflows.

Original PR description

This PR updatsd snippets keywords ensuring they accurately reflect the associated content.
It also removes inline-snippets' keywords' because, following the removal of the sidebar's search, these are no longer necessary.

task-4063510


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

#website editor#snippets#search keywords

[FIX] web_tour: start tour by url

PR #182340

Core18.0web_tour

Starting an onboarding tour from a direct URL now correctly loads its step-by-step guidance. This prevents users from seeing an incomplete tour and helps onboarding flows work as expected.

Original PR description

When starting tour by url, if the tour was an onboarding tour (info in db and steps in registry), the steps were missing.
Now, if the steps are missing, I search them in the registry.

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

#onboarding#tour#url

[FIX] *: little fixes in tours

PR #182289

Core18.0crmmrppos_restaurantproject_todotest_sale_product_configuratorswebsitewebsite_livechat

This update streamlines several automated walkthrough tests by removing repeated or unnecessary actions and reducing waiting time between checks. It helps the test suite run faster and more reliably without changing business features or user workflows.

Original PR description

In this commit, we :
- Remove redondant steps (multiple click on the same element)
- Remove unuseful clicks (default action is now "nothing")
- Impose checkDelay so that tours go faster (checkDelay is 750ms by
default)

#tests#tours#quality#performance

[FIX] spreadsheet_dashboard: move edit button

PR #182079

Core18.0spreadsheet_dashboardspreadsheet_dashboard_edition

The dashboard edit option is now only provided by the edition module that supports it. This prevents users from seeing an error when opening a dashboard in installations that do not include the editing add-on.

Original PR description

Steps to reproduce:
- Install spreadsheet_dashboard without spreadsheet_dashboard_edition
- Go to a dashboard
- Click on the edit button => Traceback

This commit moves the edit button to the right module (spreadsheet_dashboard_edition).

Note that to avoid overriding DashboardAction (component, template and entry in the registry), we introduce a new registry with the aim to contains the edit button.

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

#dashboard#spreadsheet#edit button#stability

[FIX] project , hr_timesheet: Correct alignment of footer elements

PR #182129

Core18.0hr_timesheetproject

Project and timesheet task cards now display footer details more neatly. Assignee names are shortened when space is limited, the remaining-hours indicator blends better with the page, and outdated styling was removed for a more consistent look.

Original PR description

**Before this commit:**
- The assignee's name would overflow instead of truncating in the footer.
- The remaining hour's widget displayed an unusual grey background.
- classes with the prefix `oe_` were present for styling.

**After this commit:**
 - The assignee's name will now truncate after a specific width in the footer.
 - The remaining hour's widget has a transparent background.
 - removed class `oe_kanban_align` from the code base.

Task-4207390

#project#timesheets#task cards#layout

[FIX] website: adapt dynamic snippet size when 1 elt is fetched

PR #182142

Core18.0websitewebsite_sale

Website dynamic snippets now keep a balanced layout when they show only one item, such as a product or appointment. This prevents the item from stretching too wide or becoming overly tall, improving page appearance and readability.

Original PR description

Prior to this this commit, when a single element was fetched in the dynamic snippet, it took the entire width and became too tall according to the page height. (e.g. Products or Appointments snippet)

To limit the height of this snippet, this commit forces the same size to be used as when two elements are fetched.

task-4215773




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

#website#snippets#layout

[FIX] html_editor: reset table size

PR #182155

Core18.0html_editor

The table editing menu now includes the missing Reset Size option again. This helps users quickly return tables to their default sizing after editing, improving consistency in content editing.

Original PR description

The Goal of this commit is to add the “Reset Size” table menu item that
had been omitted during conversion to html_editor.

#html editor#tables#reset size

[FIX] website_(forum, profile): use `t-att-content` for textarea

PR #182117

Core18.0website_forumwebsite_profile

This change fixes how saved text is loaded into forum and profile text areas. It avoids an extra server lookup, helping these pages show existing content more reliably and efficiently.

Original PR description

This is a partial revert of [1] and proposition of another solution.

Instead of doing an extra orm call we just add the content as attribute to the textarea and retrieve it directly from there.

opw-4148163

[1]: https://github.com/odoo/odoo/commit/82fbc0c30848763d6a55d4e5e78b0b34ff6c8245

#forum#profile#textarea#performance

[FIX] html_editor: escape close powerbox

PR #182178

Core18.0html_editor

This fix makes the editor's command search close properly when users press Escape. It prevents the search panel from unexpectedly reopening when the user continues typing, making text editing smoother and less confusing.

Original PR description

Before this commit, pressing “escape” when the powerbox is open did not stop the current search. Adding a new character reopened it.

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

#editor#powerbox#keyboard

[FIX] hr_holidays: fixes accrual validity visibility

PR #181239

Core18.0hr_holidays

This fixes the Time Off accrual plan view so the carry-over validity value is no longer shown when no validity period is configured. It reduces confusion for HR users by only displaying relevant leave policy information.

Original PR description

in this commit, fixes a issue where carry over validity isn't set value is still visible in view.

task-4207945

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

#time-off#accruals#carry-over

[WIP][FIX] frontdesk: broken style

PR #70926

Enterprise18.0frontdesk

This fixes a display issue in Frontdesk kiosk mode where the landing page did not fill the full browser window. The change improves the visitor check-in experience by making the kiosk screen look complete and consistent.

Original PR description

This PR addresses a styling issue in the kiosk mode of Frontdesk. Before this pr, the landing page would not fill the height of the window causing the whole user experience to be strange.

task-4213241

#frontdesk#kiosk#style

[FIX] documents_hr: fix employee documents link

PR #71191

Enterprise18.0documents_hr

This fixes an issue where links to employee documents were missing or incorrect in HR document communications. Employees and HR teams can now access the intended documents more reliably from the related messages or pages.

Original PR description

We forgot to add the field. We'll go for a model method in this fix, this can be cleaned to a field in master.

Task-4216195

#hr#documents#employee-records

[FIX]: spreadsheet_dashboard_edition: move edit button

PR #71041

Enterprise18.0spreadsheet_dashboard_edition

The dashboard edit button has been moved into the updated dashboard controls so it appears where users expect it. This keeps spreadsheet dashboard editing available after related interface changes, reducing confusion for users who manage dashboards.

Original PR description

This commit is the counterpart of https://github.com/odoo/odoo/pull/182079 and add the edit button to the newly introduced registry.

#dashboard#spreadsheet#edit button

[FIX] spreadsheet_sale_management: exclude sections and notes

PR #71086

Enterprise18.0spreadsheet_sale_managementspreadsheet_dashboard_editionspreadsheet_edition

Sales order spreadsheets now leave out section headers and notes from line item lists, avoiding confusing or poorly formatted rows. The list is also inserted with table styling again, making spreadsheet views clearer and easier to read.

Original PR description

Sections and notes in the SO are badly displayed in the sale order line list in the spreadsheet. They should be excluded from the list (domain on display type). (or maybe later, change the default list fields to make it pretty somehow?)

Task: 4200539

#sales orders#spreadsheets#display

[FIX] web_studio: qweb table menu

PR #71173

Enterprise18.0web_studio

The report editor's table menu now disappears again when the pointer moves away, matching the previous expected behavior. It also closes during scrolling, reducing visual clutter and preventing the menu from staying open at the wrong time.

Original PR description

Since PR odoo/enterprise#181141, when a qweb table menu is displayed, it no longer disappears when the pointer moves outside it.

This commit will reintroduce the old behavior:
- When the pointer quits a closed qweb table menu, we make it disappear.
- When the pointer leaves an open qweb table menu, it doesn't disappear. You need to do a pointerdown to make it disappear.

We'll also add a close to the qweb table menu when scrolling. This will have the same behavior as the table menu.

#report editor#table menu#usability

[FIX] 3 commits to fix tours

PR #71171

Enterprise18.0knowledgetest_rental_product_configuratorsweb_studio

This update cleans up and speeds up several automated test tours used to verify key workflows in Knowledge, Rental product configuration, and Web Studio. It helps reduce unnecessary test steps and makes validation faster and more reliable without changing customer-facing features.

#automated tests#tours#reliability

[FIX] documents_account: avoid creating empty moves

PR #71172

Enterprise18.0documents_account

This fix prevents the Documents accounting flow from creating unnecessary empty accounting entries when determining the right journal. It reduces clutter and helps keep accounting records cleaner without changing the intended user workflow.

Original PR description

We don't need to create an empty move to compute the suitable journal_id.

Task-4216195

#documents#accounting#journal

[FIX] documents: remove hide shortcuts filter

PR #71170

Enterprise18.0documents

The Documents app no longer automatically applies the filter that hides shortcuts in search results. This reduces confusion by showing users a more complete and expected view of their documents unless they choose otherwise.

Original PR description

It's more confusing than helpful to enable the filter automatically.

Task-4216195

#documents#search#shortcuts

[FIX] documents: fix search panel reload after actions

PR #71028

Enterprise18.0documents

The Documents app now refreshes its folder list after actions such as creating shortcuts, duplicating, archiving, or renaming folders. This prevents outdated folders from remaining visible and helps users see the correct document structure immediately.

Original PR description

Before this commit when creating shortcut / duplicating / archiving / renaming a folder the search panel wasn't reloaded and thus the folder still appeared in it. This commit fixes this.

Task-4219258

#documents#folders#search panel

[FIX] documents: fix control panel button group

PR #70851

Enterprise18.0documentsdocuments_spreadsheet

The Documents control panel buttons now display with consistent grouping and styling. This prevents visual glitches when only certain action buttons, such as Share, are shown.

Original PR description

Some btn-group classes were missing creating inconsistent looks among the buttons.

The presence of the xpath for the share and freeze btn breaks the style when there are only the actions and share btns to display on the ctrl panel.

task-3373836

#documents#buttons#interface

[FIX] documents: fix breadcrumbs for non-pinned Company roots

PR #71042

Enterprise18.0documents

This fixes an issue where opening certain Company document folders showed incorrect breadcrumbs and hid available actions. Users can now navigate these folders more reliably and access the expected options.

Original PR description

To reproduce:
Open a non-pinned folder in "Company", the breadcrumb will not be correctly shown and actions are not available.

When simply removed from the returned records, no item is added in the breadcrumbs on opening a non-pinned company root folder.

Co-authored-by: Lopes Marc (loma) <loma@odoo.com>

Task-4216195

#breadcrumbs#folders#navigation

Refactoring(4)

Code cleanup and technical improvements

[REF] html_editor: clean the resource API for plugins

PR #181198

Core18.0html_editor

The HTML editor’s internal plugin resource system was simplified so developers can define and access shared editor resources more consistently. This is an internal refactor that should make future editor maintenance easier without changing day-to-day user behavior.

Original PR description

This commit change the resource API for the plugins in 3 ways. # 1) The disposal of resources Instead of ```js class MyPlugin extends Plugin { /** @type { (p: MyPlugin) => Record<string, any> } */…

This commit change the resource API for the plugins in 3 ways.

# 1) The disposal of resources

Instead of

```js
class MyPlugin extends Plugin {
    /** @type { (p: MyPlugin) => Record<string, any> } */
    static resources = (p) => ({
        my_handlers: p.handler.bind(p)
    })
}

```

We now have
```js
class MyPlugin extends Plugin {
    resources = {
        my_handlers: this.handler.bind(this)
    }
}
```

# 2) Resource getter
To access a specific resource within a plugin, instead of

```js
this.resources['my_handler']
```

We now have
```js
this.getResource('my_handler')
```

If no other plugin disposed the specified resource, the getter will return an empty array.

# 3) Sequences for all resources
This commit give the ability to specify a sequence for any resource item, removing the need for the consumer of the resource to have to setup it.

Instead of
```js
class MyPluginA extends Plugin {
    resources = {
        my_handlers: {handler: this.handler.bind(this), sequence: 100}
        my_data: {id: 'some-id', sequence: 100}
    }
}
class MyPluginB extends Plugin {
    constructor() {
        this.handlers = this.getResource('my_handlers')
            .sort((a, b) => a.sequence - b.sequence)
    }
    myMethod() {
        for (const {handler} of this.myHandlers) {
            handler();
        }
    }
}
```

We now have
```js
class MyPluginA extends Plugin {
    resources = {
        my_handlers: withSequence(100, this.handler.bind(this)),
        my_data: withSequence(100, {id: 'some-id'}),
    }
}
class MyPluginB extends Plugin {
    myMethod() {
        for (const handler of this.getResource('my_handlers')) {
            handler();
        }
    }
}
```





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

#html editor#plugins#maintenance

[REF] html_editor, *: dialog plugin

PR #182076

Core18.0html_editor

Editor dialogs now share a common way to restore the user's cursor or selection after the dialog closes. This reduces duplicated logic and helps make editing interactions more reliable across features such as media and AI-assisted content dialogs.

Original PR description

The purpose of this commit is to add a dialog plugin that will centralise the behaviour shared between dialogs opened from the editor. The behaviour shared by all the editor dialogs is the repositioning of the selection in the editable when a dialog closes.

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

#editor#dialogs#consistency

[REF] html_editor: clean the resource API for plugins

PR #70560

Enterprise18.0appointmentknowledge

The editor plugin resource API was updated to stay aligned with related platform changes. This is an internal cleanup that helps appointment and knowledge editor features remain maintainable without changing day-to-day user workflows.

Original PR description

This commit adapt the api of plugin resources to match the changes made in community.

#html_editor#plugins#maintenance

[REF] html_editor, *: dialog plugin

PR #71040

Enterprise18.0html_editorappointmentknowledge

Editor dialogs now share a common handling process so the editing cursor returns to the right place when a dialog closes. This reduces inconsistent behavior across areas such as appointments and knowledge articles, making editing smoother for users.

Original PR description

The purpose of this commit is to add a dialog plugin that will centralise the behaviour shared between dialogs opened from the editor. The behaviour shared by all the editor dialogs is the repositioning of the selection in the editable when a dialog closes.

#editor#dialogs#usability

Other(49)

Miscellaneous changes

[FW][FIX] *: fix some broken tests

PR #182385

Core18.0

Original PR description

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

[FW][FIX] mail: fix prefetch of fields

PR #182362

Core18.0mailtest_mailtest_mass_mailing

Overriding the _compute_field_value in order to only prefetch the currently requested field. opw-4213262 Forward-Port-Of: odoo/odoo#181855 Forward-Port-Of: odoo/odoo#181534

Original PR description

Overriding the _compute_field_value in order to only prefetch the currently requested field.

opw-4213262

Forward-Port-Of: odoo/odoo#181855
Forward-Port-Of: odoo/odoo#181534

[FW][FIX] sale_project: avoid stop iteration issue

PR #182384

Core18.0sale_project

Steps to reproduce: 1. Install the `sale_project` module. 2. Create a product with the following properties: - Type: 'Service' - Create on Order: 'Project & Task' 4. Create a sale order and add the product to it. 5. Confirm the sale order. 6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.) The issue arises because the 'Project' smart button remains visible

Original PR description

Steps to reproduce:
1. Install the `sale_project` module.
2. Create a product with the following properties: 
    - Type: 'Service'
    - Create on Order: 'Project & Task'
4. Create a sale order and add the product to it.
5. Confirm the sale order.
6. In another tab, change the product type to 'Consumable' in the product form (a popup will appear informing you that you cannot change the type, but it can be dismissed.)

The issue arises because the 'Project' smart button remains visible in the sale order tab until the page is reloaded, and there are no longer any order lines with a product of type 'Service', resulting in a StopIteration error.

Closes #180340

Forward-Port-Of: odoo/odoo#182235
Forward-Port-Of: odoo/odoo#181946

[FW][FIX] stock: compute the qty to order of orderpoint correctly

PR #182328

Core18.0stock

**Steps to reproduce the bug:** - Create a storable product "P1". - Go to the Purchase tab > add a vendor. - Create an order point: - Min qty: 10 - Trigger: Auto - Result > the quantity to order is updated to 10. - Create a delivery with one unit of P1. - Mark the delivery as 'To Do'. **Problem:** A purchase order is created with 10 units of P1 instead of 11. **Explanation:** When the minimum quantity is set to 10, the `_compute_qty_to_order` method is triggere

Original PR description

**Steps to reproduce the bug:**
- Create a storable product "P1".
   - Go to the Purchase tab > add a vendor.
   - Create an order point:
     - Min qty: 10
     - Trigger: Auto
   - Result > the quantity to order is updated to 10.
- Create a delivery with one unit of P1.
- Mark the delivery as 'To Do'.

**Problem:**
A purchase order is created with 10 units of P1 instead of 11.

**Explanation:**
When the minimum quantity is set to 10, the `_compute_qty_to_order` method is triggered. Since the `qty_to_order_manual` is 0, the `qty_to_order_computed` is using so computed with `_compute_qty_to_order_computed` and assigned to `qty_to_order`:
https://github.com/odoo/odoo/blob/156bed3f430d706e13822bbd95d91c8dfd3ea42d/addons/stock/models/stock_orderpoint.py#L274-L277

https://github.com/odoo/odoo/blob/156bed3f430d706e13822bbd95d91c8dfd3ea42d/addons/stock/models/stock_orderpoint.py#L292

Subsequently, the inverse method is triggered, and the value of `qty_to_order` is set in `qty_to_order_manual`:
https://github.com/odoo/odoo/blob/156bed3f430d706e13822bbd95d91c8dfd3ea42d/addons/stock/models/stock_orderpoint.py#L279-L281

Thus, when the delivery is confirmed, `_compute_qty_to_order` is called again. However, this time, as `qty_to_order_manual` is already set, its value is used instead of recalculating a new value using `_compute_qty_to_order_computed`.

opw-4150572

Forward-Port-Of: odoo/odoo#180951

[FW][FIX] mrp: not unreserve twice during mass production

PR #182302

Core18.0mrp

Original PR description

### Steps to reproduce: - Enable Multi-Step Routes - Inventory > Configuration > Warehouse Management > Warehouses - Change your warehouse settings to Manufacturing in 2 steps - Create a product P…

### Steps to reproduce:

- Enable Multi-Step Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Change your warehouse settings to Manufacturing in 2 steps
- Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable product with 10 units in stock)
- Create and confirm an MO for 10 units of P
- Validate the delivery from stock to pre-production
- Click on `Mass Produce` > `Generate` only 7 SN
- Click No back order (split and generate only 7 MO's)
#### > Looking at the quant of the product you see that 0 units are reserved in pre-production but 7 should be
- validate one of the 7 MO
#### > Looking at the quant of the product you see that -1 units are reserved in pre-production but 6 should be

### Cause of the issue:

By processing the "Mass produce" wizzard you will call the `_assign_serial_numbers` method and hence the `split_productions`: https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/wizard/stock_assign_serial_numbers.py#L65-L68 During this `split_productions` call, the quant reserved quantity will be updated by these lines:
https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/mrp/models/mrp_production.py#L1931-L1938 However, since the stock pocalypse, the quant is already updated once you write and change the quantity of the stock move line of the raw move of the inital MO because of these lines:
https://github.com/odoo/odoo/blob/af4055e2ccce399f94bc465e2dd529c9f14953e0/addons/stock/models/stock_move_line.py#L437-L439 Hence, the `stock.quant` reserved quantity will end up to be updated twice

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

Forward-Port-Of: odoo/odoo#181864
Forward-Port-Of: odoo/odoo#181255

[FW][FIX] mrp: fix _split_productions set consumed_qty 2

PR #182338

Core18.0mrp

Original PR description

### Steps to reproduce:
- Create a product P tracked by serial number with a BOM: - 1 x COMP (a storable prodcut that you do not have in stock)
- Create and confirm an MO for 10 units of P
- Click on the [+] button to generate one serial number of P
> This steps updates the qty_producting to 1 and the set the
consumed_qty of the raw move to 1.
- Click on `Mass Produce` > `Generate` > Apply (to generate the remaining SN)
> This generates 9 backorders each for 1 unit of P with a set SN
#### > However raw moves are **picked with a consumed_qty of 0**

### Cause of the issue:

Since the stockpocalypse commit 7dda6bb the `_split_productions` did not consume quantities anymore. This behavior was fixed by commit 4be8cac for mass production notably by the addittion of these lines: https://github.com/odoo/odoo/blob/6995d65437ba6b2cd0df7503d589260bedcce67d/addons/mrp/models/mrp_production.py#L1879-L1887 However, in our flow, when we assigned the firt serial number by clicking on the [+] button we had set the quantity of the `initial_move` to 1 and associated a `move_line` with the corresponding quantity to it. As such, none of the move line of the raw moves of the back order is going to be created and the issue remains.

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

Forward-Port-Of: odoo/odoo#182216
Forward-Port-Of: odoo/odoo#179062

[FW][FIX] point_of_sale: fix product warning

PR #182171

Core18.0point_of_salepos_self_order

The condition that dictates whether or not the product warning is shown in the product list in pos is inverted. This means that we currently show the product warning when it's not the case. Steps to reproduce: 1. On a db without self order installed, open a pos; 2. Observe that the "info" tags on the corners of the product cards are red; Task: 4214248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181668

Original PR description

The condition that dictates whether or not the product warning is shown in the product list in pos is inverted. This means that we currently show the product warning when it's not the case.

Steps to reproduce:
1. On a db without self order installed, open a pos;
2. Observe that the "info" tags on the corners of the product cards are red;

Task: 4214248




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

Forward-Port-Of: odoo/odoo#181668

[FW][FIX] hr_attendance: Fix overtime computation with adjustments

PR #182324

Core18.0hr_attendance

When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself. Forward-Port-Of: odoo/odoo#181701

Original PR description

When overtime is converted to time off, an hr.attendance.overtime record is created with a negative amount to offset the total overtime amount available with adjustment set to True. Those records should not be taking into account when computing overtime itself.

Forward-Port-Of: odoo/odoo#181701

[FW][FIX] account: no quick encoding on section/note

PR #182346

Core18.0account

Original PR description

**Steps to reproduce:**
- Install Accounting
- Go to Accounting settings
- Set "Quick encoding" to "Customer Invoices and Vendor Bills"
- Create an invoice
- Set "Total (Tax inc.)" to any value
- Add a section and a note
- Check Journal Items

**Issue:**
A tax is set on the section and the note lines.

opw-4204583




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

Forward-Port-Of: odoo/odoo#181519

[FW][FIX] web: Allow users to change reports font size

PR #181903

Core18.0web

Steps: - Install `web_studio` - Open studio - Go to Reports - Create or edit an existing report - Add some text and try to change its size - Preview will display the right size but printed pdf ignores it `wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4). ```css .display-2-fs { font-size: calc(1.575rem + 3.9vw); }

Original PR description

Steps:
    - Install `web_studio`
    - Open studio
    - Go to Reports
    - Create or edit an existing report
    - Add some text and try to change its size
    - Preview will display the right size but printed
        pdf ignores it

`wkhtmltopdf` uses an old version of Webkit which doesn't support CSS3. Since 17.0 we use the new html_editor in our report editor but it uses `display-x-fs` (x is an int from 1 to 4).

```css
.display-2-fs {
  font-size: calc(1.575rem + 3.9vw);
}
```

The problem with this class is the 'calc', which is not supported by the old Webkit version.

see https://github.com/odoo/odoo/issues/136360
https://github.com/wkhtmltopdf/wkhtmltopdf/issues/4092

One solution would be to use the old (hardcoded) bootstrap 4 values in the reports.

opw-3894005

Forward-Port-Of: odoo/odoo#181756

[FW][16.0][REF] stock_account: Add _get_qty_taken_on_candidate()

PR #181666

Core18.0stock_account

This change allows us to practically revive the 'real price' costing method via customization, specifically using the stock_valuation_fifo_lot OCA module. By making `qty_taken_on_candidate` adjustable in the `_run_fifo()` method, we can fine-tune the FIFO calculation to better suit real price costing needs. @qrtl QT4650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180245

Original PR description

This change allows us to practically revive the 'real price' costing
method via customization, specifically using the
stock_valuation_fifo_lot OCA module. By making `qty_taken_on_candidate`
adjustable in the `_run_fifo()` method, we can fine-tune the FIFO
calculation to better suit real price costing needs.

@qrtl QT4650

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

Forward-Port-Of: odoo/odoo#180245

[FW][FIX] mail: 'object-fit: cover' on all persona avatar in discuss

PR #182264

Core18.0mailwebsite_livechat

Without it, images with ratio different than 1 had width or height either shrunk or expanded, which definitely makes these avatar look hideous. This commit fixes most of them. Note that the ones with `.o_avatar` have implicitly `o_object_fit_cover` so this was unnecessary to add them. Before / After <img width="51" alt="Screenshot 2024-10-01 at 00 51 05" src="https://github.com/user-attachments/assets/bee81b6c-b3cc-4610-b855-3a66f6defff9"> <img width="55" alt="Screenshot 2024-10-01 at 00

Original PR description

Without it, images with ratio different than 1 had width or height either shrunk or expanded, which definitely makes these avatar look hideous.

This commit fixes most of them. Note that the ones with `.o_avatar` have implicitly `o_object_fit_cover` so this was unnecessary to add them.

Before / After
<img width="51" alt="Screenshot 2024-10-01 at 00 51 05" src="https://github.com/user-attachments/assets/bee81b6c-b3cc-4610-b855-3a66f6defff9"> <img width="55" alt="Screenshot 2024-10-01 at 00 50 44" src="https://github.com/user-attachments/assets/f3d1937c-3a3a-4a8c-aa01-d91e25bceaac">


Before / After
<img width="1280" alt="Screenshot 2024-10-01 at 00 51 40" src="https://github.com/user-attachments/assets/983aa74f-2904-4037-a373-517b13a014d9">
<img width="1280" alt="Screenshot 2024-10-01 at 00 49 40" src="https://github.com/user-attachments/assets/4227137a-aab4-48be-bbf0-803704cb9575">

Forward-Port-Of: odoo/odoo#182262

[FW][FIX] account: prevent error when duplicating multiple payments

PR #181453

Core18.0account

This Error occurs when a user tries to duplicate multiple payments from the 'Payments' list view. Steps to reproduce: - Install the 'account' module - Go to Invoicing / Customers / Payments and create two payments. - Come to the list view of 'Payments' and duplicate both of them. Traceback: ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5961, in ensure_one _id, = self._ids ValueError: Expected singleton: account.payment(22, 11) File "o

Original PR description

This Error occurs when a user tries to duplicate multiple payments from the 'Payments' list view. Steps to reproduce: - Install the 'account' module - Go to Invoicing / Customers / Payments and…

This Error occurs when a user tries to duplicate multiple payments from the 'Payments' list view.

Steps to reproduce:

- Install the 'account' module
- Go to Invoicing / Customers / Payments and create two payments.
- Come to the list view of 'Payments' and duplicate both of them.

Traceback:
```
ValueError: too many values to unpack (expected 1)
  File "odoo/models.py", line 5961, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: account.payment(22, 11)
  File "odoo/http.py", line 2373, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1903, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1966, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1933, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2177, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 754, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 35, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 459, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/account/models/account_payment.py", line 939, in copy
    if not self.is_internal_transfer:
  File "odoo/fields.py", line 1204, in __get__
    record.ensure_one()
  File "odoo/models.py", line 5964, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

An error occurs at [1], where the system receives multiple records in 'self' as duplicating of multiple payments.

link [1]:https://github.com/odoo/odoo/blob/5e28dcf717a7184f226773b3c84b409da24c1336/addons/account/models/account_payment.py#L939

To resolve this issue, Add a loop to copy multiple records one by one.

Sentry-5689633522

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

Forward-Port-Of: odoo/odoo#176169

[FW][IMP] event{_sale}: improve barcode scanner flow to easily handle larger crowd

PR #181436

Core18.0eventevent_salehr_attendance

**Purpose:** Enhance the barcode scanner interface and optimize the attendee registration process for more efficient handling of large volumes of attendees. **Specifications:** Change barcode scanner template. - Make barcode template same as 'stock_barcode' - Add a dynamic title Modify attendees page. - Remove check/uncheck button - Replace payment status by status - Keep status as a badge - Only keep kanban and list view - When clicking on record, it opens a dialog box same as if

Original PR description

**Purpose:**
Enhance the barcode scanner interface and optimize the attendee registration process for more efficient handling of large volumes of attendees.

**Specifications:**
Change barcode scanner template.
- Make barcode template same as 'stock_barcode'
- Add a dynamic title

Modify attendees page.
- Remove check/uncheck button
- Replace payment status by status
- Keep status as a badge
- Only keep kanban and list view
- When clicking on record, it opens a dialog box same as if barcode is scanned (kanban and list).

Edit the dialog box which opens when user is marked attended.
- Keep status in one line.
- Add an undo button.
- Add Print and Edit buttons in footer which are 'Print Ticket' and 'Open Details' currently.

Removed a kanban view from event_sale module
- 'event_registration_view_kanban' view was no longer needed as replaced 'sales_status' wth 'status'
 
Mockup link: https://app.excalidraw.com/l/65VNwvy7c4X/88aC6OMVygk

Task-4159794

Forward-Port-Of: odoo/odoo#180535

[FW][FIX] stock_dropshipping: wrong vendor selected

PR #182284

Core18.0purchase_stockstock_dropshipping

Original PR description

Steps to reproduce:
- Create a product with 2 vendors:
	- First one: quantity 10, delay 10, price 5
	- Second one: quantity 5, delay 5, price 10
- Select the dropship route on the product
- Create an SO with that product (quantity 5) and confirm it
- Go on the purchase order created

Bug:
The vendor selected is not the correct one (it selects the first one, so the price should be 0, and the delay should be incorrect as well)

Fix:
In https://github.com/odoo/odoo/commit/a35be7b0dd52a5a02b6811cb95ad3189483b7327, the partner passed to _select_seller will always have a value, but an incorrect one for dropshipping routes. The problem resides in https://github.com/odoo/odoo/blob/c04fe54bf45509660ea94a9d7d431c74f1c6023b/addons/product/models/product_product.py#L656. The partner_id is the SO buyer, and it's not possible to have the vendor == to the buyer. It thus default the vendor to the first known vendor which is incorrect.

task-id: 4207060

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

Forward-Port-Of: odoo/odoo#181724
Forward-Port-Of: odoo/odoo#181542

[FW][FIX] product: catalog ux manual edit

PR #182167

Core18.0product

Original PR description

When a user clicks in the catalog record input to change the quantity manually the input content isn't autoselect and the user has to delete the former one to enter the desired value. Autoselecting the value seems more conveniant in the majority of cases.

Also, after one of these edits, if the user click right away in the Back to order button, the redirection to the order form will too fast and it will miss the last edition.

Current behavior before PR:

![Peek 12-09-2024 11-29](https://github.com/user-attachments/assets/7ab2d27a-5fc9-4d0c-af54-4f4bfa33c374)


Desired behavior after PR is merged:

![after](https://github.com/user-attachments/assets/e96f97a4-fb08-4b9f-bf60-45c6e0662210)


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

Forward-Port-Of: odoo/odoo#180003

[FW] PRHOOT 24

PR #182199

Core18.0web

## Pull Request HOOT (PRHOOT) - part 24 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10

Original PR description

## Pull Request HOOT (PRHOOT) - part 24 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…

## Pull Request HOOT (PRHOOT) - part 24

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767
Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895
Part 21: https://github.com/odoo/odoo/pull/174337
Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721
Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728

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.

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

Forward-Port-Of: odoo/odoo#181971

[FW][FIX] website: prevent website search box cache

PR #182267

Core18.0website

Original PR description

__Current behavior before commit:__
When making a search through `/website/search`, the `website_search_box`
view is cached. This includes the search term and the search count.
Therefore when a user makes a search, a previous search term might be
displayed. It may even be a search that another user made.

This bug appeared since the search bar has been added to header
templates [`7559626`][1].

__Description of the fix:__
Add `t-nocache` to the whole searchbox so that the search term and the
search count is updated with each search.

__Steps to reproduce the issue in local:__
(For the issue to appear consistently everytime there should be only a
single worker)
1. Click on the search button in the website header and make a search
2. Do the same thing again with another search
3. Click again on the search button

The previous search term is shown inside the searchbar

opw-4114511

[1]: https://github.com/odoo/odoo/commit/7559626

Forward-Port-Of: odoo/odoo#180548

[FW][FIX] account: keep valid attachments on bill

PR #182247

Core18.0account

Original PR description

To reporoduce:
==============
1. install "l10n_mx"
2. send an email to the vendor bill alias with both XML and PDF attached (use the ones on the ticket)
-> Odoo only retrieves the XML file and PDF is deleted

Problem:
========
when processing the files, `l10n_mx` may set `process_if_existing_lines = True` on some files, if one of these files is processed first, the other files will be ignored then deleted.

Solution:
=========
process all files.

opw-4054484

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

Forward-Port-Of: odoo/odoo#180576

[FW][FIX] repair: not assign repair move to return picking

PR #181850

Core18.0repair

### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t

Original PR description

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

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

Forward-Port-Of: odoo/odoo#180008

[FW][FIX] web: allow drag and drop elements in mass_mailing

PR #182230

Core18.0web

Original PR description

Issue:
======
We can't move elements in mass mailing.

Steps to reproduce the issue:
=============================
- Create a new mass mailing with a template that have some blocks
- Try to drag one of the blocks to another position
- When you click on the button to drag, the right sidebar refreches

Origin of the issue:
====================
The issue was first introduced by [1].

The problem when we have the wysiwyg inside an iframe
`document.activeElement` will be equal to the iframe element and the
`ev.target` is the button of dragging. In reality the button is inside
the iframe but the content of the iframe is like this `<iframe>
document <iframe>` so contains returns false.

Solution:
=========
When the `activeElement` is an iframe we search inside its
`contentDocument`.

opw-4196067

[1]: https://github.com/odoo/odoo/commit/ef97eaf9876bcf1712d4a6bfb91307875b0034ac

Forward-Port-Of: odoo/odoo#181143

[FW][IMP] http: allow deactivating generation of res.device.log per session

PR #182246

Core18.0

In some situations it is useful to avoid generating useless device logs, e.g. for automated technical sessions, platform-generated request, etc. This commit introduces support for a `_trace_disable` session flag to do so. This should never be done without a proper assessment of the consequences for auditability, as seen from the user's point of view. Note that non-admin users have no direct or indirect way to set this flag, so it shouldn't be an extra security risk. Privileged users would

Original PR description

In some situations it is useful to avoid generating useless device logs, e.g. for automated technical sessions, platform-generated request, etc.

This commit introduces support for a `_trace_disable` session flag to do so. This should never be done without a proper assessment of the consequences for auditability, as seen from the user's point of view.

Note that non-admin users have no direct or indirect way to set this flag, so it shouldn't be an extra security risk. Privileged users would have different technical ways to set it, but they could just as easily delete the generated logs or modify them.

Also noteworthy: such sessions will of course still be subject to all other auditing mechanisms (server logs, web proxy logs, metadata tracking on modified records, etc.)

Forward-Port-Of: odoo/odoo#179413

[FW][FIX] mail: allow SA to send emails on any model

PR #182152

Core18.0mailtest_mail

Original PR description

odoo/odoo#114352 add some logic validation to avoid nonsensical configurations that attempt to e.g. add a follower to a model who does not inherit mail.thread

This restriction is a tad too extreme in the case of the 'Send message' action - sending an email is supported on any kind of model as long as the email template supports it.

Task-4203142

Forward-Port-Of: odoo/odoo#181763

[FW][FIX] base: prevent address truncation in PDF documents

PR #182172

Core18.0

Problem: When printing a Sales Order for a partner with a long address, the address is truncated in the generated PDF. Steps to reproduce: - Create a partner with a long address. - Create a Sales Order for that partner. - Print the Sales Order. - In the generated PDF, the partner's address is truncated. opw-4201101 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181525

Original PR description

Problem:
When printing a Sales Order for a partner with a long address, the address is truncated in the generated PDF.

Steps to reproduce:
- Create a partner with a long address.
- Create a Sales Order for that partner.
- Print the Sales Order.
- In the generated PDF, the partner's address is truncated.

opw-4201101

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

Forward-Port-Of: odoo/odoo#181525

[FW][FIX] sale: price rules form behavior

PR #182250

Core18.0product

Original PR description

Steps :
- Set the company of the first pricelist in list view to false
- Create a product and set it's company and the go to extra price tab and group by product
- Now when adding a new, opens form view, try saving the record

Issue :
Returns a warning message not allowing to save

Cause :
The company for pricelist that is default selected and the product have different companies

Fix :
Updated the action so that it does not open form view as the pricelist tree view is multi-edit

opw-3943830

Forward-Port-Of: odoo/odoo#171032

[FW][FIX] survey: hide test warning banner on survey results

PR #182211

Core18.0survey

Steps to reproduce: - Survey > New > Tick 'Survey' - Create a question - Test > Complete the survey - Edit survey > See results The banner displays 'This is a test survey entry', despite no longer being in the test. The condition to display this text was removed in c983f8a5343ac623ebc9d6dbddc506db4079ee5e but it is still relevant here. opw-4160109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182103 Forward-Port

Original PR description

Steps to reproduce:
- Survey > New > Tick 'Survey'
- Create a question
- Test > Complete the survey
- Edit survey > See results

The banner displays 'This is a test survey entry', despite no longer being in the test. The condition to display this text was removed in c983f8a5343ac623ebc9d6dbddc506db4079ee5e but it is still relevant here.

opw-4160109

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

Forward-Port-Of: odoo/odoo#182103
Forward-Port-Of: odoo/odoo#179726

[FW][FIX] *: fix some broken tests

PR #71238

Enterprise18.0

Forward-Port-Of: odoo/enterprise#70302

Original PR description

Forward-Port-Of: odoo/enterprise#70302

[FW][FIX] timesheet_grid: remove stray test display

PR #71233

Enterprise18.0

Steps to reproduce: - Timesheet > Register time for any task The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here. I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96 opw-4123649 Forward-Port-Of: odoo/enterprise#71174

Original PR description

Steps to reproduce:
- Timesheet > Register time for any task

The display of time spent on the task also contains the diff with the expected time for the day, which should not be displayed here.

I mistakenly left in a display meant for testing purposes only added in commit 56c7e8ccf5eb92baee258842fe72efa3d1956b96

opw-4123649

Forward-Port-Of: odoo/enterprise#71174

[FW][REF] industry_fsm_sale: add hook for inheritance of so values

PR #71065

Enterprise18.0

before this commit, if user need to pass any different value to the sale order creation, there is no direct hook available to do the same after this commit, this hook can be used to pass any value or to modify any existing value passed to the create method Forward-Port-Of: odoo/enterprise#70961 Forward-Port-Of: odoo/enterprise#70151

Original PR description

before this commit, if user need to pass any different value to the sale order creation, there is no direct hook available to do the same

after this commit, this hook can be used to pass any value or to modify any existing value passed to the create method

Forward-Port-Of: odoo/enterprise#70961
Forward-Port-Of: odoo/enterprise#70151

[FW][FIX] sale_planning: fix Schedule by Sales Order menu visible to planning users

PR #71097

Enterprise18.0

Before: The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights. After: The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights. Fix: Add the user group so that the menu will now be visible based on the user's access rights. Task:4192098 Forward-Port-Of: odoo/enterprise#70331

Original PR description

Before:
The Schedule by Sales Order menu was not visible to planning users, even if they had the necessary access rights.

After:
The Schedule by Sales Order menu is now visible to planning users who have the appropriate access rights.

Fix:
Add the user group so that the menu will now be visible based on the user's access rights.

Task:4192098

Forward-Port-Of: odoo/enterprise#70331

[FW][FIX] spreadsheet_dashboard_documents: tour wasn't run

PR #71198

Enterprise18.0

The tour `spreadsheet_dashboard_document_add_document_to_dashboard_group` was never actually run because the python method wasn't prefixed by `test_`. The toru was also broken since we allowed to create a dashboard based on a new spreadsheet. Task: [4199036](https://www.odoo.com/web#id=4199036&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#71142 Forward-Port-Of: odoo/enterprise#70355

Original PR description

The tour `spreadsheet_dashboard_document_add_document_to_dashboard_group` was never actually run because the python method wasn't prefixed by `test_`. The toru was also broken since we allowed to create a dashboard based on a new spreadsheet.

Task: [4199036](https://www.odoo.com/web#id=4199036&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#71142
Forward-Port-Of: odoo/enterprise#70355

[FW][FIX] {appointment}_hr: traceback on duplicating the appointment

PR #71192

Enterprise18.0

Before this PR When multiple appointments are selected and duplicated a traceback occurs. **Technical** **_get_default_range_slots** method in appointment_hr expects single record, so when appointment_hr is installed and try to duplicate the record singelton traceback occurs. After this PR Without any traceback, appointments can be duplicated. Task-4210180 Forward-Port-Of: odoo/enterprise#70537

Original PR description

Before this PR
When multiple appointments are selected and duplicated a traceback occurs.

**Technical**
**_get_default_range_slots** method in appointment_hr expects single record,
so when appointment_hr is installed and try to duplicate the record
singelton traceback occurs.

After this PR
Without any traceback, appointments can be duplicated.

Task-4210180

Forward-Port-Of: odoo/enterprise#70537

[FW][FIX] industry_fsm: fix tour display for customer selection field

PR #70941

Enterprise18.0

Before this PR: - The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action. - As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`. - So, the customer selection step was not properly highlighted or explained. After this PR: - Added `content` and `position` attributes to the child step triggered by `.o_field_w

Original PR description

Before this PR:
- The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action.
- As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`.
- So, the customer selection step was not properly highlighted or explained.

After this PR:
- Added `content` and `position` attributes to the child step triggered by `.o_field_widget[name="partner_id"] input`, ensuring the tooltip appears with the correct message and placement.
- The step now properly displays the tooltip when the customer selection field is focused.

task-4159812

Forward-Port-Of: odoo/enterprise#69768

[FW][FIX] account_accountant: bank account creation

PR #70832

Enterprise18.0

Create a bank statement line with: - Label - No partner - Bank Account number [BNK1] - Amount Go to reconciliation widget Reconcile with a manual statement having partner [TEST] [BNK1] will be added to the bank accounts of [TEST] Repeat the steaps with another account [BNK2] Issue: [BNK2] will not be added to the bank accounts of [TEST] This occurs because, when validating a statement line, we don't add a new bank account to the partner if there is already one defined opw-4

Original PR description

Create a bank statement line with:
- Label
- No partner
- Bank Account number [BNK1]
- Amount

Go to reconciliation widget
Reconcile with a manual statement having partner [TEST]
[BNK1] will be added to the bank accounts of [TEST]
Repeat the steaps with another account [BNK2]

Issue: [BNK2] will not be added to the bank accounts of [TEST]

This occurs because, when validating a statement line, we don't
add a new bank account to the partner if there is already one defined


opw-4145124

Forward-Port-Of: odoo/enterprise#69658

[FW][FIX] {,l10n_be_}hr_payroll: Explicitly reset `is_unforeseen`

PR #71162

Enterprise18.0

The definition of the records `hr_payroll.hr_work_entry_type_out_of_contract` and `l10n_be_hr_payroll.work_entry_type_partial_incapacity` reset the field `is_leave` to False, but not the field `is_unforeseen`. Because of the constraint `is_unforeseen_is_leave`, if `is_unforeseen` had been previously set as True, when the record gets updated (eg during an upgrade), only one of the fields gets changed and it will trigger the constraint. Steps to reproduce: - Edit 'Out of Contract' work entr

Original PR description

The definition of the records `hr_payroll.hr_work_entry_type_out_of_contract` and `l10n_be_hr_payroll.work_entry_type_partial_incapacity` reset the field `is_leave` to False, but not the field `is_unforeseen`.

Because of the constraint `is_unforeseen_is_leave`, if `is_unforeseen` had been previously set as True, when the record gets updated (eg during an upgrade), only one of the fields gets changed and it will trigger the constraint.

Steps to reproduce:
- Edit 'Out of Contract' work entry type and set Time Off and Unforeseen Absence as True.
- Upgrade to the next version.

Forward-Port-Of: odoo/enterprise#70104

[FW][FIX] helpdesk: merge duplicate help ticket sla

PR #70946

Enterprise18.0

Coupled with [53d6c3492ec977e4588ee734f3c3a7f06534687a](https://github.com/odoo/odoo/pull/179266/commits/53d6c3492ec977e4588ee734f3c3a7f06534687a) Steps to reproduce: - Helpdesk > Configuration > SLA policies - Create one if necessary or use existing - Helpdesk > Tickets > Create - Configure it so that it corresponds to SLA requirements - Duplicate the ticket and merge them both (data_merge module required) Currently helpdesk ticket uses the default merge fuction, which simply concate

Original PR description

Coupled with [53d6c3492ec977e4588ee734f3c3a7f06534687a](https://github.com/odoo/odoo/pull/179266/commits/53d6c3492ec977e4588ee734f3c3a7f06534687a)

Steps to reproduce:
- Helpdesk > Configuration > SLA policies
- Create one if necessary or use existing
- Helpdesk > Tickets > Create
- Configure it so that it corresponds to SLA requirements
- Duplicate the ticket and merge them both (data_merge module required)

Currently helpdesk ticket uses the default merge fuction, which simply concatenates the values of merged records. This causes a few strange things to happen:

1. sla_ids which registers SLA policy types, has duplicate entries. This recordset should remain a set.

2. Followers of the merged tickets are sometimes not added to the resulting record. The default merge simply swaps the resource id with no regard for a possible duplication of unique key (res_model, res_id, partner_id), which causes the transaction to fail on repeat followers. This is a common problem with every record inheriting mail.thread which does not define its own merge function as well.

3. Keeping every SLA status record is redundant, merging tickets makes it impossbile to keep track of which task each deadline was originally related to anyway. Hence why we only keep those with the shortest deadline for each type. Priority is not a concern here since SLA policies are recomputed according to a ticket's priority rating, so we cannot have 2 SLAs with the same policy and different priorities.

opw-4037262

Forward-Port-Of: odoo/enterprise#69352

[FW][FIX] l10n_ch_hr_payroll_elm: Make IJM and LAAC Position Agnostic

PR #71121

Enterprise18.0

Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore. Forward-Port-Of: odoo/enterprise#71075 Forward-Port-Of: odoo/enterprise#71012

Original PR description

Currently, order of Many2many insurance_line_ids matters for IJM and LAAC, which can be error prone in the case where you go from example from 2 solutions -> 11,12 to one solution -> 12, the cumulated salaries will not be computed properly in this case. 

We make the rules Position aware in this PR, meaning that order or quantity of solutions in the contract does not matter anymore.

Forward-Port-Of: odoo/enterprise#71075
Forward-Port-Of: odoo/enterprise#71012

[FW][FIX] planning: fixed the group_expand not working as expected

PR #71109

Enterprise18.0

Steps to Reproduce: - Open the planning app. - Create a planning for a resource. - Make sure resource doesn't have any past or future plannings. - Change the time frame to next week. Issue: - We don't see an empty line. Reason: In the PR https://github.com/odoo/enterprise/pull/55618. All the gantt time ranges have domain strictly comparative operators(> and <). But in group_expand_resource_ids we use non strict comparative operators(>= and <=). Fix: - Added strictly comp

Original PR description

Steps to Reproduce:

- Open the planning app.
- Create a planning for a resource.
- Make sure resource doesn't have any past or future plannings.
- Change the time frame to next week.

Issue:

- We don't see an empty line.

Reason:

In the PR https://github.com/odoo/enterprise/pull/55618. All the gantt time ranges have domain strictly comparative operators(> and <).  But in group_expand_resource_ids we use non strict comparative operators(>= and <=).

Fix:

- Added strictly comparative operators into operators being checked.

task-4188936

Forward-Port-Of: odoo/enterprise#70454

[FW][IMP] l10n_mx_edi: display fiscal folio for vendors and payments

PR #70971

Enterprise18.0

Allow viewing the fiscal folio for vendor invoices and all payments in the tree view, as it currently only displays for customer invoices. Related https://github.com/odoo/enterprise/pull/69359 Forward-Port-Of: odoo/enterprise#70698

Original PR description

Allow viewing the fiscal folio for vendor invoices and all payments in the tree view, as it currently only displays for customer invoices.

Related https://github.com/odoo/enterprise/pull/69359

Forward-Port-Of: odoo/enterprise#70698

[FW][FIX] industry_fsm : Add AM or PM when having 12-hour time format

PR #71132

Enterprise18.0

### Steps to reproduce: - Install Field Service module - Set 12-hour time format in the languages - Navigate to My tasks kanban view in Field Service ### Current behavior before PR: When having 12-hour time format for Field Service it will be shown in the kanban view as '02:00 A' for example. This is happening because when formatting the time in the fsm_date widget the format we are using have a typo 'hh:mm A' where the 'AM, PM' should be represented with lowercase 'a' not uppercase 'A

Original PR description

### Steps to reproduce:
	- Install Field Service module
	- Set 12-hour time format in the languages
	- Navigate to My tasks kanban view in Field Service

### Current behavior before PR:
When having 12-hour time format for Field Service it will be shown in the kanban view as '02:00 A' for example. This is happening because when formatting the time in the fsm_date widget the format we are using have a typo 'hh:mm A' where the 'AM, PM' should be represented with lowercase 'a' not uppercase 'A'

### Desired behavior after PR is merged:
Fixed the typo and added the correct format

opw-4178726

Forward-Port-Of: odoo/enterprise#70922
Forward-Port-Of: odoo/enterprise#70250

[FW][FIX] l10n_mx_edi: nombre and regimen fiscal of branch

PR #70688

Enterprise18.0

With an MX company setup Create a branch Change the fiscal regime of the branch to Arrendamiento (606). With the branch create an invoice and generate the CFDI Issues: - Regimen Fiscal in CFDI is set to the one of the parent company while it should be the one of the branch - When a PAC certificate is registered in the branch, company name in CFDI will be the branch name while it should always be the root company name opw-4097669 Forward-Port-Of: odoo/enterprise#70451 Forward-Port-O

Original PR description

With an MX company setup
Create a branch
Change the fiscal regime of the branch to Arrendamiento (606).
With the branch create an invoice and generate the CFDI

Issues:
- Regimen Fiscal in CFDI is set to the one of the parent
company while it should be the one of the branch
- When a PAC certificate is registered in the branch, company name in CFDI
will be the branch name while it should always be the root company name

opw-4097669

Forward-Port-Of: odoo/enterprise#70451
Forward-Port-Of: odoo/enterprise#69411

[FW][FIX] l10n_ke_edi_oscu_stock: allow negative qty subcontracting location

PR #70945

Enterprise18.0

Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior - Component: - C1: - Routes: “Resupply Subcontractor on Order” - Create a purchase order for one unit of “P1” - Confirm the PO - Create a second PO for one unit of “C1” and receive it - Confirm the resupply picking of C1 - Confirm the receipt of P1 **Problem:** A validation error is

Original PR description

Steps to reproduce the bug: - Log in as a Kenyan company - Create a storable product “P1” with the following Bill of Materials (BoM): - Type: Subcontracting - Subcontractor: Azure Interior -…

Steps to reproduce the bug:
- Log in as a Kenyan company
- Create a storable product “P1” with the following Bill of Materials (BoM):
  - Type: Subcontracting
  - Subcontractor: Azure Interior
  - Component:
    - C1: - Routes: “Resupply Subcontractor on Order”

- Create a purchase order for one unit of “P1”
- Confirm the PO
- Create a second PO for one unit of “C1” and receive it
- Confirm the resupply picking of C1
- Confirm the receipt of P1

**Problem:**
A validation error is triggered: “You cannot end up with a negative stock quantity.”

We added a constraint to prevent negative stock quantities in internal locations for a company in Kenya. However, the location linked to subcontracting is internal but has no warehouse, so we don’t care if its quantity is negative, and it should be ignored. This could also happen with other internal locations that don’t have a warehouse.

Additionally, when reporting stock quantities, we only consider
quantities in locations that have a warehouse:
https://github.com/odoo/enterprise/blob/9dea0f2696084235ee1192b0a14adfa43eb732ef/l10n_ke_edi_oscu_stock/models/product.py#L47


opw-4184857

Forward-Port-Of: odoo/enterprise#70808

[FW][FIX] planning, sale_planning: regenerate recurring slots from origin

PR #71051

Enterprise18.0

Steps to reproduce: - Planning > Configuration > Employees > New - Schedule > By resource > Filter for your employee - Click on the employee's Gantt line and assign a shift - Click the shift > Edit > Click the looping arrow next to date - Your shift should now be recurring over the coming weeks - Go to the 2nd week > Edit the shift's end date - Check 'All shifts' at the top and save There are 2 issues here: 1. A MissingError is raised 2. Even when bypassing that error, the planning i

Original PR description

Steps to reproduce:
- Planning > Configuration > Employees > New
- Schedule > By resource > Filter for your employee
- Click on the employee's Gantt line and assign a shift
- Click the shift > Edit > Click the looping arrow next to date
- Your shift should now be recurring over the coming weeks
- Go to the 2nd week > Edit the shift's end date
- Check 'All shifts' at the top and save

There are 2 issues here:
1. A MissingError is raised
2. Even when bypassing that error, the planning is regenerating the slots from the original slot's start date to the 2nd slot's end date. (i.e. for a weekly recurrence you will now have 2 week long slots instead of the expected 1 week)

Both happen because when editing the start/end date of a recurring shift we simply unlink the existing ones and regenerate them from the original slot. Since they are unlinked we can no longer access the shift we were trying to edit (the 2nd occurrence) resulting in the MissingError. And because we regenerate from the first slot despite taking values from the second, we stretch the original slot, which is repercuted on every subsequently generated slot's dates.

opw-4154647

Forward-Port-Of: odoo/enterprise#70292

[FW][FIX] l10n_mx_hr_payroll: compute paid amount correctly

PR #71154

Enterprise18.0

Issue: ====== `paid_amount` is not calculated correctly when the schedule pay isn't month. Steps to reproduce the issue: ============================= - Switch to MX company - Go to roque and employee and add these values to his contract : salary structure type( Mexico:Employee) - both schedule pay fields (weekly) - add any amount in wage. - Go to payslips and create one for roque and click on compute sheet - Go to salary computation tab - Basic salary is wrong it should be the amount

Original PR description

Issue:
======
`paid_amount` is not calculated correctly when the schedule pay isn't month.

Steps to reproduce the issue:
=============================
- Switch to MX company
- Go to roque and employee and add these values to his contract : salary structure type( Mexico:Employee) - both schedule pay fields (weekly) - add any amount in wage.
- Go to payslips and create one for roque and click on compute sheet
- Go to salary computation tab
- Basic salary is wrong it should be the amount you put at the start.

Origin of the issue and solution:
=================================
We were dividing by the coefficient of the pay schedule but in reality we didn't have to since we create the payslip for the period of the schedule pay so it will have the full mentioned wage.

But for the christmas we need to divide by the coefficient since it's computed by `days/year`.

opw-413332

Forward-Port-Of: odoo/enterprise#70136

[FW][FIX] repair: not assign repair move to return picking

PR #70901

Enterprise18.0

Original PR description

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

opw-4159779

Forward-Port-Of: odoo/enterprise#70748
Forward-Port-Of: odoo/enterprise#69936

[FW][FIX] sign: restore sign placeholder field formatting

PR #71098

Enterprise18.0

Steps to reproduce: - Sign > Edit any template > Add a field - Click your field > Select left alignment > Validate The placeholder text overlaps with the arrow block, in 16.0 this does not occur. The culprit is the ps-0 class added to signItem which removes all padding from the block. The formatting was changed in f1b35ae9030ff82afc498bfbd6315414407bb4e1 to make it consistent between the other views (The shift is kept even the move icon is not visible) but the alignment feels consistent

Original PR description

Steps to reproduce:
- Sign > Edit any template > Add a field
- Click your field > Select left alignment > Validate

The placeholder text overlaps with the arrow block, in 16.0 this does not occur. The culprit is the ps-0 class added to signItem which removes all padding from the block.

The formatting was changed in f1b35ae9030ff82afc498bfbd6315414407bb4e1 to make it consistent between the other views (The shift is kept even the move icon is not visible) but the alignment feels consistent even without this class.

opw-4159676

Forward-Port-Of: odoo/enterprise#70307

[FW][FIX] account_reports: prevent modification of dict during iteration

PR #70944

Enterprise18.0

The `RuntimeError: dictionary changed size during iteration` occurred in the `_generate_tax_closing_entries` method when iterating over the `closing_moves_by_company` dictionary. This happened because accessing a key in a `defaultdict` that doesn't exist automatically creates that key with a default value. Specifically, the line: ```py if from_post and move == closing_moves_by_company[self.env.company]: ``` triggered the insertion of a new key when `self.env.company` was not already present,

Original PR description

The `RuntimeError: dictionary changed size during iteration` occurred in the `_generate_tax_closing_entries` method when iterating over the `closing_moves_by_company` dictionary. This happened because accessing a key in a `defaultdict` that doesn't exist automatically creates that key with a default value. Specifically, the line:
```py
if from_post and move == closing_moves_by_company[self.env.company]:
```
triggered the insertion of a new key when `self.env.company` was not already present, leading to the runtime error.

This commit changes the access method to use `.get()` instead of directly accessing the key allowing, safe retrieval of the value without modifying the dictionary.

opw-4089738

Forward-Port-Of: odoo/enterprise#70500

[FW][FIX] l10n_fr_reports: show EC Sales List for France

PR #71118

Enterprise18.0

Currently the EC Sales List menuitem is not visible when only installing `l10n_fr_reports` (and no other localization activating the item). To reproduce it you need to install `l10n_fr_reports` on a database where the item is not already visible. (It does not work on the runbot.) Forward-Port-Of: odoo/enterprise#71021 Forward-Port-Of: odoo/enterprise#70723

Original PR description

Currently the EC Sales List menuitem is not visible when only installing `l10n_fr_reports` (and no other localization activating the item).

To reproduce it you need to install `l10n_fr_reports` on a database where the item is not already visible. (It does not work on the runbot.)

Forward-Port-Of: odoo/enterprise#71021
Forward-Port-Of: odoo/enterprise#70723

[FW][FIX] l10n_ch_hr_payroll_elm: correct insurance threshold fallback

PR #71122

Enterprise18.0

Steps to reproduce: - Intall Payroll and Switzerland localization > Switch to CH company - Employees > New > Work Information tab > Set any Canton - Create a contract for that employee > Set it to 'Running' state - Payroll > Work Entries > Work Entries > Remove filters - Navigate to next month > Regenerate Work Entries - Generate Payslips > Error is raised This error is raised because the fallback value in _get_ac_threshold is 0, 0 instead of being a float (same as the otherwise returne

Original PR description

Steps to reproduce:
- Intall Payroll and Switzerland localization > Switch to CH company
- Employees > New > Work Information tab > Set any Canton
- Create a contract for that employee > Set it to 'Running' state
- Payroll > Work Entries > Work Entries > Remove filters
- Navigate to next month > Regenerate Work Entries
- Generate Payslips > Error is raised

This error is raised because the fallback value in _get_ac_threshold is 0, 0 instead of being a float (same as the otherwise returned line.amount). This was most likely just a typo using the wrong decimal separator which turned th fallback into a tuple, breaking on the following operations.

opw-4204580

Forward-Port-Of: odoo/enterprise#71071
Forward-Port-Of: odoo/enterprise#70751

Rows:Rows per page:

10 25 50 100

1 / 2Page 1 of 2 · 168 days total