Daily updates from Odoo
Wednesday, May 6, 2026
309 changes
27 changes
Enhancements to existing features
This update expands the width of the Discuss sidebar to better accommodate chat descriptions and improve usability across different screen sizes. The sidebar now dynamically adjusts its width based on the screen, allowing users to see more of the conversation content without overlapping.
Original PR description
Prior to this commit, the left sidebar in Discuss had a max width of 300px. This commit allows larger widths based on the screen width. This is dependent on screen width, similar to…
Prior to this commit, the left sidebar in Discuss had a max width of 300px. This commit allows larger widths based on the screen width. This is dependent on screen width, similar to o-mail-ActionPanel.o_resizable_panel. It also removes the styling setting the max width to 300px. This helps make discuss more configurable, and makes it possible to see more of the description in live chat conversations. The sizes are set to match the max size of the right panel, so that they don't overlap, and there's suitable space in the center for the chat itself. Related to 221559 task-6180965 (Screenshots below show the worst case-scenario, where both the left and right panels are expanded to their max size) Before (Screen width > 1200px): <img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/952d6c4b-60fd-47b9-aff7-8e034a2ee752" /> After: Screen width > 750px: <img width="1291" height="964" alt="image" src="https://github.com/user-attachments/assets/1120da2d-a434-4b3b-b387-f1d29bf0cb91" /> Screen width > 1200px: <img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/47c6c981-0c62-43b6-8634-c6d644c342bb" /> Screen width > 1600px: <img width="1291" height="964" alt="image" src="https://github.com/user-attachments/assets/2945c964-5847-456b-b982-09086f335860" /> Screen width > 2300px: <img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/c8cbc63f-025b-463d-9a3a-c84fce87d223" /> Forward-Port-Of: odoo/odoo#262338
Resolved issues and error corrections
This update resolves a crash in the Retail POS system that occurred when viewing order details. The issue stemmed from a delay in loading order information, causing a 'null' error. The fix ensures order data is fully loaded before displaying details, improving stability and preventing unexpected application crashes.
Original PR description
Steps to reproduce: =================== - Open Retail POS - Add at least one product to the order - Go to the Payment Screen - Select any payment method - Navigate to the Ticket Screen - Click the (i) button to open Order Details Issue: ====== - Application crashes with an OWL lifecycle error: TypeError: Cannot read properties of undefined (reading 'id') - At that point, this.props.order.currency_id is undefined Cause: ====== - The currency_id relation field may not be fully loaded when orders are accessed during certain navigation flows (Payment Screen → Ticket Screen) - The method formatCurrency() tried to access currency.id on an undefined object Fix: ==== - Changed formatCurrency() in OrderDetailsDialog to use the currency getter instead of the direct currency_id field Task:6178180
This update removes the Tailscale IP address from the IoT box status screen. This simplifies the display for users and ensures accurate reporting of network connectivity. The change addresses a minor technical detail related to interface detection.
Original PR description
This PR removes tailscale ip address from iot box status screen. ``` >>> netifaces.interfaces() ['lo', 'eth0', 'wlan0', 'tailscale0'] ``` The 'tailscale0' interface will now be ignored Forward-Port-Of: odoo/odoo#242796
This update resolves an issue where invoices sent via Peppol were failing for customers in Iceland and Albania. The change ensures that VAT numbers for these countries retain their country code prefix, allowing invoices to be successfully transmitted. This improves compatibility with Peppol and avoids invoice sending errors.
Original PR description
Current behavior before PR: To send an invoice via Peppol, the customer's VAT must have the country code as a prefix. But while creating customers from countries like Iceland and Albania, It removes the country code prefix. Which later raises an error while sending the invoice that "The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: VAT numbers for customers in Iceland and Albania now keep their country code prefix, letting users to send invoices via Peppol. task-6050791 Forward-Port-Of: odoo/odoo#259105
This update corrects a technical issue that caused a traceback error when users removed the Unit of Measure (UOM) from a sales order line. The fix prevents unnecessary calculations related to discounts, ensuring smoother operation when managing UOM settings on sales orders. This improves overall system stability and user experience.
Original PR description
Issue: --- Due to this issue, there is a TB when you try to remove uom. Steps to reproduce: 1- Create a SO and add a line. 2- On SOL, remove uom. You get a traceback. This is because of `ensure_one` here: https://github.com/odoo/odoo/blob/saas-18.4/addons/product/models/product_pricelist_item.py#L588 We can prevent the discount compute on the line which is causing the `compute_price`, when uom is not set. opw-6144426 Forward-Port-Of: odoo/odoo#262266
This update resolves a technical problem that prevented the 'l10n_tr_nilvera_edispatch' module from installing correctly. The change ensures a necessary dependency, 'stock_account', is automatically installed, preventing an error related to missing configuration data. This ensures the module functions as intended.
Original PR description
Issue: currently, the module `l10n_tr_nilvera_edispatch` depends on `l10n_tr_nilvera_einvoice` and `stock`. and in `l10n_tr_nilvera_einvoice` , it eventually gets `account` in its dependencies [from…
Issue: currently, the module `l10n_tr_nilvera_edispatch` depends on `l10n_tr_nilvera_einvoice` and `stock`. and in `l10n_tr_nilvera_einvoice` , it eventually gets `account` in its dependencies [from dependency chain]. So `stock` and `account` both are installed, and ideally `stock_account` is also installed since it is set to `auto_install: True`. but if we try to install edispatch module with `--skip-auto-install` the module installation fails, because we skip auto install modules and `stock_account` is not installed, due to this, `country_code` field defined in `stock_account` module and used in `l10n_tr_nilvera_edispatch` module is not found which causes error. Solution: This PR fixes this issue by updating dependency from `stock` to `stock_account` to make sure it is installed in all conditions. Related runbot error: https://runbot.odoo.com/odoo/runbot.build.error/238909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262721
This update resolves a recurring issue that caused the Gantt chart's edge scrolling tests to fail intermittently. The fix ensures the test accurately identifies and interacts with the chart elements, improving overall stability and reliability. This prevents potential disruptions for users relying on the Gantt chart functionality.
Original PR description
This commit resolves intermittent flakiness in the Gantt side panel edge scrolling tests. Previously, the test could fail because the target pill element would occasionally become unbound (detached from the DOM) following the unsuccessful drag-and-drop sequence. The test logic has been updated to ensure the element reference is re-queried appropriately. runbot-error-243446
This update resolves an issue where referenced refunds in Viva.com were incorrectly reversing payments. The problem stemmed from a previous update that removed a necessary payment session ID. This fix restores the session ID, allowing refunds to function as intended and ensuring accurate payment reversals.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262911 Forward-Port-Of: odoo/odoo#262475
This update fixes a bug that prevented users from assigning recruiters to job positions when the hr_payroll module wasn't installed. The fix ensures the necessary data is always available, preventing an error message and improving the user experience. This change ensures consistent functionality across different Odoo configurations.
Original PR description
**Steps to Reproduce:** 1. Ensure hr_payroll module is NOT installed 2. Open a Job Position in hr_recruitment app 3. Click on "Assign Recruiter" button for a position without a recruiter 4. Observe error: "Name 'company_id' is not defined" **Bug Cause:** The interviewer_ids field on hr.job uses a string domain that references company_id. Since company_id is not available in the current view without hr_payroll it fails. **Solution:** Add `<field name="company_id"/>` to the hr_job_kanban view to ensure the field is consistently available for domain evaluation regardless of other installed modules. **Task:** 6106143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259305
This update fixes a potential issue where multiple sign actions within a single transaction could incorrectly assign the same roles, leading to data inconsistencies. The change adds a check during the transaction to ensure unique role assignments, preventing conflicts and maintaining data integrity. A new test has been implemented to verify this fix.
Original PR description
Before this commit, creating multiple server actions for the Sign app in a single transaction (e.g., when saving an Automation Rule with multiple nested actions) bypassed the `_check_sign_template_conflicts` constraint. Because the constraint only queried the database for existing links, it failed to detect conflicts within the in-memory batch, allowing the save to succeed and causing silent role overrides. This commit introduces an intra-batch check to the constraint. By tracking requested roles in memory during the loop, the constraint now correctly raises a ValidationError if multiple actions in the same transaction attempt to automate the exact same template roles. A test has been added to ensure batch creations are properly validated. Task: 6128909 Forward-Port-Of: odoo/enterprise#115062
This update resolves an issue where multiple users were incorrectly added to Whatsapp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added, preventing unnecessary notifications and channel clutter. This improves the user experience and channel management efficiency.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#114912 Forward-Port-Of: odoo/enterprise#102452
This update fixes an issue where the product configurator dialog wasn't displayed when products had sale packaging set. Now, the dialog automatically appears when a product's unit of measure (UOM) is defined, ensuring users always see the options for configuring the product before adding it to their cart. This improves the shopping experience and prevents accidental use of default UOMs.
Original PR description
Issue: --- If a product has sale packaging set, in website_sale, by clicking on add to cart icon, the dialog is not shown, as a result it always uses the default uom. This can be fixed by showing the configurator if there are product.uom set. opw-6112786 Forward-Port-Of: odoo/odoo#259658
This update fixes a bug where users could accidentally add text within image-only gallery items (like banners and image walls). The change prevents users from directly editing the content within these galleries, ensuring they display only images as intended. This improves the visual consistency and stability of website designs.
Original PR description
Some image items are supposed to not contain any extra content. Grid image items and `s_image_gallery`'s images are such images. Grid image-only items are actually `contenteditable`. This makes it possible to replace the image with text. A similar issue exists for images inside `s_image_gallery` blocks. This commit makes such items non-editable, while keeping the media inside it replaceable. Steps to reproduce: - Drop a Banner block - Select an image - Type something => Image was replaced with text - Drop an Image Wall - Select an Image - Type something => Image was replaced with text task-5436148 Forward-Port-Of: odoo/odoo#258018
This update corrects a calculation issue related to Pay-For-Account (PFA) and Daily Pay Value (DPV) in the Odoo Enterprise's Belgian payroll module. Separating these calculations ensures more accurate payroll processing and compliance with Belgian tax regulations. This fix enhances the reliability of payroll reports and reduces the risk of errors.
Original PR description
Forward-Port-Of: odoo/enterprise#113385
This update fixes a discrepancy in the calculation of canteen costs within the payroll module for employees without worked day data. By adding a simulation context, the system now accurately reflects canteen cost eligibility, ensuring correct payroll calculations. This improves the accuracy of employee compensation reporting.
Original PR description
We add simulation context in the canteen cost condition, since we dont have worked day lines in that case Forward-Port-Of: odoo/enterprise#113907
This update fixes an issue where users couldn't delete time off requests after a payslip was validated. Previously, the system incorrectly prevented deletion, even though the time off wasn't impacting the pay calculation. This change ensures that time off requests can be deleted regardless of payslip validation status, streamlining HR processes.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990
Forward-Port-Of: odoo/enterprise#116024
Forward-Port-Of: odoo/enterprise#115765This update resolves a bug where attachments weren't uploading correctly when navigating between records in the chatter. The change ensures attachments are always associated with the intended record, preventing data inconsistencies and improving the reliability of attachment uploads.
Original PR description
Currently, when uploading a bunch of attachments or a big one to the chatter, if you click on the pager (e.g. next) before the upload is complete, the attachments that have not yet been uploaded are uploaded to the next record. Due to the persistence of the Chatter component during record navigation and the fact that the `FileUploader` logic is tied to `state.thread`, an async callback that finishes after a record switch will attempt to update the currently active thread rather than the one that initiated the upload. With this change we tie uploader lifecycle to a specific record and ensure the completion callback only affects that record. task-5119290 Forward-Port-Of: odoo/odoo#262923 Forward-Port-Of: odoo/odoo#261552
This update ensures Odoo’s Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668This update resolves an issue that prevented the `sale_stock` and `purchase_stock` modules from installing correctly on databases with existing sale or purchase orders that included non-stock items like downpayments. The fix filters out these problematic lines during the installation process, preventing a software error and ensuring smooth module installation.
Original PR description
## Summary When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:…
## Summary
When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:
ValueError: Expected singleton: uom.uom()
## Root Cause
The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:
```python
empty_lines = open_sale_orders.order_line.filtered(
lambda l: l.product_uom_id.is_zero(l.qty_delivered)
)
```
This accesses product_uom_id without checking if it exists. Lines with:
- display_type set (sections, notes)
- is_downpayment = True (downpayments)
...don't have a product_id or product_uom_id, causing the error.
Fix
Add filters to skip non-stock lines before accessing product_uom_id:
```
empty_lines = open_sale_orders.order_line.filtered(
lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)
)
```
Steps to Reproduce
1. Create a fresh database (without sale_stock/purchase_stock)
2. Create a sale order with a downpayment line or section/note
3. Install sale_stock module
4. Error: ValueError: Expected singleton: uom.uom()
Reproduction Reference
- purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing
- sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
opw-6179073
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262625
Forward-Port-Of: odoo/odoo#262439This update resolves an issue where the inheritance in the marketing card event views was incorrectly referencing a related module. The fix ensures the correct view inheritance is applied, improving the stability and functionality of marketing event management within Odoo. This change ensures proper display and interaction with marketing event cards.
Original PR description
Technically, mass_mailing_event is not in marketing_card_event deps. Moreover the inherit refers to event form view. runbot-242493
This update resolves an issue preventing tests using the 'pos_admin' user from running correctly. The change adjusts user group permissions to ensure the 'pos_admin' test user has the necessary internal access, allowing for proper testing of the Point of Sale module. This ensures continued functionality and stability of the POS system.
Original PR description
Tests using `login=pos_admin` were no longer starting properly because `/pos/ui` was returning a 404 error. This happened because `pos_admin` was no longer an internal user. The issue was introduced when `stock.group_stock_user` was removed from the implied groups of `point_of_sale.group_pos_manager`. Since `stock.group_stock_user` implies `base.group_user`, `point_of_sale.group_pos_manager` no longer granted internal user access. To fix this, `base.group_user` is now added directly to the implied groups of `point_of_sale.group_pos_manager`. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6193752 PR introducing the bug: https://github.com/odoo/odoo/pull/241368/changes#diff-04860a18d18ef0dc2ebfcd974fafc0b886b6b1e8094a333a7c107b3cdc2301b2
This update resolves a test failure related to the ESG report by adjusting the data used in the tests. Specifically, the report's date range and associated records were set to an ancient date to prevent interference from demo data. This ensures the ESG report tests run reliably.
Original PR description
There was an issue when setting in draft all the account moves of the test DB before running the ESG report tests. In that process, some account moves were actually removed, which results in a 'Not found' record error. As the ESG report searches for all the account moves given a period (in all companies of the DB), some demo data could make the test to fail. We handle that issue by changing the date of the report and the related records to a very ancient date, to ensure that no external data will disturb the test. We also make that change for tests related to the HR part of the ESG report. runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/242321
This update corrects a visual issue in the accounting reports where the last column's data was partially cut off when scrolling. The fix adds bottom padding to the report, ensuring all data is fully visible and readable. This improves the clarity and usability of the accounting reports for users.
Original PR description
Before this commit, there was no bottom padding in the accounting reports, which caused the last column’s values to appear partially cut off when scrolling to the bottom. This issue started occurring after the PR: https://github.com/odoo/enterprise/pull/99198 opw-6130981 **Before fix (runbot)** <img width="1920" height="1005" alt="image" src="https://github.com/user-attachments/assets/808bbb2b-3b4e-4b5c-a872-b8bd7bf589ba" /> **After fix:** <img width="1917" height="1006" alt="image" src="https://github.com/user-attachments/assets/55f04e1f-0469-46e1-af69-f5055a7232d9" /> Forward-Port-Of: odoo/enterprise#116329 Forward-Port-Of: odoo/enterprise#116168
This update fixes a problem where tax amounts weren't accurately calculated when users grouped invoice lines. Now, the system automatically adjusts tax amounts to match before and after grouping, ensuring correct financial reporting. Additionally, a test case has been updated to use Belgian company and tax scenarios.
Original PR description
[FIX] account_edi_ubl_cii: correct tax amount when grouping lines When the user group lines of a move, the tax amount is now corrected if there's a difference in the tax amount before and after grouping This commit also removes the `ungroup_lines` context key, as the flow was changed in odoo/odoo#252458 Reword the `test_import_and_group_lines_by_tax` test: use belgian company and belgian taxes task-5993555 Forward-Port-Of: odoo/odoo#261718 Forward-Port-Of: odoo/odoo#252719
This update fixes a bug that occurred when attaching images to invoices. The system was incorrectly creating and syncing orphaned attachment files, leading to errors and crashes. The change prevents this premature attachment creation, ensuring stability and proper invoice processing.
Original PR description
Steps to reproduce: - Install documents_account and account_accountant. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Install documents_account and account_accountant. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: When attaching an image via a log note, the file becomes the main attachment but is intentionally unlinked (res_model=False) by the system to avoid UI clutter. Downstream modules unknowingly sync this orphaned file. Later, when "Send & Print" generates the real PDF, the system attempts to update the orphaned downstream record, causing model linkage conflicts and eventually a crash. Solution: Add `no_document=True` to the context during `_message_post_after_hook` for invoices. Previously, for incoming emails or log notes, the mail framework would trigger document creation immediately before the core accounting module could evaluate and orphan invalid files (like images). This change suppresses that premature sync, allowing downstream modules to explicitly handle the sync after the attachment's final state is resolved. opw-5930888 Forward-Port-Of: odoo/odoo#262637 Forward-Port-Of: odoo/odoo#258307
This update resolves an issue where sending invoices with attached images caused a system crash. The fix prevents the incorrect syncing of orphaned attachments, ensuring stable invoice printing and preventing data inconsistencies. It improves the reliability of the documents account functionality.
Original PR description
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: Adding an image via log note sets it as the main attachment, but it is intentionally orphaned (res_model=False) to prevent UI clutter. `documents_account` incorrectly syncs this unlinked file, creating a workspace document with a missing model. During "Send & Print", the official invoice PDF replaces the image as the main attachment. The document versioning logic intercepts this swap and attempts to re-parent the new PDF to match the orphaned document. This destroys the PDF's linkage to the invoice, causing a crash when the system later attempts to fetch the PDF. Solution: Since the base module now suppresses premature document creation during the message post, we explicitly handle the sync ourselves. We override `_fix_attachments_on_record_from_files_data` to iterate over the validated attachments and trigger document creation only for files that retained their `res_model`. We also add a check inside `_update_or_create_document` to strictly block orphaned attachments. opw-5930888 Forward-Port-Of: odoo/enterprise#116247 Forward-Port-Of: odoo/enterprise#115065
This update resolves an issue where a key in the purchase order suggestion process was incorrectly formatted, leading to potential errors. The fix ensures the correct key is used, improving the reliability of the purchase order suggestion feature. This change ensures accurate data processing within the purchase order workflow.
Original PR description
Issue: - `_editSuggestContext` sends `sectionId` in the context, but `action_purchase_order_suggest` expects the key to be `section_id`. Fix: - Update the `_editSuggestContext` to send the correct context key, `section_id`. Forward-Port-Of: odoo/odoo#261930
12 changes
Enhancements to existing features
This update expands the width of the Discuss sidebar to better utilize screen space, particularly for viewing chat descriptions. The sidebar now dynamically adjusts based on screen size, allowing users to see more of the conversation content. This improves usability and the overall chat experience.
Original PR description
Prior to this commit, the left sidebar in Discuss had a max width of 300px. This commit allows larger widths based on the screen width. This is dependent on screen width, similar to…
Prior to this commit, the left sidebar in Discuss had a max width of 300px. This commit allows larger widths based on the screen width. This is dependent on screen width, similar to o-mail-ActionPanel.o_resizable_panel. It also removes the styling setting the max width to 300px. This helps make discuss more configurable, and makes it possible to see more of the description in live chat conversations. The sizes are set to match the max size of the right panel, so that they don't overlap, and there's suitable space in the center for the chat itself. Related to 221559 task-6180965 (Screenshots below show the worst case-scenario, where both the left and right panels are expanded to their max size) Before (Screen width > 1200px): <img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/952d6c4b-60fd-47b9-aff7-8e034a2ee752" /> After: Screen width > 750px: <img width="1291" height="964" alt="image" src="https://github.com/user-attachments/assets/1120da2d-a434-4b3b-b387-f1d29bf0cb91" /> Screen width > 1200px: <img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/47c6c981-0c62-43b6-8634-c6d644c342bb" /> Screen width > 1600px: <img width="1291" height="964" alt="image" src="https://github.com/user-attachments/assets/2945c964-5847-456b-b982-09086f335860" /> Screen width > 2300px: <img width="1291" height="965" alt="image" src="https://github.com/user-attachments/assets/c8cbc63f-025b-463d-9a3a-c84fce87d223" />
Resolved issues and error corrections
This update fixes a bug where users could accidentally add text within image-only gallery items (like Banner and Image Wall blocks). The change prevents users from directly editing the image content, ensuring galleries always display images as intended. This improves the visual consistency and reliability of website designs.
Original PR description
Some image items are supposed to not contain any extra content. Grid image items and `s_image_gallery`'s images are such images. Grid image-only items are actually `contenteditable`. This makes it possible to replace the image with text. A similar issue exists for images inside `s_image_gallery` blocks. This commit makes such items non-editable, while keeping the media inside it replaceable. Steps to reproduce: - Drop a Banner block - Select an image - Type something => Image was replaced with text - Drop an Image Wall - Select an Image - Type something => Image was replaced with text task-5436148 Forward-Port-Of: odoo/odoo#258018
This update resolves an issue where signing documents with read-only date fields would be blocked due to a system error. The fix ensures that read-only date fields are correctly recognized and included during the signing process, preventing the 'required items not filled' warning. This improves the overall usability of the signing feature.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Create a sign template with a read-only (constant) date field. - Add at least one more sign item (e.g., text/signature). - Try to sign the document. Issue: - Signing is blocked with warning: “Some required items are not filled”. Cause: - Read-only date fields don’t have a value in `item.el.value`. - The system only checks value, so it treats the field as empty. - Even though the date is visible in the document, it is not picked during submission. Solution: - Update date value extraction to also read from `textContent` when value is empty. - This ensures read-only date fields are correctly considered filled. task-6181883
This update resolves an issue where uploading an empty file to the Sign Documents feature would cause an error. The fix ensures that empty file uploads are handled correctly, preventing the application from crashing. This improves the reliability of the Sign module for users.
Original PR description
## Steps to Reproduce: - Install the Sign module. - Try to upload an empty file in Sign Documents. Sample File: https://drive.google.com/file/d/1ik3b7Z--Xla_TmvRj92uTCGy1PspQ_cP/view?usp=drive_link ## Error: `TypeError - a bytes-like object is required, not 'bool'` ## Cause: Before saas-19.2, at [1] `datas` returns an empty binary string (`b''`) when the file content is empty. After the [refactor], `raw` is used instead, which returns `False` for empty content, leading to this error. ## Fix: This commit ensures that when the attachment raw value is False, it is replaced with an empty binary string (`b''`). [refactor]: https://github.com/odoo/enterprise/commit/8d66ffa62ab3fb3334528999d4534a9a995c6830 [1] - https://github.com/odoo/enterprise/blob/0d70215fb5d7b72dcfe86ac23fd04208329aad5d/sign/models/sign_document.py#L65 sentry-7432818850
This update corrects an issue where multiple users were incorrectly added to Whatsapp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added, preventing notification overload and improving channel management. This resolves a bug related to improperly formatted phone numbers.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#114912 Forward-Port-Of: odoo/enterprise#102452
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly included in the Mod347 BOE export. The fix removes a redundant search process that was adding partners unnecessarily, ensuring that only relevant partners are included based on the core BOE requirements. This improves the accuracy of the export data for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#116035 Forward-Port-Of: odoo/enterprise#110947
This update fixes an issue where Purchase Orders generated from Point of Sale orders weren't including the custom attribute information. The change ensures that the product description is correctly computed for POS orders, leading to more accurate purchase order details. This improves the consistency of order data.
Original PR description
Step to reproduce: - install "purchase_stock" and "point_of_sale" - Create a product attribute -> Display Type: Radio Button -> Variant Creation Mode: Never create variants -> Add two attribute…
Step to reproduce: - install "purchase_stock" and "point_of_sale" - Create a product attribute -> Display Type: Radio Button -> Variant Creation Mode: Never create variants -> Add two attribute values, ensuring that one includes a 'is_custom' field. - Create a product and assign this attribute to it. - Enable the MTO (Make To Order) route. - Add a vendor to the product. - Create and confirm a POS order for this product. (add text for custom attr) - Observe that a Purchase Order is generated automatically. Observation: - the PO does not have that text in description Cause: - After commit [1], `description_picking` became a computed field. - Previously, its value (`product_description_variants`) was set in `_prepare_procurement_values`. - That key is no longer used for this purpose, so the information is not propagated and the data is lost. https://github.com/odoo/odoo/blob/71b1267e54fd53fb283c41b579756c72e393cbfa/addons/stock/models/stock_rule.py#L341-L343 above code is removed following that commit Fix: - The description is computed for pos orders [1] https://github.com/odoo/odoo/commit/6b2d3af64a076654e04494972acc4c42d7c54bd8 opw-5969378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262503 Forward-Port-Of: odoo/odoo#253231
This update fixes an error in the manufacturing report that incorrectly converted quantities between different units of measure (UoM). The report now accurately calculates the total cost and quantity produced, ensuring consistent results regardless of the input UoM, which is crucial for accurate cost tracking and reporting.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#114233
Forward-Port-Of: odoo/enterprise#113979This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch reporting requirements.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668This update resolves an issue where purchase order suggestions were sending the wrong key in the context, leading to incorrect behavior. The fix ensures the correct key, `section_id`, is used, improving the accuracy and reliability of the purchase order suggestion process. This ensures purchase order suggestions function as intended.
Original PR description
Issue: - `_editSuggestContext` sends `sectionId` in the context, but `action_purchase_order_suggest` expects the key to be `section_id`. Fix: - Update the `_editSuggestContext` to send the correct context key, `section_id`. Forward-Port-Of: odoo/odoo#261930
This update resolves an issue where the last column of accounting reports was partially cut off when scrolling to the bottom. The fix adds bottom padding to the reports, ensuring all data is fully visible and accessible. This improves the clarity and usability of financial reports.
Original PR description
Before this commit, there was no bottom padding in the accounting reports, which caused the last column’s values to appear partially cut off when scrolling to the bottom. This issue started occurring after the PR: https://github.com/odoo/enterprise/pull/99198 opw-6130981 **Before fix (runbot)** <img width="1920" height="1005" alt="image" src="https://github.com/user-attachments/assets/808bbb2b-3b4e-4b5c-a872-b8bd7bf589ba" /> **After fix:** <img width="1917" height="1006" alt="image" src="https://github.com/user-attachments/assets/55f04e1f-0469-46e1-af69-f5055a7232d9" /> Forward-Port-Of: odoo/enterprise#116329 Forward-Port-Of: odoo/enterprise#116168
This update resolves an issue where custom website snippets weren't correctly reflecting translated content when using the delayed translation feature. The change ensures that translated values are properly applied to snippets immediately after saving, improving the user experience for multilingual websites. This prevents a delay in seeing translated content when using custom snippets.
Original PR description
The feature "delayed translation" and "copy translation in custom snippet" have been worked on in parallel, but had buggy interactions. This commit changes the way translations terms are copied in custom snippets to read and write the translated values as expected with delayed translations. Steps to reproduce: - With a page with some content on a website in 2 languages - Open the website builder in the main language - Drop a custom snippet - Save - Bug: The change is immediate on the version in the second language (instead of being only available after user translated it) Delayed translations: 2d08f97c0778469b409fca23f2be5f5a98ce3df8 Copy translation in custom snippet: d3426b7714012e833caae10281cfb8433223299a Re-enabling delayed translations: 03a85b13b2c46ef7174123d902e95d5103031c6c task-5474184 Forward-Port-Of: odoo/odoo#262814 Forward-Port-Of: odoo/odoo#245850
1 change
Resolved issues and error corrections
This update fixes an issue where a delay in website navigation transitions could cause dropdown menus to close unexpectedly. By ensuring the menu fully renders before other actions are taken, this change improves the overall stability and reliability of the website experience for users. This resolves a potential disruption to the user flow.
Original PR description
[FIX] website: wait for extra menu to fully render before continuing When clicking on the extra menu item, a Bootstrap dropdown is displayed with a transition. Because this transition takes time, it can lead to undeterministic behavior especially in tests. For example, if a tour clicks on the extra menu item and then clicks on the "Site" button in the navbar, the dropdown transition may still be in progress. This can cause the "Site" dropdown to close prematurely. runbot-240955 Forward-Port-Of: odoo/odoo#262660 Forward-Port-Of: odoo/odoo#261179
4 changes
Resolved issues and error corrections
This update fixes an issue where payment reminders weren't being sent to newly duplicated subscriptions. The root cause was a shared 'last_reminder_date' field, preventing reminders from being triggered for the copy. The fix sets this field to 'false' for copied subscriptions, ensuring reminders are sent as expected.
Original PR description
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new…
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago 3. Confirm the subscription 4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token" 5. Go back to the previously created subscription (see that a reminder email has been added in the chatter) 6. Duplicate the subscription and confirm the duplicate 7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again 8. There are no reminder for the duplicate subscription Issue: The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120 Solution: Set `copy=False` on the field `last_reminder_date` opw-6167356 Forward-Port-Of: odoo/enterprise#115509
This update automatically refreshes the payment screen when the PIS payment status changes. Previously, users had to manually refresh the page to see the updated status, leading to delays. This improvement ensures payment information is always current and accurate for users.
Original PR description
There were some buttons like sign payment that were visible even when the PIS status was signed which needed a manual page refresh for the update to reflect, now it's reflected automatically on the PIS status change. task-5417365 Forward-Port-Of: odoo/enterprise#114299
This update resolves an issue where multiple documents with the same subject wouldn't all be included in the downloaded zip file. The fix ensures that all signed documents with identical subjects are correctly grouped and downloaded, preventing data loss. This improves the reliability of the Sign app's document download feature.
Original PR description
## Issue In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file. ## Steps to reproduce 1. Install *Sign* (`sign`)…
## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.
## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**
## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.
https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286
Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.
## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.
opw-6143128
Forward-Port-Of: odoo/enterprise#116013This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#11566810 changes
Resolved issues and error corrections
This update prevents subscriptions from being automatically reopened after manual closure by a salesperson. Previously, approvals or payments could trigger reopening, leading to inconsistencies. This change ensures subscriptions remain closed as intended, streamlining the subscription management process.
Original PR description
Before this commit, when a subscription was closed manually by the salesperson, it could be reopened when a transaction was approved or an invoice paid. It could cause issue. In this case, we should not reopen automatically. task-5900481 Forward-Port-Of: odoo/enterprise#106487
This update fixes an issue where subscription delivery dates were incorrectly displayed as the previous day due to timezone differences. The change ensures delivery dates are accurately calculated based on the company's timezone, resolving a potential scheduling problem for subscription orders. This improves the reliability of delivery planning.
Original PR description
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm…
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm it. 3. Open the generated delivery order and check its Scheduled Date. Issue The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value (https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398). The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`. Solution Split the two cases explicitly: - First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow. - Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722). opw-6133831 Forward-Port-Of: odoo/enterprise#115100
This update fixes a display issue in push notifications for inbox users. Previously, notifications contained escaped characters, resulting in a broken message. Now, users receive the full, correctly formatted notification content, ensuring accurate and clear alerts.
Original PR description
**Steps to reproduce:** Log in as admin and ensure notifications are handled in Odoo. Enable push notifications and the 'Task Created' subtype for a project. As a second user, create a new task in…
**Steps to reproduce:** Log in as admin and ensure notifications are handled in Odoo. Enable push notifications and the 'Task Created' subtype for a project. As a second user, create a new task in that project. **Current behavior before PR:** admin received escaped content in the push notification (e.g., `A new task has been created in the "Project Name" project`) **Cause:** For inbox users, we send a client-side push notification using `previewText` as the body. This field returns a markup object containing escaped characters, which are converted to a string when passed to the notification body. Since the notification body only accepts plain text, these characters are displayed literally to the user. **Desired behavior after PR is merged:** admin receives the unescaped content in the push notification. (e.g., `A new task has been created in the "Project Name" project`) task-5112810 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when preparing future online food delivery orders. The issue stemmed from an incorrect delivery time format, which has now been corrected to ensure the preparation display functions smoothly and reliably.
Original PR description
### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176)
This update resolves a test failure in the 'pos_self_order' module that occurred due to a discrepancy in how time slots were generated. The fix freezes the time to '00:00' to ensure all available slots are considered for each day, improving the reliability of the order scheduling process. This ensures accurate order processing and prevents potential disruptions.
Original PR description
Before this commit: = - The test test_slot_limit_orders created slots only for the first day of the week (Monday). - The test scenario includes a slot at "18:00". - On Mondays, the test fails between 18:01 and 23:59 because the "18:00" slot no longer exists for the current day. - On other days, the test passes since slots are generated for the upcoming Monday. After this commit: = - Freezed the time to current day at "00:00" so that slot list can have every slot for that day. task-6043739 runbot-241836
This update fixes a discrepancy in how the invoiced quantity is calculated for sales orders, particularly when dealing with packaged products. Previously, rounding differences led to an inaccurate displayed quantity. The change ensures consistent rounding across delivered and invoiced quantities, improving data accuracy and order reporting.
Original PR description
Steps to reproduce: --- - Install the `Sales and Inventory` modules. - Enable `Units of Measure & Packagings` from Settings. - Go to `Sales > Configuration > Products > Units & Packagings.` - Create…
Steps to reproduce: --- - Install the `Sales and Inventory` modules. - Enable `Units of Measure & Packagings` from Settings. - Go to `Sales > Configuration > Products > Units & Packagings.` - Create a new unit > Pack of 12 with quantity 12 and unit Units. - Create a new product > enable Track Inventory, set Quantity On Hand to 100, and in the `sales` tab, under `Upsell & Cross-Sell`, set `packaging` as` Pack of 12`. - Create a Sales Order > add the product and set the quantity to 3, with a unit Pack of 12. - Confirm the order and validate the delivery. - Create and confirm the invoice. - Return `1 unit` from the delivery and validate it. - From the invoice, create a `credit note` with quantity 1 unit and confirm it. - Go back to the Sales Order. Issue: --- - On the Sales Order: `Delivered Quantity` shows` 2.92` while `Invoiced Quantity` shows `2.91`. Root cause: --- - At [1] & [2], in `_compute_qty_invoiced`, the `_compute_quantity` method is called without specifying a `rounding_method`, so it defaults to `UP` (1/12 rounded to 0.09), while `_compute_qty_delivered` explicitly uses `HALF-UP` (1/12 rounded to 0.08), leading to inconsistent rounding. Solution: --- - In this PR, the same rounding method (HALF-UP) is applied when computing the invoiced quantity to ensure consistency with the delivered quantity. [1]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale/models/sale_order_line.py#L896-L912 [2]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale_stock/models/sale_order_line.py#L193-L209 opw-6073690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258024
This update corrects a bug preventing free FSM services with prepaid invoicing from appearing on invoices. Previously, the system incorrectly set the invoice quantity to zero. Now, these services will correctly appear on invoices, ensuring accurate billing for prepaid FSM tasks.
Original PR description
Changed _compute_qty_to_invoice in industry_fsm_sale, SaleOrderLine to no longer set qty_to_invoice to 0 for free services with prepaid invoicing. Previous changes seem intended for goods. Steps to reproduce: - Create service product with 0 price, prepaid invoice policy, creates FSM task - Create/Confirm sales order with created product - Attempt to create invoice, get 0 quantity to invoice error Current Behavior: Free services linked to FSM tasks do not appear on invoices due to compute 0 qty_to_invoice Expected Behavior: Prepaid Invoice Services linked to FSM tasks appear on invoices. Other invoice policies can be invoiced through the generated sales order lines (timesheets, delivered quantity, etc.) opw-6047992 Forward-Port-Of: odoo/enterprise#113718
This update corrects a bug where the Point of Sale dashboard incorrectly displayed all POS locations under only the primary warehouse, even when a different warehouse and operation type were configured. The fix ensures that POS locations automatically reflect the correct warehouse based on their operation type, improving accuracy and usability.
Original PR description
When filtering pos by warehouse_id, all pos are under the same warehouse even if we had configure an Operation Type from a different warehouse for a specific pos. Steps to reproduce: ------------------- * Setup a second warehouse in the company * Add the new POS operation type picking for the second warehouse on the POS settings * Group by warehouse in the POS dashboard > Observation: It always shows the first warehouse Why the fix: ------------ The warehouse_id field on pos.config was a plain Many2one with a static default that always set it to the first warehouse of the company. Convert warehouse_id into a computed stored editable field that derives from picking_type_id.warehouse_id. This ensures the warehouse stays in sync when the operation type changes, while still allowing manual override for the Ship Later feature. opw-6104652 Forward-Port-Of: odoo/odoo#262246 Forward-Port-Of: odoo/odoo#258830
This update automatically refreshes the payment screen when the PIS payment status changes. Previously, users needed to manually refresh the page to see the updated status, leading to delays. This improvement ensures payment information is always current and accurate.
Original PR description
There were some buttons like sign payment that were visible even when the PIS status was signed which needed a manual page refresh for the update to reflect, now it's reflected automatically on the PIS status change. task-5417365 Forward-Port-Of: odoo/enterprise#114299
This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#1156682 changes
Resolved issues and error corrections
This update corrects a bug in the Mod 349 report for Spanish tax filings. Previously, transactions under 1 Euro were incorrectly excluded, preventing the report from displaying all relevant journal entries. The fix adjusts the calculation to accurately include these small amounts, ensuring complete and accurate tax reporting.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#114776
This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid report submission failures and maintain compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#11566818 changes
New functionality added to Odoo
This update introduces overtime salary rules specifically tailored for the Emirates localization within Odoo Enterprise. These new rules ensure accurate payroll calculations and compliance with UAE labor regulations, improving the system's functionality for businesses operating in the UAE.
Original PR description
…set for Emirates localization Add salary rules for overtime rules in the Emirates localization. Task: 6152326
Enhancements to existing features
This update simplifies alert handling within the IoT payment interfaces (Tyro, Worldline, Six) by standardizing alert messages. Previously, each module had its own alert system; now, a central helper function is used, making the system more consistent and easier to manage. This change improves the overall user experience and maintainability.
Original PR description
Drop the per-module alert wrappers and inline `dialog.add(AlertDialog, ...)` calls in the IoT payment interface and its subclasses, routing them through the base `PaymentInterface` `showAlert(title, message)` helper added in community.
This update introduces a dialog that provides a clear view of the data merging process for duplicate records. Users can now see which fields are contributing to the similarity, how master and source records will be updated, and how related records will be merged, reducing the risk of errors.
Original PR description
[IMP] data_cleaning: add merge details dialog in data_merge.record list view Before this commit Users could not easily understand why records were considered duplicates or what would happen after…
[IMP] data_cleaning: add merge details dialog in data_merge.record list view Before this commit Users could not easily understand why records were considered duplicates or what would happen after merging them. Although duplicates were detected based on similarity rules, there was no easy way to see which fields contributed to the similarity or what data would be kept or transferred during the merge. After this commit Merge details dialogs are introduced to improve transparency in the deduplication flow: - Field Mapping Logic: Displays a side-by-side comparison of master and source records for fields used in deduplication rules. - Master-Exclusive Fields: Highlights fields whose values are kept exclusively from the master record during the merge. - Master Record Update: Provides a preview of how relational fields will be updated during the merge, including which records currently linked to the source will be reassigned to the master record, and how many related records will be merged into the master. Impact Improves user understanding of the deduplication process and enables users to review similarity criteria and merge results before performing the merge, reducing the risk of incorrect merges. Taskid-5952579
This update redesigns the input section on employee payslips to improve usability and aesthetics. The changes include adding specific salary rule categories for Belgian regulations and streamlining the input selection process, resulting in a more user-friendly experience for payroll administrators.
Original PR description
Purpose: Currently the input tab on payslips is very ugly on not user friendly. Current behavior: - Show the input section selection if the input usage is employee or payslip - Always allow edit the input section. - Add salary rule categories for Belgian salary inputs - Hide other input list in BE localization if there are no salary adjustments - removed the last 3 other inputs that are not used task-id: 6117069
This update adds a simple button to the offer form in Odoo, allowing users to easily regenerate the offer token. This is a security enhancement to protect against compromised email addresses and ensures tokens are always up-to-date. It provides a convenient way to manage offer tokens without needing technical assistance.
Original PR description
Add a button in the cogwheel of the offer form view to regenerate the token in case the email is compromised or the token needs to be updated for any other reason. Task-5172914
This update links reservation appointments to their corresponding POS orders, streamlining the process for restaurants. It also fixes a previous issue where new partners created through the booking page weren't automatically linked to POS orders. This improves order management and data accuracy.
Original PR description
*: pos_appointment, pos_restaurant_appointment Link table-reservation appointments to their corresponding POS orders and add a smart button on the POS order form to access the related appointment. Fix an issue where a partner created via quick create (or not yet loaded in the frontend) from the booking page was not automatically set on the POS order. Task-5249028
This update enhances the Odoo Report Editor by enabling the insertion of 'bare x2m' data types, which were previously restricted. This change expands the types of data that can be included in reports, providing greater flexibility for report customization. This aligns with prior support for x2m data, as documented in odoo/odoo#231147.
Original PR description
Before this commit, it was not possible to insert bare x2m in the report even though their basic support has been supported for sometime namely with odoo/odoo#231147 After this commit, it is possible to do such a thing task-6003295
This update removes a confusing distinction between 'Regular' and 'Accrual' holiday allocation types. Now, allocations are automatically categorized based on whether an accrual plan is set up, leading to a simpler and more intuitive user experience. This change improves the overall system clarity and reduces potential errors.
Original PR description
Before: - Allocations were explicitly divided into Regular and Accrual types through the allocation_type field. - This separation created an unintuitive UX and added unnecessary complexity to the logic. After: - Removed the allocation_type field. - Simplified the logic so that: - If an allocation has an accrual plan → it is treated as accrual. - If no accrual plan is set → it is treated as a regular allocation. - This improves clarity, simplifies the flow, and makes the behavior more intuitive. Task-5944548
Resolved issues and error corrections
This update removes a confusing setting that was incorrectly mixing withholding tax (WHT) closing entries with VAT closing entries. This ensures that financial reports are accurate and separate, preventing errors in tax calculations. The change improves the clarity and reliability of financial reporting.
Original PR description
WHT does not require a closing entry. The current return type is causing VAT closing entry to mix with WHT closing entry or vice versa. task-6157814 Forward-Port-Of: odoo/enterprise#115576
This update resolves an issue where users unregistering from GST would receive a 'Missing Required Fields' error. The fix ensures the GST username field is only required when the GST section is enabled, allowing users to modify settings correctly regardless of their GST registration status.
Original PR description
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to…
**Steps to reproduce:** * Install `l10n_in` module. * Go to Accounting > Settings. * Check 'Fetch Vendor E-Invoiced Document` and clear the GST Username * Uncheck `Registered Under GST`. * Try to modify any setting and save. **Observed behavior:** * A `Missing Required Fields` error is raised even though no visible field is missing a value. **Cause:** * The `l10n_in_gstr_gst_username` field is placed inside a `div` that is hidden when `l10n_in_is_gst_registered` is `False`. * However, its `required` condition only checked `l10n_in_gst_efiling_feature or l10n_in_fetch_vendor_edi_feature`, without accounting for `l10n_in_is_gst_registered`. * Since both features default to enabled, the field remained required even when invisible, blocking any settings save. **Fix:** * Update the `required` attribute on `l10n_in_gstr_gst_username` to include `l10n_in_is_gst_registered` as a condition, so the field is only required when the GST section is visible and either `GST E-Filing & Matching` or `Fetch Vendor E-Invoiced Document` is enabled. opw-6133001 Forward-Port-Of: odoo/enterprise#116174 Forward-Port-Of: odoo/enterprise#114423
This update resolves an issue where live chat channels with AI agents were not appearing correctly. The fix corrected a coding error that was preventing the system from accurately counting agents associated with each channel. This ensures all live chat channels, including those with AI agents, are visible to users.
Original PR description
The number of agents linked to a livechat channel was always 0 because of a mistake in the code. This prevented livechat channels with AI agents from appearing to users. This commit fixes the problem. task-5409200 Forward-Port-Of: odoo/enterprise#114404 Forward-Port-Of: odoo/enterprise#111574
This update fixes a minor issue in the Odoo HTML editor by clarifying how text content is handled. Specifically, it replaces a specific method with a more general one, ensuring consistent behavior and better performance. This change improves the reliability of text manipulation within the editor.
Original PR description
Description of the issue this PR addresses: This commit replace `editableSelection.textContent()` with `toString()` and review `textContent`/`innerText` usages. task-6014428 community-https://github.com/odoo/odoo/pull/260619
This update ensures that the Point of Sale configuration correctly resets when optional modules (like appointment scheduling) are removed. Previously, the configuration would retain outdated settings, leading to potential issues. This change guarantees a clean state after module uninstallation, improving stability and usability.
Original PR description
PURPOSE: ------------ Prevent POS configuration from keeping stale flags after uninstalling optional modules such as pos_appointment or pos_avatax. STEPS TO REPRODUCE: ------------- 1. Enable Appointment in POS config (module_pos_appointment=True). 2. Uninstall pos_appointment. → The “Appointment” option in POS config remains checked. FIX: --------------- Added uninstall_hook in __init__.py of each POS addon: - pos_appointment - pos_avatax - pos_iot - pos_urban_piper Each uninstall hook resets the corresponding module_pos_* flag to False in all pos.config records. Task-5166200 Related PR-https://github.com/odoo/odoo/pull/235255
This update adds warnings to the payroll dashboard for employees in India who have missing or invalid bank information (IFSC codes). This ensures accurate payroll processing and compliance by proactively identifying and resolving potential payment issues related to bank account details.
Original PR description
Purpose: - Ensure employees have valid bank identification codes for payroll payments by showing warnings when bank BIC/SWIFT/IFSC codes are missing or invalid. This PR includes: - Added related field `partner_country_code` on bank accounts to determine the partner country. - Updated bank account form view to dynamically display the label: - 'BIC/SWIFT/IFSC' when the contact country is India. - 'BIC/SWIFT' when the contact country is outside India. - Modified validation logic to detect missing or invalid bank identification numbers depending on the employee contact country. - Added payroll dashboard warning 'Missing or invalid bank BIC/SWIFT/IFSC' to highlight employees with incomplete or incorrect bank details and restricted it to Indian companies and employees. task-5921423
This update resolves a technical issue preventing proper tracking of expenses within the Stripe module. The change ensures that tracking values are correctly linked to mail messages, improving the reliability of expense reporting. This ensures accurate expense data is captured and managed.
Original PR description
tracking_value_ids are used in _transfer_messages_to_card but since the seperation of tracking values from mail, it's failing. task-6186968 Forward-Port-Of: odoo/enterprise#116213
This update resolves an issue where users lacking specific permissions on employee records would encounter an access error when trying to view attendance data. The change corrects a technical error related to accessing employee information, ensuring all users can access attendance records regardless of their permission level. This improves usability and prevents disruptions for users.
Original PR description
Steps to reproduce: ---------------------------------------- - Connect with a user having no rights on Employee - Try to open Attendances - Access error Cause: ---------------------------------------- Since 218b91cad3e50b27a84624145c89ed6bb23f18c5 we read the field `is_flexible` on employee which is a field only accessible to `hr.group_hr_user` ([src](https://github.com/odoo/odoo/blob/70ade77937bfc171a3352e70c5c78bfd87ceb4d1/addons/hr/models/hr_version.py#L154)). opw-6179252 Forward-Port-Of: odoo/enterprise#116052
A minor typo in the French Profit & Loss report (P&L) has been fixed. The term 'exceptionnel' was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting and compliance with French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
Code cleanup and technical improvements
This update removes a redundant field from salary attachments, streamlining calculations and ensuring all amounts are consistently displayed with the correct positive or negative signs. This change improves the accuracy of payroll reports and payment processing, addressing a potential source of calculation errors.
Original PR description
The is_refund field on the salary attachments is used in order to keep all the values (i.e. monthly_amoun, remaining_amount, total_amount etc.) positive and add the negative sign when needed. Here we refactor the code so that we have the amounts with the correct sign all the time. Task: 6110407
11 changes
Enhancements to existing features
This update enhances the appearance of online order notifications within the Point of Sale system. Specifically, the notifications now utilize a full-width layout on smaller screens, improving readability and alignment. This ensures a cleaner and more user-friendly experience for customers viewing notifications on mobile devices.
Original PR description
In this commit: ------------------- - Use a full-width layout on small screens by removing container padding and improving alignment with `justify-content-between`. task: 6054267
Resolved issues and error corrections
This update fixes a TypeError occurring during v19.1 upgrades involving subscription orders with defined end dates. The issue stemmed from an incorrect comparison between a boolean and a date field, now corrected by adjusting the calculation within the order amount computation. This ensures smooth upgrades and accurate invoicing for subscription-based services.
Original PR description
**Steps-to-Reproduce** - In v19, install subscriptions. - create new subscription + service product with allow one time sale enabled. - make a SO with that product,any reccuring plan and any end…
**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date.
```
id | name | subscription_state | next_invoice_date | end_date
----+--------+--------------------+-------------------+------------
1 | S00001 | 1_draft | | 2026-05-02
```
- confirm the SO
```
id | name | subscription_state | next_invoice_date | end_date
----+--------+--------------------+-------------------+------------
1 | S00001 | 3_progress | 2026-05-01 | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
id | name | subscription_state | next_invoice_date | end_date
----+--------+--------------------+-------------------+------------
1 | S00001 | 3_progress | | 2026-05-02
```
- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
line 175, in _compute_amount_to_invoice
and (not order.end_date or order.next_invoice_date < order.end_date)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```
- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).
upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)This update corrects a previous issue where payslips were incorrectly referencing contract dates instead of the correct version dates. The fix ensures payslips accurately reflect the version of the contract being processed, leading to more reliable payroll reporting. This change was enabled by a related update to search functionality.
Original PR description
Prior to this commit, the version domain on payslips only looked at the contract dates rather than the version's dates. The domain was fixed in this commit to limit the domain based on the version's dates instead, and this was allowed after the searches on the version date_start and date_end fields were fixed in the odoo/odoo#256581. task-6067139 Forward-Port-Of: odoo/enterprise#113818
This update fixes an issue where bank statement imports were failing due to incorrect partner name matching. The change ensures that when a CAMT file contains both 'Dbtr' and 'UltmtDbtr' values, the 'UltmtDbtr' name is used for reconciliation, resolving import failures and improving data accuracy.
Original PR description
Steps to reproduce: 1- Create a Swiss company and switch to it 2- Go to [Accounting -> Configuration -> Journals] and create a Bank journal 3- Go to the Accounting dashboard, click on the three dots on the Bank journal and click import records 4- Upload a CAMT file with a record that has both a value for "Dbtr" and "UltmtDbtr" (file can be found in the ticket chatter) Issue: The added record uses the "Dbtr" `name` value for the partner name. As a result, reconcilation matching fails Expected behavior: If exists, should use the "UltmtDbtr" `name` value opw-6024860
This update corrects a bug where multiple users were incorrectly notified for WhatsApp channel updates. Previously, a single message trigger would add all users in a notification list to the channel. The fix ensures that only the initiating user receives notifications, improving channel management and reducing unnecessary alerts. This resolves a potential issue with channel creation and user notification accuracy.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#114912 Forward-Port-Of: odoo/enterprise#102452
This update fixes an issue where recurring invoices weren't accurately reflecting the subscription's billing period. The change ensures invoices align correctly with the subscription's value (e.g., 3 months) regardless of the billing period, leading to more accurate revenue recognition. This improves the subscription billing process.
Original PR description
## Issue When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit…
## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
- *Billing Period*: 6 Months
- *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
- Any Customer
- Recurring Plan RP
- Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**
## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382
This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.
## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.
**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.
opw-6151530This update fixes a minor usability issue in the Helpdesk module. Previously, users attempting to delete a stage in a ticket kanban view were prompted with a warning if the stage contained tickets. Now, keyboard shortcuts are correctly assigned to the confirmation and discard buttons within this wizard, streamlining the deletion process.
Original PR description
Before this commit, when the user tries to delete a kanban column in ticket kanban view when the group by is stage_id. A pop-up appears when there is at least one ticket in that stage to notify the user it would be better to archive the stage or remove all tickets from that stage before deleting it. The Confirm and Discard buttons of that wizard does not have keyboard shortcut as the other discard button in the other views/wizards. This commit makes sure the keyboard shortcut is correctly assigned to those buttons. task-4885677 Forward-Port-Of: odoo/enterprise#89141
This update automatically refreshes the payment screen when the PIS (Payment Initiation System) status changes. Previously, users had to manually refresh the page to see the updated status, leading to delays. This improvement ensures payment information is always current and accurate.
Original PR description
There were some buttons like sign payment that were visible even when the PIS status was signed which needed a manual page refresh for the update to reflect, now it's reflected automatically on the PIS status change. task-5417365 Forward-Port-Of: odoo/enterprise#114299
This update fixes an issue where the AI systray button had excessive padding, creating an uneven look. The change removes unnecessary styling classes to streamline the design and ensure a consistent user experience. This improves the visual appeal of the application.
Original PR description
Remove the `btn` class because it adds additional padding, and eliminate the other unnecessary classes since the rules have already been applied in the `navbar.scss` file. task-5079952
This update resolves an error that occurred when calculating benefit costs using property fields in the employee contract settings. Previously, the system couldn't handle property fields correctly, leading to a calculation error. This change prevents property fields from being used as cost fields, ensuring accurate benefit cost calculations.
Original PR description
**Steps to Reproduce:** 1. Install `hr_contract_salary_payroll` with demo data. 2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties. 3. Add a new property for Payroll…
**Steps to Reproduce:** 1. Install `hr_contract_salary_payroll` with demo data. 2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties. 3. Add a new property for Payroll and fill in the value also. 4. Go to Payroll > Configuration > Benefits. 5. Create a new benefit with: Salary Structure Type: Worker Cost Field: Payroll Properties (Employee Contract) 6. Save the record. Video: https://drive.google.com/file/d/1gHRkDW5G0bURlo9_IRgCnvqpE-8Fk1xa/view?usp=drive_link **Error:** `TypeError - unsupported operand type(s) for +: 'int' and 'Property'` **Cause:** The method `_get_benefits_costs()` directly sums values using: ``` self[benefit.cost_field] ``` When the selected cost field is a property field, it returns a **fields_properties.Property** object instead of a numeric value, and this object is not directly compatible with the arithmetic sum operation. Before 19.0, property fields were not allowed to be selected as a cost field - [1]. **Fix:** This commit prevents selecting property fields as cost fields from the list of supported field types. [1] : https://github.com/odoo/enterprise/blob/04224abcc7eec1c81df7ad57a9213fd091774888/hr_contract_salary/models/hr_version.py#L183 sentry-7388663038
This update prepares Odoo for a critical change in Dutch reporting requirements. The Digipoort endpoint infrastructure is migrating to a new domain (logius.nl) effective May 1, 2026. This ensures continued accurate report submissions and avoids submission failures.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#11566812 changes
Enhancements to existing features
This update enhances the VAT reporting feature in Odoo Enterprise by accurately reflecting the total turnover for each VAT number, even when individual partner turnovers are below a threshold. Previously, partners with low individual turnover but a high total VAT number were excluded from the report. Now, the report includes all partners associated with a VAT number if the total turnover for that number exceeds the defined threshold, providing a more complete and accurate VAT listing.
Original PR description
When having different partners with the same vat number and their individual turnover values are less than the threshold they were not included in the partner vat listing report even though if the total turnover for their vat number is above the threshold. This commit handles this case by grouping by vat number and if the total turnover for a vat number is above the threshold then it will be shown in the report with another level beneath it to show the partners having this vat number even if their individual turnovers are below the threshold. task-6133010
Resolved issues and error corrections
This update ensures that failed Stripe terminal payments are properly flagged in the POS system. Previously, a successful authorization could lead to incorrect payment status updates, masking payment issues. Now, the system correctly identifies and displays payment failures, improving accuracy and preventing revenue loss.
Original PR description
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.
This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.
In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.
Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.
opw-6075384
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where Odoo was generating incorrect CFDI XML files for invoices using the 'add_invoice_line' cash rounding strategy. The fix ensures that pre-rounding amounts are correctly reported according to Mexican tax regulations (SAT), preventing XML rejection errors. This improves compliance and accuracy of financial reporting.
Original PR description
When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078
This update fixes a UI issue where the change amount displayed during point of sale transactions was incorrectly shown as a positive value. Now, change amounts are displayed as negative, accurately reflecting the money leaving the store with the customer. This ensures accurate financial reporting and a better user experience.
Original PR description
Steps to Reproduce ------------------------ - Install point of sale. - Do a order and pay more than the amount. Issue ------ - The change amount is displayed as a positive value on the UI. - Typically, amounts going out of the shop (like change given to the customer) should be shown as negative. Cause ------- - The change amount was not correctly represented in the UI. - Since the change flows in the opposite direction of the payment, it should be displayed as the negation of the original amount. FIX ----- - Updated the frontend to display the change amount with the correct (negative) sign. - No backend changes were required, as the correct value was already being handled during order synchronization Enterprise PR: https://github.com/odoo/enterprise/pull/112560 task: 6074620
This update fixes a visual issue in the Point of Sale interface where the change amount was not displayed with the correct negative sign. The change ensures that the POS system accurately reflects the amount of change given to customers, improving the user experience and preventing potential errors.
Original PR description
In this commit: --------------- - The tours are updated to adapt the change as now frontend display the change amount with the correct (negative) sign. Community PR: https://github.com/odoo/odoo/pull/256776 task: 6074620
This update resolves an issue where commission plans with negative targets caused a system error. The fix ensures the commission calculation logic handles negative values correctly by applying absolute values within the calculation, preventing a 'Maximum call stack size exceeded' error. This improves the stability and usability of commission plan creation.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644
A bug preventing the snippets drag-and-drop tour from completing was resolved. The fix ensures the editor is responsive during snippet loading, preventing errors when users remove or interact with snippets. This improves the user experience and prevents tour failures.
Original PR description
`test_03_snippets_all_drag_and_drop` was consistently failing on runbot. The tour stopped after removing the snippet `s_dynamic_snippet_products` because no drop zones were found for the next snippet. **Cause** The public widget `DynamicSnippetProducts` performs an RPC call in `willStart` (~1 second), but it is still possible to delete the snippet while the promise is pending. In this case, the editor is unresponsive until the promise resolves. The tour fails because the snippet is removed while the promise is still pending, the editor is not ready to process the click on the next snippet, and no drop zones are generated. **How to reproduce the problem** This is impossible to trigger manually, but consistently happening on runbot. The easiest way to reproduce the problem is to add a delay in `_fetchData()`. **Fix** Wait for the snippet to finish loading before proceeding with the tour, ensuring the editor is responsive when the next steps runs. runbot-226770
This update resolves an issue where payment reminders wouldn't render correctly when the 'payment' module wasn't installed. The fix ensures the necessary 'payment.method' model exists before attempting to use it in the email template, preventing a rendering error. This ensures all payment reminder emails display properly.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030
A technical issue with how data was imported into the product_unspsc module was resolved. This fix corrects a syntax error related to older PostgreSQL versions, ensuring data imports function correctly. This prevents potential disruptions during updates.
Original PR description
last week this fix deployed https://github.com/odoo/enterprise/pull/112652 https://www.postgresql.org/docs/14/sql-copy.html in older version posgress like 14.0 ``Header`` is only accepting [boolean]…
last week this fix deployed https://github.com/odoo/enterprise/pull/112652
https://www.postgresql.org/docs/14/sql-copy.html
in older version posgress like 14.0 ``Header`` is only accepting [boolean] parameter.
```
Traceback (most recent call last):
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/loading.py", line 481, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/loading.py", line 366, in load_marked_modules
loaded, processed = load_module_graph(
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/loading.py", line 234, in load_module_graph
migrations.migrate_module(package, 'post')
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/migration.py", line 216, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
File "/tmp/tmpfiag6d7a/odoo/17.0/odoo/modules/migration.py", line 240, in exec_script
migrate(cr, installed_version)
File "/tmp/tmpfiag6d7a/enterprise/17.0/product_unspsc/upgrades/0.3/post-update-codes.py", line 16, in migrate
cr.copy_expert("COPY _upgrade_product_unspsc_code FROM STDIN WITH (DELIMITER '|', HEADER MATCH)", csv_file)
psycopg2.errors.SyntaxError: header requires a Boolean value
```
detected here
https://upgradeci.odoo.com/upgradeci/run/294631
Forward-Port-Of: odoo/enterprise#116351This update resolves an issue where paid orders using loyalty cards with archived programs would trigger errors when opening the partner list. The fix prevents these errors, ensuring smooth processing of paid orders with loyalty programs. This improves the reliability of the point-of-sale system.
Original PR description
Backport of https://github.com/odoo/odoo/commit/ffe46084665bb8a64ef9cd9f44b85f7178adf6f7 Before this commit, when loading a paid order with a loyalty card that its program had been archived, an error was raised when opening the partner list due to the missing program. opw-6182368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where payment accounts were incorrectly swapped for outbound payments in the Point of Sale system. The fix ensures that journal entries accurately reflect inbound and outbound payments, debiting the correct accounts and preventing financial discrepancies. This improves the accuracy of financial reporting related to sales transactions.
Original PR description
Step to reproduce: - we need a session, where in total, we gave out money (when we refund) - for this, start a pos session, do a order, pay using bank and close session - restart the pos, refund the order, and pay using bank, close it. - go to accounting > customer > payment - open payment for both session Observation: - in journal entries for both payment, amount is credit into `account_receivable` and debit from `outstanding account` Cause: - commit[1] swaps accounts when we have outbound payments, which is functionally incorrect and lead to this issue. [1] https://github.com/odoo/odoo/commit/844d2960af6b2cdd8620eb1681bda03dd48a97e4 Fix: - do not swap accounts between `outstanding` and `destination` accounts. Expected after fix: - Inbound and outbound payments use the same accounts - Journal entries are correct: - Inbound: debit outstanding, credit account_receivable - Outbound: reverse of inbound entries opw-6044883
This update fixes a bug preventing returns for dropshipped orders within the Helpdesk module. Previously, returns were limited to outgoing customer orders. Now, the 'Returns' button is visible for dropshipped transfers, allowing users to manage returns directly from the Helpdesk ticket, streamlining the returns process for dropshipping customers.
Original PR description
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and…
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and quantity under the Purchase tab - Create a sale order for the product - Go to the Purchase stat button and confirm the order - Click on the Dropship stat button and validate the transfer - Open Helpdesk and create a new ticket for the same partner ### Issue: The "Returns" stat button is not visible for dropshipped deliveries. ### Current behaviour: - The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor. - With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket. ### Expected behaviour: Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO). ### Fix: The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket Issue:https://github.com/odoo/enterprise/pull/81378 task-4881338
3 changes
Enhancements to existing features
This update ensures Odoo's Dutch reporting modules (SBR, ICP, and Status Info) correctly submit data to the new Digipoort infrastructure, effective May 1, 2026. This migration is required by the Dutch government and prevents submission failures. It also confirms the need for valid PKIoverheid certificates.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668Resolved issues and error corrections
This update fixes an issue where the DMFA report incorrectly displayed '5' for 'Days Per Week' when employees worked fewer than 5 days a week. The fix adjusts the calculation to accurately reflect the employee's actual working schedule, ensuring accurate reporting for Belgian payroll compliance.
Original PR description
## Issue When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5. ## Steps to reproduce 1. Install…
## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.
## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
- set *ONSS Registration Number* to `0830123456`
- set *DMFA Employer Class* to `083`
- create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
- Work from 8:00 to 12:00
- Lunch from 12:00 to 13:00
- Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
- In the *Payroll* tab, set the start date of the contract to 01/01/2026.
- In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**
## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.
opw-6103934This update corrects a technical issue preventing the import of product data using the standard Odoo import process. The problem stemmed from an outdated configuration requiring a specific CSV format with a header row. This fix ensures the import process functions correctly, allowing for seamless data updates.
Original PR description
with header true still it gives the error because copy feature still need to pass explicitly CSV FORMAT. ``` Traceback (most recent call last): File…
with header true still it gives the error because copy feature still need to pass explicitly CSV FORMAT.
```
Traceback (most recent call last):
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/modules/loading.py", line 481, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/modules/loading.py", line 366, in load_marked_modules
loaded, processed = load_module_graph(
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/modules/loading.py", line 234, in load_module_graph
migrations.migrate_module(package, 'post')
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/modules/migration.py", line 216, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
File "/tmp/tmpe_22i6y2/odoo/17.0/odoo/modules/migration.py", line 240, in exec_script
migrate(cr, installed_version)
File "/tmp/tmpe_22i6y2/enterprise/17.0/product_unspsc/upgrades/0.3/post-update-codes.py", line 16, in migrate
cr.copy_expert("COPY _upgrade_product_unspsc_code FROM STDIN WITH (DELIMITER '|', HEADER TRUE)", csv_file)
psycopg2.errors.FeatureNotSupported: COPY HEADER available only in CSV mode
```
https://upgradeci.odoo.com/upgradeci/run/294907
Co-authored-by: Pirols <pied@odoo.com>