Daily updates from Odoo
Wednesday, September 10, 2025
32 changes · saas-18.3
Enhancements to existing features
The invoice form now shows a helpful placeholder for the Incoterm field based on the company’s default setting. If no default Incoterm is configured, users still see clear guidance text, making data entry easier and more consistent.
Original PR description
This commit adds a dynamic placeholder to incoterm field form view in `account.move`. The placeholder is dynamically set as the default incoterm value in setting. If no default is chosen, a default text is shown. task-4788236 Current behavior before PR: No placeholder is set to incoterm field in account move form view. Desired behavior after PR is merged: Dynamic placeholder set to incoterm field in account move form view with default incoterm value chosen in setting. If no default incoterm is chosen, a default text placeholder is shown. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol registration wizard now includes more helpful explanations for certain company information fields. This helps users understand why the requested details are needed and reduces confusion during electronic invoicing setup.
Original PR description
…ion wizard. Give move information on what the registration information are used for. task-none Forward-Port-Of: odoo/odoo#225730
Mexican CFDI e-invoices are now generated from invoice lines in the same way the SAT validates them, reducing the risk of rejection due to rounding or total mismatches. Any small difference from the original document is handled through discounts where possible, or by adding an adjustment line when needed.
Original PR description
Simplify the CFDI generation. Now the totals are always computed from the lines. That way, it's impossible for the SAT to refuse a CFDI since it's built in the way the SAT checks the validity of the file. The difference between the CFDI total and the original documents is put using the discount if available. If not, we add a fake line in the CFDI. task-id: 4926200
IoT boxes now receive a clear unauthorized error when they try to download drivers but are not recognized by the database. This makes connection or setup issues easier to diagnose instead of failing with an unclear empty response.
Original PR description
When an iot box tries to download drivers from the database, but the db doesn't have a record corresponding to the IoT Box, the IoT Box receives an empty string, making it hard to debug why it couldn't download handlers. We now raise an unauthorized error to make it clearer. Forward-Port-Of: odoo/enterprise#93813
Users with Invoicing & Banks access can now start an online bank synchronization when a bank journal is configured for online feeds and not yet connected. This makes bank connection setup available to the right finance users directly from the journal dashboard, reducing reliance on higher-access users.
Original PR description
Before this commit: - Users with "Invoicing & Banks" access rights could not create a bank synchronization, and the "Connect Bank" button was not visible. After this commit: - Users with "Invoicing & Banks" access rights can now create a bank synchronization if the journal has "Bank Feeds = Online Synchronization" and the bank is not yet connected. - The "Connect Bank" button is now visible to them. task-4840544 Forward-Port-Of: odoo/enterprise#87408
Resolved issues and error corrections
The editor now adds a blank paragraph before inserted items like banners or tables of contents so they do not block full-content deletion. This prevents users from being unable to clear an editable area when selecting everything and pressing backspace.
Original PR description
**Current behavior before PR:** If the first child of an editable element was `contenteditable="false"`, selecting all content and pressing backspace would not remove everything. This was due to a Chromium bug where non-editable elements as the first child are not fully selected. **Desired behavior after PR is merged:** When inserting elements such as a banner or table of contents, a paragraph is added before them. This ensures that the editable element never starts with a non-editable child. task: 5010666
This update improves Odoo's internal Hoot testing framework by making test runs faster, clearer, and easier to diagnose. It is limited to unit test infrastructure, reducing risk to normal product behavior while helping developers catch issues more efficiently.
Original PR description
## Pull Request HOOT (PRHOOT) 36 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. Enterprise: https://github.com/odoo/enterprise/pull/93167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225598 Forward-Port-Of: odoo/odoo#221367
Point of Sale cash out receipts now print correctly when using printers connected through the hardware proxy. This prevents staff from seeing a successful cash-out message while the receipt silently fails to print.
Original PR description
When the printer comes form the hardware_proxy, the receipt was not printing for a cash out. Steps to reproduce: ------------------- * Connect an ePos printer * Open pos * Create and validate a cash out > Observation: Notification says 'Succesfully...' Console log says 'No printer device available...' Why the fix: ------------ Introduced by this pr: https://github.com/odoo/odoo/pull/209274 This protection wasn't working for our usecase where the device is set after this check in this call `this.printHtml(el, options)`. A hoot test will be added during fw-port in 18.3 opw-4841441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222155
Italian delivery transport documents now show each line total using the same amount as the related sale order. This prevents small rounding differences when discounts or taxes affect the sale price, improving consistency for printed delivery documents.
Original PR description
#### Issue: In the DDT Report, the value displayed on each line is the rounded value of one unit multiplied by the number of unit. Therefore, the amount on a line differ from the real value. ####…
#### Issue: In the DDT Report, the value displayed on each line is the rounded value of one unit multiplied by the number of unit. Therefore, the amount on a line differ from the real value. #### Step to reproduce: - in an Italian company - create a sale order with a product - confirm it - go to delivery - validate the delivery - print #### Current behavior: On the DDT report, the value of each line is the rounded value of one unit multiplied by the number of unit. #### Expected behavior: On the DDT report, the value of each line should be the same as in the sale order. #### Cause of the issue: The value of a line was miscalculated based on the rounded price of a unit. #### Solution: This error occurs when a calculation is applied to the sale price, such as a tax or a discount. This applies for deliveries coming from sale orders. These calculations are included in the `price_total` field of the corresponding line in the SO. opw-5012921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents invoice creation from crashing when a company has no country set and VAT number verification is enabled. The system now safely handles missing company country information, helping users continue invoicing even if company setup data is incomplete.
Original PR description
The system crashes with an error when a user tries to create an invoice. **Steps to produce:-** - Install `Accounting` module and switch to `BE Company`. - Go to `Settings > Users & Companies >…
The system crashes with an error when a user tries to create an invoice.
**Steps to produce:-**
- Install `Accounting` module and switch to `BE Company`.
- Go to `Settings > Users & Companies > Companies` and remove the country from the BE company.
- Create a new customer with:-
- Country as `Belgium`.
- Tax ID as `DE123456788`.
- `Accounting > configuration > settings > enable Verify VAT Numbers`.
- Now try to make `invoice` with customer as previously created customer.
**Error:-**
`TypeError : argument of type 'bool' is not iterable`
**Root cause:-**
- At [1], the code attempts to access `company.country_id`, but since the country was manually removed from the company, it evaluates to null record, leading to the error.
**Solution:-**
- Add a safeguard to ensure `company.country_id` also exist before accessing `country_group_codes`.
[1] -https://github.com/odoo/odoo/blob/4c2330f3cc0d1a0046e28d351f894763aeea57d2/addons/base_vat/models/res_partner.py#L764
**sentry-6851141424**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix makes Discuss command palette tests more stable by ensuring the interface is ready before simulated clicks happen. It also corrects a search mock and an incomplete test, reducing false failures in automated validation without changing customer-facing functionality.
Original PR description
Before this commit, clicking on some elements of the command palette would not trigger the associated event, this was probably caused by clicking on outdated owl fragments which cannot trigger events while being destroyed. This commit fixes this issue by making sure that the interface is in a stable configuration before clicking. The commit also fixes the mock of `discuss/search` ( for https://github.com/odoo/enterprise/pull/94075 ) and a test that was incomplete and relied on the incorrect implementation https://runbot.odoo.com/odoo/runbot.build.error/112148 Forward-Port-Of: odoo/odoo#225844
Fixes an issue where unbuilding manufacturing orders for non-storable finished products or by-products could create duplicate product movement records. This keeps inventory and manufacturing records accurate and avoids confusion when reviewing unbuild operations.
Original PR description
When creating a unbuild order for non storable product, it will generate two stock.move.line going form Stock>Production. ** Steps to reproduce ** - Create an untracked product (is_storable = False).…
When creating a unbuild order for non storable product, it will generate two stock.move.line going form Stock>Production.
** Steps to reproduce **
- Create an untracked product (is_storable = False).
- Create a BOM (the components don't matter).
- Create a manufacturing order & produce it for the untracked product.
- Unbuild the manufacturing order.
- Manufacturing Order> Unbuilds>(Select the Unbuild (UB/...))>Product Moves
- Two move lines are created from stock to production for the untracked product when only one should have been created.
** Cause of the issue **
Clicking on unbuild, will launch a call of the action_unbuild method. During this call,
the moves of the unbuild for the final product of the MO are created and confirmed here:
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/mrp/models/mrp_unbuild.py#L181-L182
During this confirmation process and since the product is not storable, (hence move should by pass reservation) therse moves will be assigned and the related move line created:
https://github.com/odoo/odoo/blob/e4d9ef3f39bd62a8db6854270b4cf6a35936b8d4/addons/stock/models/stock_move.py#L1759-L1762
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/stock/models/stock_move.py#L1581-L1583
However, in the rest of the action_unbuild call, since we don't expect the move to be assigned by the action_confirm we create and associate manually a second move line to our unbuild move:
https://github.com/odoo/odoo/blob/de2216ae52cee40d0851b4b8c0b71cb7e1d5ec89/addons/mrp/models/mrp_unbuild.py#L196-L198
** Observation **
During this commit
https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-31912cb536cbf184f8f475ccdfb5e42c30796a3f0430eea35751519434a67ba8L156
An "if condition" was removed that allowed untracked product to skip the manual assignation ("consu" product are untracked), since they already been assigned during consume_move._action_confirm().
This fix reintroduce the condition, for all move with their quantity (1) updated.
Which resolve the issue for non stored product since their quantity is updated during _action_confirmation>_action_assign
(1) https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR325
opw-4830965
Forward-Port-Of: odoo/odoo#213305Invoices created for a child contact now use the invoice sending method configured on the parent company contact. This prevents invoices from being sent by email when the customer is set up to receive them through Peppol, improving billing accuracy for grouped customer contacts.
Original PR description
**Steps to reproduce** - Have a partner with Invoice Sending configured 'by Peppol' - Create a child contact for that partner - Make 2 invoices for the child contact - Select both and click 'Send' **Issue** The system will try to send invoice by mail, even if Peppol is correctly setup This occurs because when retrieving the default sending method we only look at the partner of the move, that, being a child contact, does not have invoicing info opw-4925876 Forward-Port-Of: odoo/odoo#225725 Forward-Port-Of: odoo/odoo#225097
Kiosk ordering now only shows online payment methods that have been configured for that kiosk. This prevents customers from choosing unsupported payment options that could mark an order as paid without properly progressing it through preparation workflows.
Original PR description
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are…
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend. Steps to reproduce: ------------------- * Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup * Create an online payment method (use demo for example) * Change the kiosk settings to use those two payment methods * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The fix to send the order to the backend is in the other part of this fix. Here we decide to only allow to use the online payment methods that have been set on the config. Previously if two were existing but only one setup you were able to select any of them. We also make a change to the `filterPaymentMethods` method. This method is called when pressing the pay button and is indirectly responsible for the fact that if there's only one payment method then we directly start the payment process. Prior to this fix if we only had a terminal method setup and clicked to pay an order we directly had the screen telling us to follow the instructions on the terminal. However if we only had a online payment method, when clicking on pay, we would directly have the screen prompting us to pay at the register, we could never select the payment method. With the fix, when there's only one payment method and it's online, clicking on pay will show the qr code. opw-5001998 Enterprise: https://github.com/odoo/enterprise/pull/92825 Forward-Port-Of: odoo/odoo#224755 Forward-Port-Of: odoo/odoo#223689
When receipt items are moved into a new wave or picking, their related quality checks now move with them or are recreated for the correct transfer. This prevents staff from missing required quality checks on the new transfer or completing them from the wrong receipt.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Enterprise: https://github.com/odoo/enterprise/pull/92951
opw-5009635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224947
Forward-Port-Of: odoo/odoo#223852Updating the memo on an accounting payment now also updates the reference on its linked journal entry. This keeps payment records consistent and avoids confusion when reviewing or reconciling accounting entries.
Original PR description
Issue: In previous versions, the memo field of account payments and ref field of account move were related Now that payments do not required to have generated account move's when the memo is updated the ref remains unchanged. Purpose of this PR: To update the account move ref when the payment memo is updated. Steps to Reproduce on Runbot: install accounting go to bank account and assign outstanding accounts for manual payment methods create a payment -- a related account move should be created update the memo on the payment -- the ref on the related account move is unchanged. opw-4989260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223459
The Print button on purchase orders now chooses the correct document based on the order status. Confirmed orders print the Purchase Order report instead of the earlier RFQ document, reducing confusion and helping users send the right paperwork.
Original PR description
Before this commit: ------------------------- - The 'Print' button in the Purchase Order form always triggered the RFQ report, regardless of the order state. - This caused confusion for users…
Before this commit: ------------------------- - The 'Print' button in the Purchase Order form always triggered the RFQ report, regardless of the order state. - This caused confusion for users expecting the Purchase Order report when the order was already confirmed. Steps to reproduce: ------------------------- 1. Install 'purhcase' module. 2. Confirm a purchase order (move it to the 'Purchase Order' state). 3. Click on 'Print' button . 4. Notice that the RFQ report is printed instead of the PO report. Cause of the issue ------------------------- - The print button was hardcoded to always prints the RFQ report—even for confirmed purchase orders. After this commit: ----------------------- - The system now prints the Purchase Order report when the order is confirmed. - The Print button behavior dynamically changes based on the order state - This improves user experience by ensuring the correct document is printed according to the current state of the order. Task Id: 4905350 Forward-Port-Of: odoo/odoo#221148
This fix makes automated WhatsApp command palette tests wait for the interface to settle before interacting with it. It reduces false test failures, helping keep releases and maintenance work moving smoothly without changing user-facing behavior.
Original PR description
Before this commit, clicking on some elements of the command palette would not trigger the associated event, this was probably caused by clicking on outdated owl fragments which cannot trigger events while being destroyed. This commit fixes this issue by making sure that the interface is in a stable configuration before clicking. https://runbot.odoo.com/odoo/runbot.build.error/112148 Forward-Port-Of: odoo/enterprise#94075
The Swiss financial reports now show previous-year unallocated earnings with the correct amount. The balance sheet also distinguishes retained and allocated current-year earnings, helping businesses read profit and loss carryforward figures more accurately.
Original PR description
Before this commit, `Previous Year unallocated profit and loss` was showing wrong amount. With this commit, we adapt this line (change period of one of its expression) and we add two new lines to reflect the actual year earnings, retained and allocated. Steps, with fresh db: - 1 invoice confirmed in the past year for 1000 - Create the carryforward move (1000 debit for 999 account, and 1000 credit for 2979 account) - Go to balance sheet, set date as 'End of last fiscal year' -> See 'Previous Years Unallocated Earnings` showing -1000 opw-4054341 Forward-Port-Of: odoo/enterprise#91281
The Belgian salary configurator now prevents employees from combining a fuel card benefit with a reimbursed private bike option. When private bike reimbursement is active and above zero, fuel card values are automatically cleared and disabled to keep salary choices compliant and consistent.
Original PR description
The Belgian salary configurator allows employees to declare a private bike cost. When the "Private Bike" option is checked and its reimbursement value is greater than zero, the fuel card inputs must be reset to 0 and disabled. task-5062963 Forward-Port-Of: odoo/enterprise#94063 Forward-Port-Of: odoo/enterprise#93884
Installing the Peru electronic invoicing module is now more reliable on large databases. The change reduces memory usage during setup and avoids an installation error related to tax group updates, helping businesses complete upgrades or deployments without interruption.
Original PR description
### [PERF] l10n_pe_edi: Avoid OOM during installation ### Description: Installing `l10n_pe_edi` on large databases with many moves and move lines could cause out-of-memory (OOM) errors. This happens…
### [PERF] l10n_pe_edi: Avoid OOM during installation ### Description: Installing `l10n_pe_edi` on large databases with many moves and move lines could cause out-of-memory (OOM) errors. This happens because several stored fields need to be computed at installation. ### Fix: This fix adds the columns via SQL, preventing Odoo from computing and populating the field for all existing records. This reduces memory usage and avoids installation failures. ____ ### [FIX] l10n_pe_edi: Fix error during post-init hook ### Description: During installation, the `l10n_pe_edi` module's post-init hook attempts to update tax groups, setting the new `l10n_pe_edi_code` field. This can cause an error if a tax group doesn't exist and needs to be created, because the name field is missing in the list of values given to the `_load_records` function. ### Fix: This fix filters the tax groups to only update existing ones. This prevents `_load_records` from trying to create new groups, which avoids the installation error. ___ ### Reference: opw-4982181 Forward-Port-Of: odoo/enterprise#91997
Belgian payroll work entry UCM codes now preserve spaces so they can meet the required three-character format. This prevents valid codes such as “PR ” from being shortened incorrectly when users edit payroll settings.
Original PR description
#### Issue: - UCM work entry code should be 3 characters long and allow spaces to get this length #### Step to reproduce: - In a Belgian company - Go to Payroll > Settings > Work Entry Types > New - Add a name - Add a Payroll Code - In the `Country` field fill Belgium - In the field `UCM Code` enter "PR " - Select another field - Select `UCM Code` again #### Current behavior: - The field `UCM Code` was updated to "PR" #### Expected behavior: - The field should stay to "PR " #### Solution: - Don't trim the field and add a spaces if needed opw-5014372 Forward-Port-Of: odoo/enterprise#92838
This fix makes an automated barcode picking test wait for the page to finish loading before the browser closes. It helps prevent false test failures, improving confidence in release validation without changing day-to-day user workflows.
Original PR description
In this commit we fix the tour test_open_picking_dont_override_assigned_user. At the end of tour, we don't wait until kanban is fully rendered. If the browser is closed before this view is rendered, the error onWillStart: "Component is destroyed" can occurs error-runbot-id~190611
The message shown when no bank transactions are found now appears with proper formatting instead of showing raw HTML text. This improves clarity for users fetching transactions or changing filters in bank reconciliation.
Original PR description
Before this commit : - The help message shown when no transactions were fetched by the 'Fetch Transactions' button in the 'Bank' journal contained raw html tags, as markup was not getting applied. - Also, removing a filter (without reloading) and applying another filter that resulted in no matches, the same issue occurred. After this commit: - The help message is now consistently rendered with markup applied. task-4942234
This fix prevents Uruguayan electronic invoices from failing when an invoice line has no product or description. If no item name is available, the system now safely uses a placeholder so the CFE document can still be created.
Original PR description
This pull request makes a minor adjustment to the logic for extracting item names and descriptions in the `_l10n_uy_edi_get_line_nom_and_desc` method. The change ensures that the presence of `aml.name` (the line description) is checked directly, rather than relying on the truthiness of the entire `aml` object. Before this PR, if the aml of an invoice only have the `account_id` field filled and no `product_id`, the `_l10n_uy_edi_get_line_nom_and_desc` will raise an error message like `TypeError: 'bool' object is not subscriptable` when trying to create de CFE document. <img width="1254" height="828" alt="image" src="https://github.com/user-attachments/assets/eaadad4c-46c3-4e3b-be52-9fcd146f2c22" /> <img width="1526" height="795" alt="image" src="https://github.com/user-attachments/assets/1b831f41-9774-4ed5-9a9d-9777ee0633e9" /> With this fix, we ensure there is a name to grab or the '-' will be send instead. Forward-Port-Of: odoo/enterprise#93838
When receipt items are moved into a new wave transfer, their related quality checks now move with them or are recreated on the correct transfer. This ensures staff see and process quality checks from the right receipt, avoiding missed or misplaced inspections.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Community: https://github.com/odoo/odoo/pull/223852
opw-5009635
Forward-Port-Of: odoo/enterprise#93605
Forward-Port-Of: odoo/enterprise#92951The Documents kanban view no longer shows an unnecessary second scrollbar. This makes browsing documents smoother and reduces visual clutter for users working in that view.
Original PR description
This commit fix the useless double scroll bar in kanban view. Task-4844661 Forward-Port-Of: odoo/enterprise#90548
Fixed an issue where opening an embedded list view from a Knowledge article could accidentally save hidden view settings and later cause an error when editing the article. Users can now return to and edit articles with embedded list views without interruption.
Original PR description
Steps to reproduce =================== 1. Insert any list view in the knowledge article. 2. Click on open view from the article. 3. Come back and click edit. -> Traceback occurs Technical…
Steps to reproduce =================== 1. Insert any list view in the knowledge article. 2. Click on open view from the article. 3. Come back and click edit. -> Traceback occurs Technical ============= When we open a view from an embedded view in the article, we add `orderBy` from the action context to the action props if it exists. As the action prop is initialized and assigned directly from `embeddedState.additionalViewProps` without copying, it mutates the original object, changing the `data-embedded-props` attribute in the DOM and marking the body of the article as unsaved from `StateManager.changeState`. The action continues, and the action service commits those unsaved changes to the article. Once it is saved and the action is executed, when we get back to the article and click on edit, we check for `additionalViewProps` to be undefined/empty for all other views except calendar. As the DOM already has saved data in attributes, we get `orderBy` in `additionalViewProps`, and thus a manual error is thrown in the `editView` function. After this commit =============== Clone `additionalViewProps` when preparing the view action props. Task-4921282 Forward-Port-Of: odoo/enterprise#91113
The dashboard publish setting now changes only when users interact with the checkbox or its label. This prevents accidental reversals when clicking elsewhere in the dashboard header, making publishing behavior more predictable.
Original PR description
**Steps to reproduce:** - Open a dashboard in edit mode. - Click the “Publish” toggle to change its state. - Click elsewhere on the header (outside the toggle). → The publish state flips back unexpectedly. **Before this PR:** The wrapper container (.o_sp_publish_dashboard) had a click handler, causing clicks on the header to re-toggle the publish state. The CheckBox was rendered with a no-op onChange, so both elements competed for control. **After this PR:** Interaction is handled exclusively by the CheckBox component. toggleDashboardPublished is bound directly to its onChange. Clicking the label text now correctly toggles the checkbox and publish state. Container clicks outside the checkbox no longer affect the state. Task: [5062368](https://www.odoo.com/odoo/project/2328/tasks/5062368) Forward-Port-Of: odoo/enterprise#94061
DHL and USPS delivery integrations now retrieve package details correctly when working from sales orders. This helps ensure accurate shipping information and reduces errors during order processing.
Original PR description
This commit fixes the same issue in #89771, but for sale orders instead of pickings. opw-4979982 Forward-Port-Of: odoo/enterprise#94186
Imported FEC accounting entries are now included when users open a sales journal from the accounting dashboard. This ensures sales-related imported entries are visible in the expected journal view, reducing confusion and missing-record concerns after imports.
Original PR description
**PROBLEM** When importing a FEC files, moves are created with the `move_type` `entry`. They don't appear in the action of the journal of type `sale` when clicking on the dashboard. **STEP TO REPRODUCE** 1. on a local database install `l10n_fr_fec_import` (you need to import a FEC file given by our client, dont do it on the runbot please !) 2. select the french demo company 3. import the FEC file (accounting/settings/import a file) (for file, see [ticket](https://www.odoo.com/odoo/project/49/tasks/4848763) ) 4. goes in the dashboard, and click on the `Ventes Marchandises` journal. 5. notice the entries does not appear in the action. **CAUSE** When importing a FEC file, all moves are created with the `entry`. The domain for `sale` journal doesn't include the move of type `entry`. **FIX** Adding `entry` in the `sale` journal domain. opw-4848763 Forward-Port-Of: odoo/odoo#222208
Code cleanup and technical improvements
This update prepares customer follow-up reports to be customized more easily before they are sent or printed. Businesses can tailor how due and overdue items appear in customer communications without changing the standard report flow.
Original PR description
The goal with these hooks is to allow customization of overdue and due lines that are going to be printed on the followup report to be communicated to the customer. Forward-Port-Of: odoo/enterprise#93438