Daily updates from Odoo
Wednesday, April 29, 2026
52 changes · saas-19.1
Enhancements to existing features
This update limits the duration of automatically recurring calendar events to 15 years by default, preventing excessive event creation and ensuring predictable scheduling. Administrators can adjust this limit for specific events if needed, maintaining event organization and reducing potential system load.
Original PR description
`forever` recurrent events could currently be created for 720 years into the future, leading to excessive and unnecessary event generation. This change limits the creation of forver recurrent events to a fixed horizon of 15 years (by default) in the future, ensuring predictable behavior and preventing unbounded recurrence. The maximum horizon can be adjusted through the system parameter `calendar.max_recurrence_years` for events that require a longer recurrence window. Task-5714633 Forward-Port-Of: odoo/odoo#247929
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insights into where funds are being matched, reducing confusion and improving accuracy. The changes were based on existing bank reconciliation components and now function on hover.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382 Forward-Port-Of: odoo/enterprise#106118
Resolved issues and error corrections
This update corrects a technical issue preventing proper export of Hong Kong payroll XML files to the IRD platform. The fix ensures the correct file encoding and format (including a required BOM) are used, resolving a compatibility problem. This ensures accurate data transmission for tax reporting.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115227
This update ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The fix also includes a minor correction to view strings.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update fixes an issue where unreconciling batch payments could unexpectedly revert vendor invoices to draft due to approval checks. The change allows for a necessary repost to complete the reconciliation process, even when third-party approval workflows are in place. This prevents users from needing to manually re-enter data.
Original PR description
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module…
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually. This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks. Steps to reproduce: 1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user 2. As a user without that approval right, post a vendor bill and register a payment 3. Add the payment to a batch payment 4. Reconcile a bank statement line with the batch payment 5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line) - Expected: the bill stays Posted. - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook. opw-6121448 Forward-Port-Of: odoo/enterprise#115241
This update resolves an issue preventing kiosks from correctly communicating with new IoT box images. The fix ensures the correct message format is used, allowing the IoT box to process data properly. This improves the functionality of kiosks connected to the new IoT box infrastructure.
Original PR description
The new IoT box images expect the websocket messages to contain just `iot_identifier` and `device_identifier` instead of a list of `iot_identifiers` and `device_identifiers`. This method that the kiosk calls to send a message to the blackbox was not updated, causing the IoT box to ignore the message. This commit fixes the issue by adding the `iot_identifier` and `device_identifier` to the message. Forward-Port-Of: odoo/enterprise#115497
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the visual consistency of the reporting interface. This resolves a minor cosmetic problem.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#114903
This update resolves an issue where livechat channels with AI agents were not appearing correctly. The fix corrects a coding error that was preventing the system from accurately counting agents associated with each channel. This ensures all livechat channels, including those utilizing AI, 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#111574
This update resolves a bug where pasting a list item directly into the HTML editor would cause the main content area of the application to disappear after saving. The fix ensures that newly pasted list items are correctly wrapped within a list container, preventing the browser from incorrectly removing surrounding elements.
Original PR description
Problem: Pasting a `<li>` element inside a header block caused `<main>` and `<footer>` to disappear after saving. The browser's HTML parser ejects everything following an orphaned `<li>` (one without a `<ul>`/`<ol>` parent) out of its ancestor tree. Cause: The root cause was `closestElement(selection.anchorNode, listElementSelector)` finding a `<ul>`/`<ol>` ancestor that was not a direct parent of the insertion point, resulting in a `<li>` being inserted without a wrapping list element. Steps to reproduce: - Copy a `<li>` element and paste it in the Text Element in the header. - Save - `<main>` content disappears from the page. opw-6113857 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260320
This update resolves a layout problem in the Safaricom POS payment method configuration form. The previous design caused the right column to disappear, making it difficult for users to set up payment terminals. The fix simplifies the view structure, ensuring the form displays correctly and functions as intended.
Original PR description
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right…
The nested `group` elements in the `pos_payment_method_views.xml` view in `pos_safaricom` caused the layout of the form to break when the module is installed. More specifically, the entire right column of the form loses all the field labels, making it very difficult to fill out the information to configure a payment terminal. This commit fixes the issue by removing the `group` elements from the view, instead just using the `field` elements directly as is done in other payment terminal modules. Before (Safaricom selected): <img width="678" height="504" alt="image" src="https://github.com/user-attachments/assets/9c41643f-1a98-4e44-9493-f0e6e8161a50" /> Before (Viva selected): <img width="674" height="371" alt="image" src="https://github.com/user-attachments/assets/409f5c7a-da13-4f90-8145-a1ed5d6bbf7f" /> After (Safaricom selected): <img width="674" height="531" alt="image" src="https://github.com/user-attachments/assets/a3118563-39a3-4c41-a807-296e531abe58" /> After (Viva selected): <img width="665" height="447" alt="image" src="https://github.com/user-attachments/assets/51140a28-1fca-4d94-a81e-d45e081024a2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261746
This update addresses a visual glitch in the composer where applying a list alignment option would sometimes cause a brief flicker and fail to apply correctly. The fix prevents a 'blur' event from triggering unnecessary DOM duplication, ensuring list alignment works reliably the first time.
Original PR description
Problem: When the chatter is open and text is selected, applying a list from the toolbar causes a flicker, and the list is sometimes not applied on the first attempt. Cause: Opening the list dropdown triggers a `blur` event on the `html_editor` field, which calls `getInlinedEditorContent` and duplicates the DOM to perform inlining. This unnecessary processing causes the visual flicker and may interrupt the list application. Solution: Prevent the field from blurring when selecting a list alignment option from the toolbar. Steps to reproduce: - Open a new record. - Open the composer. - Add text and select it. - Apply a list using the toolbar. - Observe that sometimes the list is not applied on the first try and the content briefly flickers. opw-6153261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261476
This update resolves an issue where invoices generated with the l10n_sa and l10n_sa_edi modules were displaying a duplicate tax number. The change ensures that company details now print the tax number only once, improving invoice accuracy and presentation. This was triggered by a previous update.
Original PR description
Before this change: - the additional_company_details would print a second tax number to invoice printout in l10n_sa After this change: - company details will print tax number only once Forward-Port-Of: odoo/odoo#261272
This update resolves an issue in the Bangladesh localization where an incorrect expense account was being automatically applied to inventory valuations. Removing this forced setting ensures that inventory accounting aligns with standard Bangladesh regulations and avoids unexpected stock variations.
Original PR description
Issue: The Bangladesh chart template sets account_stock_expense_id on the inventory valuation account. This triggers Stock Variation entries following perpetual continental behavior, which is not expected for Bangladesh localization. Cause: l10n_bd template data explicitly populated `account_stock_expense_id` for account `l10n_bd_100502`. Solution: Remove `account_stock_expense_id` from the Bangladesh account template mapping. opw-5944874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261311
This update corrects an issue where signatures were incorrectly duplicated on generated order PDFs after a signed order was modified. Moving forward, signatures will only be printed on documents created directly by the signature process, ensuring consistency and accuracy in order documentation. This enhances the reliability of our sales records.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170 Forward-Port-Of: odoo/odoo#261288
This update resolves an issue where the automated report generation process (cron) incorrectly fetched vendor invoices when running with a default company different from the intended target companies. The fix ensures invoices are retrieved from the correct company, preventing errors and improving the reliability of the reporting process.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
This update corrects a display issue where portal users could see a 'View Timesheets' button on invoices, even if they lacked the necessary permissions. The fix ensures the button only appears for users who actually have access to the related timesheets, improving data security and user experience.
Original PR description
sale: add sale order specific hook to extend page values ------ Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values sale_timesheet: hide 'View Timesheets'…
sale: add sale order specific hook to extend page values
------
Allows adding custom data (e.g., timesheets) without overriding generic _get_page_view_values
sale_timesheet: hide 'View Timesheets' button for users without access
-------
Steps to Reproduce:
-----------------
- Create a product with the invoice policy set to Based on Timesheets
- Enable Project and Tasks on the order.
- Create and confirm a sale order using a portal user.
- Log timesheets on the related task.
- Create an invoice from the sale order.
- Log in as the portal user and open the invoice.
- Click the 'View Timesheets' button.
Issue:
-------------
The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.
Root Cause:
------------
The timesheets are linked to the sale order, so the button appears based on the timesheet_count, but the portal user does not actually have permission to access those timesheets.
Fix:
-----------
We replaced the timesheet_count check with a check that verifies whether the user actually has access to any of the related timesheets.
task-4745519
Forward-Port-Of: odoo/odoo#261681
Forward-Port-Of: odoo/odoo#209552This update resolves a bug where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix involved updating a helper method to ensure users only see the button when they have the appropriate access rights, improving the user experience and preventing confusion.
Original PR description
**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115193 Forward-Port-Of: odoo/enterprise#113481
This update fixes an issue where tax return rounding wasn't correctly applied when a company had multiple branches. The previous system aggregated rounding values, leading to inaccurate closing entries. The fix ensures that rounding is calculated and applied correctly for each company and branch, improving tax reporting accuracy.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This update resolves an issue where generating timesheets after archiving an employee would trigger an error. The fix prevents timesheets from considering time-off requests for previously archived staff, ensuring accurate timesheet generation. This improves data integrity and prevents disruptions to payroll processes.
Original PR description
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should…
[FIX] project_timesheet_holidays: Exclude archived employees from time-off # Description of the issue/feature this PR addresses: ## Steps to Reproduce: 1. Create a time off for Employee A (it should affect the timesheets). 2. Create a new public holiday (global time off) that overlaps with Employee A’s time off. 3. Archive Employee A. 4. Delete the public holiday created in step 2. 5. An error related to timesheet generation appears. ## Expected Behavior: - The public holiday / global time off should be deleted without any error. # Desired behavior after PR is merged: ## Fix (Implemented): When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees. ## Alternative Fix (Not Implemented): Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved. ## Version: This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0 but didn't directly test ## Task: [5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261412 Forward-Port-Of: odoo/odoo#244203
This update resolves an issue where the 'Remove Format' function would get stuck in an infinite loop when applied to text with icons and background colors in the To-do app. The fix ensures that icons are correctly identified and processed during format removal, preventing the loop and restoring normal functionality.
Original PR description
Steps to reproduce: =================== 1. Open the To-do app and pick any task. 2. In the description add text and an icon with a bg color. `(you can add this: <i class="fa rounded rounded-circle…
Steps to reproduce: =================== 1. Open the To-do app and pick any task. 2. In the description add text and an icon with a bg color. `(you can add this: <i class="fa rounded rounded-circle fa-user bg-o-color-1 fa-4x" contenteditable="false"></i>)` 3. Select all and click "Remove format". Result: -> Traceback due to an infinite loop. Cause: ====== Remove format calls `removeAllColor()`, which loops forever at: https://github.com/odoo/odoo/blob/626bde21a25366d0bb29662bae2057c247a1638e/addons/html_editor/static/src/main/font/color_plugin.js#L194-L194 Why: _applyColor doesn't remove the icon's background class, so hasAnySelectedNodeColor keeps returning true and the removal loop never terminates. This happens because `font` is already the `<i>` element with the `fa` class, using `querySelectorAll` on it won't include the element itself, so the icon is never checked or updated. https://github.com/odoo/odoo/blob/6cdc6f55886ea48e90f9023a6c6142bf072745b9/addons/html_editor/static/src/main/font/color_plugin.js#L290 Solution: ========= Check if the font itself has the fa class before doing the `querySelectorAll`, and include it in the nodes to check for color. Test Impact: ============ Before this fix, a `<span>` containing an icon was wrapped in a `<font>` when applying color, treating the icon as a normal span (without size) instead of applying the color directly. https://github.com/odoo/odoo/blob/8792c2d38eb0aadac8d778d83fd76f270404ecd5/addons/html_editor/static/src/main/font/color_plugin.js#L397 opw-5928627 Forward-Port-Of: odoo/odoo#261405 Forward-Port-Of: odoo/odoo#248449
This update resolves a technical issue preventing blackbox orders on self-order kiosks from generating correct receipts. The change re-introduced a necessary field, '_server_version', to the configuration, ensuring the kiosk can properly validate and create receipts. This ensures consistent receipt generation for a critical point of sale function.
Original PR description
In odoo/odoo#258744, the `pos_self_order` module was optimised to only send the fields required for the kiosk to function. This also meant the `_server_version` field was no longer sent in the `pos.config`. Because of this, there is now a traceback when validating a blackbox order in the self order kiosk, as it relies on the `_server_version` field to make the receipt. This commit fixes the issue by adding the `_server_version` to the `pos.config` as an override in the `pos_blackbox_be` module.
This update resolves an issue where reports for Withholding Taxes (WHT) were incorrectly mixed with VAT closing entries. Removing the specific return type for WHT ensures accurate reporting and prevents data confusion, leading to more reliable financial data. This improves the clarity and accuracy of financial reports.
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
This update addresses a problem where payruns were incorrectly flagged as missing in the 19.1 release for the Belgian HR Payroll module. The fix removes a dependency on company-level closing dates, aligning the payrun logic with a previous request (GMF). This ensures accurate payrun generation and reporting.
Original PR description
In this commit, we removed the missing payrun issue from 19.1, since we are missing the closing_date in company-level and the missing payrun should depend on that value (GMF request). task-6008297
This update fixes an issue where byproducts added directly to manufacturing orders weren't correctly linked to stock movements. Now, byproducts added to MOs are properly tracked, ensuring accurate inventory and production reporting. This improves the reliability of shop floor data.
Original PR description
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a…
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a Manufacturing order * Add the Product tracked by serial number on the MO as byproduct * Confirm the MO * Go to shop floor * Add the by-product quantity and create a new serial number. * Close production and go back to the MO in manufacturing * Open stock moves -> the by-product does not have "production" for origin Observation: ------------- When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM. When adding the byproduct in shopfloor, it will create the quant: https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171 Additionaly when creating the quant it will decide the source location depending if the product its a byproduct: https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192 The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110 #### Additional notes: The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false opw-5974582 Forward-Port-Of: odoo/enterprise#110122
This update resolves an issue where commission calculations were failing for recurring subscription orders due to an empty currency rate table. The fix adds a fallback rate, ensuring commissions are correctly applied when currency rates are not initially populated. This prevents lost revenue and ensures accurate commission payouts for subscription-based sales.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update fixes an issue where the ewallet discount was incorrectly included in delivery calculations. The change adjusts the pricing logic to accurately exclude ewallet amounts from delivery costs, ensuring consistent and accurate shipping charges for customers. This improves the customer experience and prevents overcharging.
Original PR description
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99…
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99 => delivery price = 50 3- Create a eWallet with balance = 200. 4- Create a SO add a line with product. Set the SOL unit amount to 100. 5- Click on `add a shipping`. Add the created delivery method. 6- As you see, the delivery amount is correctly calculated. 7- Now apply the eWallet using `reward` button. 8. Update the shipping cost. The shipping cost is 30, which is not expected. Cause: --- In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount. However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`. Fix: --- We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards. opw-6124209 Forward-Port-Of: odoo/odoo#260134
This update allows accountants to retain KSEF XML files associated with invoices. Previously, these files were automatically discarded after being used to fetch data. Now, the XML files are attached to the corresponding invoice, providing a permanent record for accounting and compliance needs.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update resolves an issue where the product description text area on iOS devices (specifically with Safari) would jump unexpectedly when typing. The fix removes a problematic sizing setting that was causing inaccurate scroll height calculations, ensuring the description field behaves correctly and allows users to enter text without the text area shifting.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that totals align with the sum of invoices, providing more accurate reporting for partner transactions. This improves the reliability of financial data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update fixes a technical issue that prevented users from leaving live chat channels without triggering an error. The fix ensures the channel leaving process is executed only once, preventing access problems. This improves the stability and usability of the live chat feature for all users.
Original PR description
When a non-livechat user leaves a livechat channel after being invited, an access error occurs. This is due to `leaveChannelRpc` being called twice: once in `_onClose`and again in `leaveChannelProcess`. The first call removes the membership, while the second attempts to access the channel without proper rights, triggering the error. This commit fixes the issue by ensuring that `leaveChannelRpc` is only called once when leaving the channel. Task-[6072247](https://www.odoo.com/odoo/project/1519/tasks/6072247)
This update resolves an issue preventing the deletion of time off allocations when created after a payslip has been validated. Previously, the system incorrectly blocked deletion, requiring manual adjustments through HR. This change ensures time off can be deleted regardless of when it was created relative to payslip validation.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## 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 Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
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."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990
Forward-Port-Of: odoo/enterprise#114895This update fixes an error in how emission factors are converted within the Odoo Enterprise ESG module. The previous process incorrectly handled unit and currency conversions, leading to inaccurate calculations. This change ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115246
This update fixes a visual issue in the invoice report where long 'Source Invoice' names would overlap with the 'Reference' field. A small margin has been added to the 'Source Invoice' block to create more space and improve readability. This ensures a cleaner and more professional appearance of the report.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This update resolves an issue where unit prices were not being rounded correctly when generating invoices for Peppol transactions. This fix ensures accurate pricing calculations for international trade and compliance with Peppol standards. The change reverts a previous commit that introduced this rounding problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870 Forward-Port-Of: odoo/odoo#261941
This pull request addresses an issue with testing related to invoice rounding in the l10n_mx_edi module. It reverts a previous change that introduced errors in the test files, ensuring accurate calculations and reporting. This update maintains the integrity of financial data within the Mexican Electronic Invoicing system.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115609
This update prevents users from starting polls while editing existing messages within channels or groups. Previously, the 'Start a Poll' action appeared misleadingly in the editor's menu. Now, the action is hidden when editing a message, ensuring it's only visible when composing a new message.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the composer, the 'Start a poll' action is displayed among the available options. Starting a poll while editing an existing message makes no sense, as polling is only meaningful when composing a new message. **Current behavior before PR:** ---------------------------------------------- - 'Start a poll' action appears in the composer 'More Actions' menu even when the user is editing an existing message - Clicking it while in edit mode opens the poll creation dialog, which is misleading and unintended behavior **Desired behavior after PR is merged:** ---------------------------------------------- - 'Start a poll' action is hidden from the 'More Actions' menu when the composer is in edit mode - The action continues to appear as expected when composing a new message in a channel or group conversation Task-6171541 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the size of the product search bar was incorrectly set, causing issues with a website tour. The fix ensures the search bar's size is only defined for the 'website_sale_renting' module, preventing disruptions to other website features.
Original PR description
__Before commit__ odoo/enterprise@1111381c set the size attribute of the product search bar. However, the view inherits from `website.website_search_box`, which means that all search boxes on the website will have the size attribute set if `website_sale_renting` is installed. The tour `dropdowns_and_header_hide_on_scroll` fails in saas-19.3 because odoo/odoo@9394e17a added a step that depends on the size of the main website search bar, which may vary because of this. __After commit__ Only set the size attribute to the product search bar as intended. runbot-242449
This update resolves minor issues within the point-of-sale test suite, specifically the checkTicketData() function. The changes ensure accurate test results by correctly handling empty data and preventing unexpected type conversions, ultimately increasing the reliability of our POS testing.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566This update fixes a minor bug in the tests for our Point of Sale system. Specifically, it corrects how the tests handle empty data results and prevents unexpected behavior when comparing values. These changes ensure the tests run reliably and accurately, maintaining the stability of the POS functionality.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566This update corrects a potential issue where Single Touch Payroll reporting was missed when payruns were submitted after the initial payment date. The fix now uses the payrun's creation date instead, ensuring accurate reporting to the ATO regardless of payment delays. This improves compliance and data reliability.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update fixes a discrepancy in the sale details report by accurately reflecting cash rounding adjustments. Now, the report displays the total cash rounding applied during a session, aligning with payment records and providing a clearer picture of financial transactions. This ensures greater accuracy and transparency in sales reporting.
Original PR description
The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#261671 Forward-Port-Of: odoo/odoo#254401
This update corrects a bug that appeared when editing appointment pages in the website builder. Specifically, an unnecessary attribute was removed from a component, preventing errors during debug mode. This ensures a smoother editing experience for users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741 Forward-Port-Of: odoo/enterprise#115242
This update resolves a minor issue where the IoT box pairing dialog could freeze indefinitely. Additionally, it corrects a localization problem where the 'Connecting' placeholder wasn't correctly translated in non-English versions. These changes ensure a smoother and more reliable experience for users adding IoT devices to their Odoo Enterprise system.
Original PR description
This commit fixes two small issues with IoT pairing: 1. When pairing an IoT box, even after the DB has discovered the IoT box and added it as a record, the dialog will keep waiting forever. If you close the dialog manually the IoT box appears as expected. 2. If using a language other than English, the placeholder 'Connecting' name will not be replaced when the IoT finishes pairing. The IoT box can still be used as normal however.
This update resolves a technical issue where an incorrect import statement was present in the adam_scale_driver.py file. This fix ensures the proper functioning of the point-of-sale system, preventing potential errors and maintaining system stability. The change is a routine bug fix.
Original PR description
This PR fixes the wrong import in adam_scale_driver.py opw-6173563
This update resolves an issue preventing users from switching between company and association fiscal localization settings in the Belgian version of Odoo. The fix clears references to old accounts in cash rounding configurations, allowing the localization switch to complete successfully. This ensures accurate financial reporting for Belgian businesses.
Original PR description
### Issue before this commit: Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The…
### Issue before this commit:
Switching the fiscal localization of a Belgian company from "Companies" to "Associations and Foundations" caused a traceback during the chart reload process. The operation failed because some accounts from the previous localization could not be deleted.
### Steps to reproduce the issue:
1. Download Accounting
2. Create a new Belgian company
3. Switch to that company
4. Go into Settings -> Fiscal Localization
5. Switch to Associations and Foundations
6. Traceback: The operation cannot be completed: Another model is using the record you are trying to delete. The troublemaker is: 'Account Cash Rounding' (account.cash.rounding). Thanks to the following constraint: 'Profit Account' (profit_account_id). How about archiving the record instead?
### Cause of the issue:
The Belgian localization creates a default cash rounding method ("Round to 0.05") linked to specific profit and loss accounts. When switching localization, it was tried to delete the old chart of accounts, but these accounts are still referenced by account.cash.rounding through profit_account_id and loss_account_id, which use ondelete='restrict'. This prevents account deletion and blocks the localization change. Commit that caused the issue: https://github.com/odoo/odoo/commit/412fc9bed36645dd950c9a60d9b6ffdd9b4bce67
### Reason to introduce the fix:
Before reloading the Belgian chart template, the fix clears the profit_account_id and loss_account_id on the existing cash rounding records. This removes the blocking references, allows the old accounts to be deleted safely, and lets the fiscal localization switch complete successfully without affecting existing cash rounding configurations.
opw-6050537This update resolves an issue where overtime hours were not being correctly calculated in payslips. The team restored a missing data file and corrected a reference, ensuring that work entry types are properly linked to overtime rulesets. This will now accurately reflect overtime hours for payroll processing.
Original PR description
Issue: The issue here is that work_entry_type is not associated with the overtime ruleset. That's why when creating a payslip, it is not considering overtime hours. From this PR - https://github.com/odoo/enterprise/pull/98952 the data file is missing from the manifest file. Fix: Added back file to manifest and fixed reference for work_entry_type_id. task-6073921
This update optimizes the PDF generation process for Saudi companies using the l10n_sa_edi_pos module. Previously, PDF creation was a major bottleneck, slowing down checkout times. Now, PDFs are only generated on demand, aligning with ZATCA requirements and improving the cashier experience.
Original PR description
For SA companies, wkhtmltopdf PDF generation was accounting for ~47% of the sync_from_ui response time (~3.1s out of ~6.5s total), blocking the cashier at every order. The PDF is not needed during checkout: ZATCA requires only the signed XML and returns the QR code. The PDF can be generated on demand when the invoice is first viewed or downloaded. opw-6019994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260757 Forward-Port-Of: odoo/odoo#253641
This update fixes an issue where combo products weren't consistently ordered according to their choices, leading to incorrect item sequences in sales orders. The fix ensures combo items are always displayed in the correct order defined by the product's combo options, improving the user experience and order accuracy.
Original PR description
When creating a combo product, its items were not ordered according to the combo choice sequence, and extra items were always appended at the end. As a result, combo items could appear in the wrong order. This fix ensures that, when computing combo prices and merging combo items with extra items before creating the order lines, the correct sequence is derived from the parent product. All items are then sorted based on this sequence so that they consistently follow the order defined by the combo choices. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6064642 Forward-Port-Of: odoo/odoo#255596
This update resolves an issue where the POS system was loading all employees, regardless of their employee type, leading to performance slowdowns. The change now ensures that only basic employees are loaded during a POS session, improving the system's responsiveness and efficiency. This enhancement focuses on a technical fix to optimize the POS experience.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259730 Forward-Port-Of: odoo/odoo#247043
This update fixes an issue where all employees were loaded into POS sessions when specific employee types were used. Now, only the basic employee assigned to the POS configuration is loaded, improving performance and reducing unnecessary data loading. This change enhances the overall POS experience.
Original PR description
Before this commit, when some employee was assigned to advanced or minimal employee, all of the employees were loaded in the POS session, because there was no basic employee assigned to the POS config. opw-5898068
This update corrects a technical issue where quotation templates linked to tasks were incorrectly assigning task IDs to non-product lines (like notes). This prevented proper task completion and could lead to data errors. The change ensures that task IDs are only applied to product lines within a quotation template.
Original PR description
When a sales order is created from a task, if a template is used, the first line is given a task ID from the context's default_task_id. If this first line were to be a non-product line (section/note), this would still be given a task_id. This is unneeded and can cause issues such as a float precision error when trying to mark the task as done. This change checks to see if the line has a display_type, in which case it will set the task_id to false. Steps to reproduce: 1. Create a new Quotation Template with a single section line 2. Create a new project 3. Open the project settings 4. Enable 'Billable' and 'Extra Quotations' 5. Create a new task 6. Select 'New Quotation' 7. Select the quotation template with just a section 8. Enter customer (to allow saving) 9. There will be a single order line, a section, with a task_id opw-6122235 Forward-Port-Of: odoo/odoo#261298
This update resolves an error preventing users from accessing the Spain VAT Books report within the Odoo Enterprise system. The issue stemmed from an outdated template referencing a removed condition, which caused a search failure. This fix ensures the report functionality is restored for Spanish companies.
Original PR description
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath…
**Steps to reproduce:** - Install the `l10n_es_reports` and `accountant` modules. - Switch to an ES Company. - Navigate to Accounting > Reporting > Spain > `VAT Books`. **Error:** `Element '<xpath expr="//button[@t-if='this.props.line.chatter and !this.ui.isSmall']" position="replace"/>' cannot be located in element tree` **Root Cause:** After commit [1], the condition `this.ui.isSmall` was removed from the template `account_reports.AccountReportLineNameCustomizable` at [2]. However, the inherited template `l10n_es_reports.VatBooksLineName` was not updated accordingly and still references the old condition, which leads to the error. **Fix:** This commit prevents errors and ensures that users can open the `VAT Books` report by applying a fix similar to [2]. [1]: https://github.com/odoo-dev/enterprise/commit/fd0afa474600586e8703ec377f962c8d7d94307a [2]: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/account_reports/static/src/components/account_report/line_name/line_name.xml#L81 opw-6169697 opw-6170173 Forward-Port-Of: odoo/enterprise#115412