Daily updates from Odoo
Friday, May 22, 2026
263 changes
8 changes
Enhancements to existing features
This update simplifies the payment process by removing a rarely used field – the Payment Identifier – from the payment form. This change improves the user experience by reducing clutter and focusing on the essential information needed to complete payments. The change was driven by a community suggestion to improve clarity.
Original PR description
The Payment Identifier field has been permanently hidden from the payment form view, as it does not provide actionable or useful information to the end user. see community pr - https://github.com/odoo/odoo/pull/266072 task-6237870
This update allows Odoo to send invoices in larger batches, streamlining the process of transmitting invoices to tax authorities. The system now handles multiple invoices simultaneously, reducing the number of individual transmissions and improving overall efficiency. This change enhances the speed and reliability of invoice submission.
Original PR description
This commit allows sending invoices in batches. - Invoices are now chunked into safe batch sizes. - The web service response logic is updated to handle and map results for multiple documents at the same time. task-6139646
Resolved issues and error corrections
The HTML Editor's code toolbar was displaying incorrectly on mobile devices due to a font size conflict. This update resolves this issue, ensuring the code toolbar appears correctly and consistently across all devices, improving the user experience for mobile users. This is a minor fix to enhance usability.
Original PR description
Currently syntax highlighting toolbar UI is broken in mobile devices. This happens because code toolbar button's font-size (12px) is overridden by webclient.css `.btn` class font-size (14px). This PR aims to fix the code toolbar's broken UI for mobile devices. task-6201174 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where tax calculations were incorrectly split on discount lines, particularly when changing the fiscal position to Quebec. The fix ensures accurate tax application by preventing the duplication of tax rates, maintaining the original tax structure for consistency.
Original PR description
Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`.…
Steps to produce: --- - Install `website_sale`, `l10n_ca` & `accountant` modules with demo data. - Switch to a `Canadian (CA) company.` - Go to Settings and enable` Discounts, Loyalty & Gift Cards`. - Go to` Website > eCommerce > Loyalty > Discount & Loyalty.` - Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order. - Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence). - Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product. - Open the website in an incognito window > Add the product to the cart > Apply the discount code. - In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes. Issue: --- - The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST. Root cause: --- - When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST. - After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST. - In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur. - In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line. Fix: --- - Avoid splitting taxes on the discount line in the sale order. - Keep the original tax structure intact to prevent duplication after fiscal position changes. [1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156 [2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296 opw-6145674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265233 Forward-Port-Of: odoo/odoo#262147
This update fixes an issue where a white background on the website would interfere with the appearance of product details. The change removes a conflicting white background from the product information card, ensuring a cleaner and more visually appealing design when using website backgrounds. This improves the overall user experience.
Original PR description
When a background is set on the website, we can't remove the background of the product information card making the design unaesthetic Steps to reproduce: 1. Install eCommerce 2. Go to Website and click on Edit in the top right corner 3. Open the "Theme" tab, set an image (not plain white) to the website's background and save 4. Go to the shop and open any product 5. The product details are shown on a white block that disrupts the background image Issue: We set a background-color on `#product_details` with value `$body-bg` which is an opaque white Solution: Remove the white background of `#product_details` opw-6214514 Forward-Port-Of: odoo/odoo#265021
This update fixes a potential error that could cause a traceback when users deleted images from media items on the website. The change now gracefully hides the image option and provides an 'add image' option instead, ensuring a smoother user experience. This prevents disruptions and maintains website functionality.
Original PR description
Before this commit, the deletion of a `s_media_list_item` image triggered a traceback because `SetMediaLayoutAction.isApplied()` attempted to calculate the option's state on a missing element. Steps to reproduce: - Enter edit mode - Drop `s_media_list` snippet - Select the first media item - Delete its image - The image is deleted, but a traceback appears This commit hides media layout options when the item has no image and introduces an add image option instead. task-6229179 Forward-Port-Of: odoo/odoo#265271
This update fixes a visual issue where content in the user rights widget sometimes overflowed, causing a cluttered display. The change adds scrolling functionality to the popover component, ensuring all information is visible and accessible. This improves the user experience for managing user permissions.
Original PR description
This PR adds the `overflow-auto` class to the popover component to enable scrolling and prevent content overflow. **Task-ID: 6137031** Forward-Port-Of: odoo/odoo#261216
This update resolves a technical issue preventing invoices with Early Payment Discounts (EPD) and 0% tax from passing schematron validation, a requirement for Peppol compliance. The fix ensures accurate VAT breakdown generation, correcting a previous error where duplicate tax categories were created and a hardcoded tax code was used. This ensures invoices meet regulatory standards and avoids potential processing delays.
Original PR description
Before this commit, creating an invoice with an Early Payment Discount (EPD) as a payment term could cause the schematron validation of the generated invoice to fail when an invoice line had a 0% tax. The issue was caused by generating two TaxSubtotal nodes for the same TaxCategory (0%, exemption code 'E'): - one for the 0% VAT - one for the EPD discount applied to the total amount However, Peppol requires a single VAT breakdown (TaxSubtotal) per VAT category (in this case: E) Additionally, when VAT was set to 0%, the allowance charge TaxSubtotal incorrectly used 'S' as a hardcoded tax category code. This commit fixes both issues. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264302 Forward-Port-Of: odoo/odoo#254199
20 changes
Resolved issues and error corrections
This update fixes an issue where discounted UBL invoice lines were being incorrectly removed during import. Previously, lines with a zero total amount were filtered out, even if the supplier had applied a discount. Now, the system correctly keeps these lines, ensuring accurate reconciliation between invoices and original documents, particularly for returns or discounts.
Original PR description
`_import_ubl_invoice_add_base_lines` filters out every imported line whose `total_included_currency` is zero, on the assumption that a zero-amount line carries no useful information. This is correct for truly empty rows, but wrong for 100%-discounted lines, an ecotax or excise row, or a returnable-packaging entry nets to zero precisely because the supplier discounted it entirely, and the line still carries data the customer needs to reconcile the bill against the original document opw-6176349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265284
This update resolves an issue where PDFs with multiple XML attachments (using the /Kids structure) weren't being correctly extracted in Odoo bills. The fix ensures that all embedded XML files are now properly recognized, preventing empty bills and ensuring accurate data retrieval. This improves the reliability of bill generation.
Original PR description
Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274 Forward-Port-Of: odoo/odoo#255798 Forward-Port-Of: odoo/odoo#252523
This update corrects a bug that allowed portal users to unintentionally delete documents they shouldn't have. The fix ensures that portal users can only delete documents they own, preventing data loss during the standard cron archiving process. This improves data integrity and user control.
Original PR description
Reproduce: with rpc call as portal user, you can archive documents you have access to. This is not desired as this may lead to records being deleted when the cron collects the trash, but we only wanted to support portal users deleting only records they own. What we did when calling toggle_active should be done for all calls to `write` with `active`. It also removes the need for `_raise_if_unauthorized_archive` and `_unlink_except_unauthorized`. Task-6205627 Forward-Port-Of: odoo/enterprise#117647 Forward-Port-Of: odoo/enterprise#116886
This update resolves an issue where the generic tax report wouldn't display an error message when dealing with negative net values. The fix ensures the report accurately checks for tax discrepancies, even when balances are negative, preventing misleading results.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update resolves an issue where UBL invoices sent via Peppol were failing due to an incorrect VAT number format for Norwegian suppliers. The fix ensures the VAT number is correctly formatted ('NO179728982MVA') during invoice creation, allowing successful export and delivery.
Original PR description
**Steps to reproduce:** * Install a Norwegian localization (e.g. **l10n_no**). * Set up a company with a valid Norwegian VAT number (e.g. **NO179728982MVA** or just **179728982**). * Create a…
**Steps to reproduce:**
* Install a Norwegian localization (e.g. **l10n_no**).
* Set up a company with a valid Norwegian VAT number (e.g. **NO179728982MVA** or just **179728982**).
* Create a customer invoice and send it via **Peppol** (format: **UBL BIS Billing 3.0.12**).
**Observed behavior:**
* The EDI document creation fails with: "The VAT number of the supplier does not seem to be valid. It should be of the form: NO179728982MVA."
* The error occurs even when the VAT number is correctly formatted.
**Cause:**
* Commit 186ad1db refactored the party node building by removing `_get_party_node()` and replacing it with granular `_ubl_add_party_*_nodes()` methods. The Norwegian VAT normalization block (introduced in task-5448941) that set `supplierCompanyID` on the party node lived inside `_get_party_node()` and was not ported to the new architecture, leaving `supplierCompanyID` never set.
* The NO-R-001 constraint in `_invoice_constraints_peppol_en16931_ubl()` reads the VAT from `party_node.get('supplierCompanyID')`, which now always returns `None`, causing `mva.is_valid(None)` to return `False` and the constraint to always fail.
**Fix:**
* Port the missing normalization logic into `_ubl_add_accounting_supplier_party_tax_scheme_nodes()`: prepend `NO` and append `MVA` to the VAT if not already present, then assign the normalized value to `party_node['supplierCompanyID']` and update `PartyTaxScheme[0]/CompanyID` when a VAT node exists.
* Handle the `NO` case in `_ubl_add_party_legal_entity_nodes()` to write the normalized VAT into `PartyLegalEntity/CompanyID`.
opw-6215400This update increases the maximum time allowed for printing documents to 90 seconds. Previously, documents taking longer than 30 seconds would fail to print. This change ensures users can successfully print larger documents without interruption.
Original PR description
To allow printing large documents that take more than 30 seconds to print, we increase the timeout to 90 seconds. opw-6235827
This update simplifies the process of inserting Dynamic Fields within Odoo's Powerbox interface. The change adds a keyword search for 'dynamic placeholder,' catering to users accustomed to this method. This ensures a smoother experience and continued usability for existing workflows.
Original PR description
This PR adds a search keyword so users who were used to dynamic placeholder to insert the Dynamic Field command can still find it in powerbox. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where an error was incorrectly triggered when longpolling requests were aborted. The fix ensures that the 'unreachable' error is only sent when a request genuinely fails, improving the stability of the IoT service and its fallback to websocket listeners. This prevents unnecessary errors and maintains smooth operation.
Original PR description
In odoo/odoo#260931, new logic was added to raise an 'unreachable' error in the case where a longpolling listen request failed. This error was then used by the IoT HTTP service to fallback to a websocket listener. However, due to an oversight this 'unreachable' error was also being triggered whenever the longpolling listen request was aborted, which happens whenever a new listener is added. This commit fixes the issue by checking the error type and only sending the 'unreachable' error if the request was not aborted. opw-6175686 Forward-Port-Of: odoo/enterprise#117905
This update resolves an issue where the ecommerce file viewer on the website displayed multiple instances simultaneously when the livechat module was active. The fix ensures that only one file viewer appears, improving the user experience and preventing visual clutter. This was caused by a misconfiguration in how the livechat module passed its identification information.
Original PR description
Before this commit, ecommerce file viewer on website may show more than 1 file viewer at once. This happens because when livechat is installed, the overlay container of livechat mistakenly shows the overlay, therefore the overlay is displayed on main page's overlay container and on the livechat container. The regression was made with [1], where the root id is not longer picked from a target DOM but instead relies on the `env`. This change was motivated to fix a flicker, but the tradeoff is that this requires good passing of the `env` with `rootId`. This was properly set on `MainComponent`, but the overlay container of livechat is exceptionally not the `MainComponent` but instead in `LivechatRoot` that is manually mount. This app lacked the `rootId` in the `env`, which this commit solves. opw-6227540 [1]: https://github.com/odoo/odoo/pull/263860 Forward-Port-Of: odoo/odoo#265603
This update fixes a visual issue in the stock picking operations report, where the table lacked borders, making it difficult to read. The change restores table borders, improving the report's clarity and allowing users to easily distinguish between operations. This ensures a better user experience when reviewing stock movements.
Original PR description
Issue before this commit: ========================= The picking operations report displays the operations table without borders, making it difficult to read and distinguish between rows and columns.…
Issue before this commit: ========================= The picking operations report displays the operations table without borders, making it difficult to read and distinguish between rows and columns. Steps to Reproduce: ========================= - Install the stock module - Create a delivery order with products - Print the picking operations report Cause of the issue: ========================= In this commit (https://github.com/odoo/odoo/commit/21cd7e6), the `o_report_stockpicking_operations` class was added to a div, which removed the table borders. After This Commit: ========================= This change restores the table borders in the operations report, improving readability. Before: <img width="796" height="523" alt="2026-04-17_16-30" src="https://github.com/user-attachments/assets/084861e9-3c5b-4ca7-a237-32a56bf2267d" /> After: <img width="795" height="596" alt="2026-04-17_16-30_1" src="https://github.com/user-attachments/assets/e43ed341-8e8b-47c9-9820-66a53823b26c" /> Task: 5462122 Forward-Port-Of: odoo/odoo#253498
This update fixes a potential error that could cause a traceback when deleting images from media items in the website builder. The change hides the image option when no image is present and adds an 'add image' option, resulting in a smoother and more reliable editing experience. This prevents disruptions during website customization.
Original PR description
Before this commit, the deletion of a `s_media_list_item` image triggered a traceback because `SetMediaLayoutAction.isApplied()` attempted to calculate the option's state on a missing element. Steps to reproduce: - Enter edit mode - Drop `s_media_list` snippet - Select the first media item - Delete its image - The image is deleted, but a traceback appears This commit hides media layout options when the item has no image and introduces an add image option instead. task-6229179 Forward-Port-Of: odoo/odoo#265271
This update fixes an issue where long text in m2m tags avatars was being cut off, creating a poor user experience. The change adds a 'truncate' class to ensure text is properly displayed with an ellipsis when it exceeds the available space, resulting in a cleaner and more readable interface.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 Before: <img width="322" height="189" alt="c5f23b6aee6f63982f530c2e6a641d21" src="https://github.com/user-attachments/assets/b50fc70d-4d21-4023-8838-460f060a98fb" /> After: <img width="310" height="167" alt="5ccf4bb07603a3d8c50d3763bd112f6d" src="https://github.com/user-attachments/assets/fa7e4167-98d8-47d7-a1e2-6639da8e5d05" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256817
This update fixes an issue where long text in m2m tags' avatar fields would overflow and be cut off. By adding a 'truncate' class, text is now automatically clipped with an ellipsis when it exceeds the available space, ensuring a cleaner and more professional appearance.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 https://github.com/odoo/odoo/pull/256817 Forward-Port-Of: odoo/enterprise#112590
This update corrects a bug where re-invoiced expenses on sales orders were incorrectly displaying the total expense amount as the unit price. The fix ensures that the quantity of the expense is properly reflected on the sales order line, resolving a pricing discrepancy. This improves the accuracy of sales order reporting.
Original PR description
Currently, when re-invoicing an expense paid by company, the line added to the sale order will show a price unit equal to the whole expense amount. Steps to reproduce: - Create a new Expense Category with Re-Invoice Costs set to 'At cost' - Create a new Expense, set the new category, and set Paid By to 'Company' - Set Quantity to greater than 1, and Customer to Re-Invoice to any Sales Order - Confirm and Submit Journal Entry on the Expense record Issue: - On the linked Sales Order you will see the total of the expense is used as the unit price This occurs because we don't pass the quantity to the move line creation vals, which then default to 1. In turn, when the sale order line is added, the unit price will be based on the move line vals but the quantity will match the expense. opw-5883290 Forward-Port-Of: odoo/odoo#246816
This update fixes a design issue where a background image set on the website would create a distracting white block when viewing product details. The fix removes the unnecessary white background from the product detail card, ensuring a cleaner and more visually appealing website experience for customers. This improves the overall aesthetic of the e-commerce site.
Original PR description
When a background is set on the website, we can't remove the background of the product information card making the design unaesthetic Steps to reproduce: 1. Install eCommerce 2. Go to Website and click on Edit in the top right corner 3. Open the "Theme" tab, set an image (not plain white) to the website's background and save 4. Go to the shop and open any product 5. The product details are shown on a white block that disrupts the background image Issue: We set a background-color on `#product_details` with value `$body-bg` which is an opaque white Solution: Remove the white background of `#product_details` opw-6214514 Forward-Port-Of: odoo/odoo#265021
This update fixes a minor display issue within the user rights widget, preventing content from overflowing and disrupting the user experience. The change adds scrolling functionality to the popover component, ensuring all information is visible and accessible. This improves usability and consistency.
Original PR description
This PR adds the `overflow-auto` class to the popover component to enable scrolling and prevent content overflow. **Task-ID: 6137031** Forward-Port-Of: odoo/odoo#261216
This update corrects a bug where certain quality control test types were incorrectly visible during work order creation. This change ensures that these test types are only accessible for manufacturing operations, aligning with intended functionality. The issue was caused by an optimization in Odoo's domain filtering system.
Original PR description
### Issue: The `Print Label`, `Register Production`, `Register By-products`and `Register Consumed Materials` are all available in the test types at control point creation. ### Expected behavior:…
### Issue:
The `Print Label`, `Register Production`, `Register By-products`and `Register Consumed Materials` are all available in the test types at control point creation.
### Expected behavior:
These test types are only meant for manufacturing operations and are supposed to be hidden by the field domain:
https://github.com/odoo/enterprise/blob/f56aa85b4ad32c5d9ad5593df1366d72e88da0e4/mrp_workorder/models/quality.py#L102-L104 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24
### Cause of the issue:
Since saas-18.1: 5ef007a2116e528b796ebe80fb291ba5f1a94c8f domains are optimised into equivalents SQL clause with better sql performances. This optimization results in the following match for boolean fields:
`('field', '=', True)` -> `('field', 'in', OrderedSet([True]))`
`('field', '=', False)` -> `('field', ' not in', OrderedSet([True]))`
Because of these:
https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1058-L1079 https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L1215-L1236
Now the issue is that the specific `search_method` of the `allow_registration` field is then called with this optimized domain: https://github.com/odoo/odoo/blob/82b16e8feb3d60a9a3855e3adb3164ae5a6c041d/odoo/orm/domains.py#L860-L866 https://github.com/odoo/enterprise/blob/00d6cccd75c402378698a6fd11ee2692f2361c7f/mrp_workorder/models/quality.py#L20-L24
And since `value` is defined as a non empty ordered set in both cases it the search method returns a True leaf as search domain.
opw-5915197
Forward-Port-Of: odoo/enterprise#117973
Forward-Port-Of: odoo/enterprise#117068This update corrects a translation issue in the Odoo Enterprise Gantt view. The button used to toggle display modes was not properly translated, preventing users from seeing the view in their preferred language. This commit adds a mechanism to dynamically generate the button title based on the current display mode, ensuring accurate translations.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
This update resolves a technical issue preventing invoices with Early Payment Discounts (EPD) and 0% tax from passing schematron validation, a requirement for Peppol compliance. The fix ensures correct VAT breakdown generation, addressing a previous error where duplicate tax categories were created and a hardcoded tax code was used. This ensures invoices are correctly formatted for international transactions.
Original PR description
Before this commit, creating an invoice with an Early Payment Discount (EPD) as a payment term could cause the schematron validation of the generated invoice to fail when an invoice line had a 0% tax. The issue was caused by generating two TaxSubtotal nodes for the same TaxCategory (0%, exemption code 'E'): - one for the 0% VAT - one for the EPD discount applied to the total amount However, Peppol requires a single VAT breakdown (TaxSubtotal) per VAT category (in this case: E) Additionally, when VAT was set to 0%, the allowance charge TaxSubtotal incorrectly used 'S' as a hardcoded tax category code. This commit fixes both issues. task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264302 Forward-Port-Of: odoo/odoo#254199
This update fixes an issue where WhatsApp channel avatars were incorrectly displaying the default Discuss avatar after a new member was added. Now, avatars are automatically pulled from the channel's WhatsApp member, ensuring users see the correct representation of the conversation participants. This improves the user experience and visual consistency within the WhatsApp channel.
Original PR description
WhatsApp sidebar avatars should be resolved from the channel's whatsapp member, not from an arbitrary non-self member. Before this fix, adding a member to a WhatsApp channel caused the default Discuss avatar to be displayed instead of the actual WhatsApp member's avatar. This happened because the correspondent was not correctly computed for channels of type whatsapp. task-[5879840](https://www.odoo.com/odoo/project/1519/tasks/5879840) Forward-Port-Of: odoo/enterprise#117794 Forward-Port-Of: odoo/enterprise#115745
28 changes
New functionality added to Odoo
This update adds a new test to ensure the structure of payment data sent to our payment processor, Odoofin, remains consistent. This proactive step helps prevent unexpected changes on Odoofin's side and ensures we're always aware of any necessary updates to our system. It's a small change designed to improve reliability.
Original PR description
Add a test asserting the payment payload structure sent to Odoofin. The goal is to safeguard against unintended payload changes that are not handled on Odoofin's side by making such changes explicit during testing, and reminding developers that corresponding updates may also be required there. No task ID Forward-Port-Of: odoo/enterprise#117537 Forward-Port-Of: odoo/enterprise#117260
Resolved issues and error corrections
This update fixes a visual issue in the termination fees report, ensuring payslips have a clean and properly aligned layout. The previous design used a fixed row count that caused misalignment when fewer lines were present. The fix dynamically adjusts the layout for better readability and consistency.
Original PR description
**Steps to Reproduce:** 1. Generate a termination slip for an employee 2. The generated payslip pdf layout looks clumsy and misaligned. **Bug Cause:** 1. The notice duration has rowspan="3" expecting 3 lines. When there are less than 3 lines, the following rows are affected and misaligned. 2. The border is missing. **Solution:** Added dynamic sizing for notice duration instead of static rowspan="3". Used index instead of line_count for both notice duration and banks to stay consistent and simple. Added table-bordered class as borders are not automatically applied like in previous versions. **Task:** 6193558
This update fixes an issue where alternating row colors were incorrectly applied, often resulting in the table header and first row having the same background color. The change ensures alternating row colors are consistently applied to odd rows, improving the visual clarity and readability of tables within the HTML editor.
Original PR description
### Purpose of this PR: Previously, alternating row colors were applied on even rows. When a table header was enabled, the header row and first body row could end up sharing the same background color. This PR updates the alternating row logic to apply colors on odd rows instead. task-6204622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where applying a combo to an order already sent to the backend would cause the original order items to reappear after a page refresh. The fix ensures that the order is synchronized with the backend after a combo is applied, providing a consistent and accurate view for the user.
Original PR description
Steps to reproduce: - Make an order that could be a combo - Send the order to preparation - Apply the combo - Refresh page => A new combo appears and the original orderlines are still there. Issue: When applying a combo to an order that has already been sent to the backend it is not synched with the backend so when you refresh the original orderlines are fetched from the backend. Fix: If the orderlines have been sent to the backend sync the order after applying the combo. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where Point of Sale orders weren't correctly calculating payments and invoices, leading to errors. The fix ensures that order details are properly updated during the validation process, resolving the 'No cash statement found' error and preventing 'entry not balanced' issues when generating invoices. This improves the reliability of the POS system.
Original PR description
### Steps to reproduce: - Download 'Point of Sale' and 'Contacts' app - Create a customer with a pricelist that includes a percentage discount - Create a shop with the following properties: - Default…
### Steps to reproduce:
- Download 'Point of Sale' and 'Contacts' app
- Create a customer with a pricelist that includes a percentage discount
- Create a shop with the following properties:
- Default preset = 'Takeout' with a standard 40hr/week schedule
- Payments = 'Card' and 'Customer Account'
- Pricelists = a 'Default' and the discounted pricelist
- Create a POS order (without choosing a customer)
- Add products to the order, and select 'Customer Account' payment method
- Select the created customer
* Pricelist applies → Order total decreases.
* Payment now exceeds total → Negative change shown.
- Disable 'Invoice' checkbox.
- Click 'Validate' → Show popup 'No cash statement found for this session.'
- Again click 'Customer Account' → Add another payment line (negative).
- Process the order payment
- Close Session
- Try to create an invoice for the order
> Error: Entry not balanced
### Cause of Issue:
When 'Validate' is clicked for the first time and `syncAllOrders()` is called, `serializeForORM()`
clears the `_dirty` state tracking after the serialization. https://github.com/odoo/odoo/blob/418b103dab782d81a33d2a7afd8ec3767d7a82df/addons/point_of_sale/static/src/app/services/pos_store.js#L1501-L1534
When the 'No cash statement found' error occurs, the backend rolls back the changes made to the
order lines.
Then, since the `order.lines` weren't marked as dirty (no changes occured to them) and `payment.ids`
were marked as dirty, when 'Validate' is clicked for the second time, the js side doesn't send the
`order.lines` again, so the backend uses the existing, undiscounted lines.
The mismatch happens because while the product lines are undiscounted, the `payment.ids` are
correct (because a new 'Customer Account' line was added, so `payment.ids` were sent again).
Hence, `amount_total` and `amount_paid` were calculated with discounts applied, while individual
`line.price_unit` values remained at list price, resulting in invoice line amounts not matching
the amount paid and causing "entry not balanced" errors during invoice generation.
### Fix:
Preserved the `_ dirty` state commands, ensuring that when the order is reserialized on retry,
the line data are included in the second `sync_from_ui` payload.
opw-6080597
Forward-Port-Of: odoo/odoo#259636This update resolves an issue where the delivered quantity for dropship products was incorrectly set to 1 before order confirmation. The fix ensures the quantity accurately reflects stock availability and triggers the necessary calculations when a purchase order is created, improving dropship order accuracy.
Original PR description
### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the…
### Steps to reproduce: - In the settings enable dropshipping - Create a storable product P, enable the dropshipping and set a vendor - Create and confirm a sale order for a field service - Open the related task > Products > Add 1 unit of P - Go back to the sale order > an RFQ has been created #### > The delivered quantity of P is set to 1 ### Cause of the issue: Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83 provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237 The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198 Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute). Fix: The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167 opw-6104326 Forward-Port-Of: odoo/enterprise#117727 Forward-Port-Of: odoo/enterprise#115760
This update fixes an issue where the End Balance figures in the Romanian Trial Balance reports were inaccurate when the report hierarchy was enabled. The fix prevents double-counting of account groups, ensuring the trial balance totals align correctly and provide accurate financial reporting for Romanian businesses.
Original PR description
### Issue before this commit: The total row for the End Balance columns in the Romanian 4-column and 5-column Trial Balance reports displayed incorrect values when the report hierarchy was enabled. ### Steps to reproduce the issue: 1. Downaload Accounting and l10n_ro 2. Switch to RO company 3. Go to Trial Balance report and be sure that Posted Entries, Accrual Basis are setted on Hierarchy and Subtotals 4. See that the End Blance both debit and credit is not correct ### Cause of the issue: The _custom_line_postprocessor method iterated over all report lines indiscriminately, adding account group subtotals to the running accumulator and causing duplicate counting. ### Reason to introduce the fix: To eliminate group double-counting and providing consistency with the totals in all the trial balances reports. opw-6146200 Forward-Port-Of: odoo/enterprise#117855
This update resolves an issue where employees on flexible work schedules were incorrectly flagged for overtime. The fix adjusts how the system calculates expected work hours, now accurately considering the employee's flexible calendar hours instead of relying on outdated synthetic schedules. This ensures accurate overtime calculations for employees with varied work arrangements.
Original PR description
**Steps to reproduce:** - Create a flexible 32h/week calendar (8h/day, 4 days) - Assign it to an employee with the Default Ruleset - Create attendances: 8h on Monday, Tuesday, Friday, and Saturday…
**Steps to reproduce:** - Create a flexible 32h/week calendar (8h/day, 4 days) - Assign it to an employee with the Default Ruleset - Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget) - Select the list view and go to the month of the attendances - Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat) **Cause:** `resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours. The two overtime rule paths relies on these synthetic intervals: 1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime. https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304 **update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053 2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime. https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433 **Solution:** For flexible calendars in the overtime rule consumer: - Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period - Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week) opw-6067063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263840
This update corrects a bug in the generic tax report that prevented error messages from appearing when dealing with negative net values. The fix ensures that the report accurately identifies discrepancies in tax amounts, even when balances are negative, improving report reliability. This resolves an issue impacting tax reporting accuracy.
Original PR description
**Issue:** In the generic tax report, a check is performed on the report lines to ensure that the declared tax amount is consistent with the expected amount. If the difference between the declared tax amount and the expected one is higher than 0.1% of the declared net amount, then a error message is displayed. If the net amount is negative, the error message is never displayed because the computed percentage of the tax difference is negative and therefore lower than 0.1% (i.e. 0.001). opw-6014350 Forward-Port-Of: odoo/enterprise#117990
This update resolves a display issue in the eCommerce mega menu builder. Previously, the menu would become empty and cause errors when a user had categories linked to the website but none of those categories had a product marked as 'published'. This change ensures the mega menu only appears when there are actual products to display, improving the user experience.
Original PR description
Steps to reproduce: =================== 1. Create a product, link it to an eCommerce category, keep it unpublished. 2. Create a mega menu, edit it. 3. Enable "eCommerce Categories" and try to change…
Steps to reproduce:
===================
1. Create a product, link it to an eCommerce category, keep it unpublished.
2. Create a mega menu, edit it.
3. Enable "eCommerce Categories" and try to change the number of columns.
=> Mega menu is empty and a JS error is logged in the console.
Cause:
======
The "eCommerce Categories" toggle in the mega menu builder appears whenever any `product.public.category` exists for the website. Once toggled, the eCommerce mega menu templates (`s_mega_menu_multi_menus`, etc.) are server-rendered and the resulting HTML is stored on `website.menu.mega_menu_content`.
Since [1] , those templates filter their with
`('has_published_products', '=', True)`. So when the user has categories but no published product, enabling the toggle produces an empty `<div class="row"></div>`. Clicking the column-count option on that empty row which won't have any children and it will cause an error.
Solution:
=========
Adapt the toggle on the same condition the templates use, so it is only offered when there is at least one category that will actually be rendered.
[1]: https://github.com/odoo/odoo/commit/120a7633505891ba3e02e879f0c1a8287a690456
opw-6218503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#265615
Forward-Port-Of: odoo/odoo#265190This update resolves a bug that prevented invoices from being sent correctly in demo mode when using the Nemhandel integration. The fix involved updating the system's handling of data transmission to align with a recent architectural change, ensuring invoices can now be successfully processed. This improves the reliability of the demo environment.
Original PR description
Steps to reproduce:
1. Install l10n_dk_nemhandel.
2. Register user for Nemhandel in Demo mode.
3. Create and post an invoice.
4. Click Send, check 'By Nemhandel (Demo)', and send.
-> Traceback: IndexError: tuple index out of range in _mock_send_document.
Cause:
The Nemhandel mocking system was halfway refactored to align with the Peppol
mocking architecture. As a result, the `_call_nemhandel_proxy` method now
passes the request payload as a keyword argument (`params={...}`) instead of
positional argument (`args[1]`). The mock functions were still attempting to
access `args[1]`, causing the crash.
Solution:
Update the mock functions to extract the payload directly from
`kwargs.get('params', {})`, removing the obsolete positional argument (args)
fallback to align with the new EDI architecture.
task-6065372
Forward-Port-Of: odoo/odoo#260574This update resolves an issue where invoices sent to Jofotara were being rejected due to extremely small negative discount amounts. The fix ensures that discount amounts are always non-negative by applying an absolute value function, preventing errors and ensuring proper invoice processing. This improves compatibility with the Jofotara system.
Original PR description
Before this commit: 1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3) 2. Send the order to Jofotara Jofotara rejects the…
Before this commit:
1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3)
2. Send the order to Jofotara
Jofotara rejects the invoice because the AllowanceCharge/Amount on the invoice line is a small negative value like -0.000000001 with the error `"EINV_MESSAGE":"discount cannot be negative"`
This happens because _add_document_line_gross_subtotal_and_discount_vals computes the discount as: gross_subtotal - total_excluded_currency
where gross_subtotal goes through two independent rounding steps (round unit price, then round unit_price * qty). When the quantity is indivisible, the reconstituted gross_subtotal can land just below total_excluded_currency by a floating-point epsilon, producing a tiny negative discount. The same subtraction also produces a legitimate negative value for refund lines (negative quantity), which was already handled by abs() in _add_pos_order_discount_vals for the document-level total but was left unguarded at the per-line level.
After this commit:
Apply abs() to vals[f'discount_amount{currency_suffix}'] in _add_pos_order_line_allowance_charge_nodes so that discount_amount_currency is always non-negative.
opw-6183423
Forward-Port-Of: odoo/odoo#265159This update corrects a visual glitch in the Point of Sale (POS) Restaurant module where a notification badge continued to appear after a general note was removed. The fix ensures that removing a note resets the system to its correct state, eliminating the persistent badge and improving the user experience. This resolves an issue reported in the Enterprise version.
Original PR description
Steps to reproduce:
-----------
- Open POS Restaurant
- Add a General Note
- Remove the General Note
- The message badge on “Send to Kitchen” remains visible
Issue:
-----------
Removing a General Note set `general_note` to `undefined`, which was
detected as a change and kept the badge visible.
Fix:
--------------
Normalize empty General Notes to an empty string ("") so removing a note
restores the correct initial state.
Task-6101501
Related PR: odoo/enterprise#113514
Forward-Port-Of: odoo/odoo#265652
Forward-Port-Of: odoo/odoo#258632This update resolves an issue where removing a general note from a restaurant orderline caused the preparation display to incorrectly mark the line as cancelled and create a new one. The fix ensures that note history is recorded regardless of whether the note is confirmed, allowing the system to accurately update existing orderlines instead of creating duplicates.
Original PR description
Steps to reproduce: --------- 1. Create an order with an orderline general note. 2. Send the order to the preparation display. 3. Remove the note from orderline. 4. Resend the order Issue: --------------- Removing the note changes the preparation line key, so the preparation display marks the old line as cancelled and creates a new one instead of updating the existing line. Cause: ----------- The note history was only recorded when the note was confirmed. If the user simply removes/clears the note, no note history entry is generated, so the backend cannot match the previous key with the updated key. Fix: ---------- Record note history even when the note is discarded (not only when confirmed. This allows the backend to match the old and new keys and update the line instead of cancelling it. Task-6101501 Related PR - https://github.com/odoo/odoo/pull/258632 Forward-Port-Of: odoo/enterprise#117943 Forward-Port-Of: odoo/enterprise#113514
This update resolves an issue where users on Android 14 couldn't access their device's camera when selecting files through the image input field. The fix ensures users can now take photos directly through the image input, improving usability on this platform. This change addresses a compatibility problem with recent Android versions.
Original PR description
Since Android 14 we don't have option to take a photo on clicking on file input in Chrome.
This for example will allow only images but no option "Camera"
```html
<input type="file" accept="image/*/>
```
A workaround is to use a dummy mimetype (`*/*`), example `dummy/allowAndroidCamera` The fix will be applied on image widget in addition to the original `acceptedFileExtensions` to not override the existing `accept` attribute
You can test the different behaviour here: https://jsfiddle.net/n0vs6h3b/
Linked url
https://blog.addpipe.com/html-file-input-accept-video-camera-option-is-missing-android-14-15/ https://stackoverflow.com/questions/77876374/html-input-type-file-not-working-to-pull-up-camera-for-pixel-android-14-comb/79163998#79163998 https://issues.chromium.org/issues/40937303
opw-6040375
Forward-Port-Of: odoo/odoo#265750This update fixes an issue where long text in m2m avatar fields was being cut off, creating a poor user experience. The change adds a 'truncate' class to the spans, ensuring text is neatly cut off with an ellipsis when it exceeds the available space, resulting in a cleaner and more professional appearance.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 Before: <img width="322" height="189" alt="c5f23b6aee6f63982f530c2e6a641d21" src="https://github.com/user-attachments/assets/b50fc70d-4d21-4023-8838-460f060a98fb" /> After: <img width="310" height="167" alt="5ccf4bb07603a3d8c50d3763bd112f6d" src="https://github.com/user-attachments/assets/fa7e4167-98d8-47d7-a1e2-6639da8e5d05" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256817
This update fixes an issue where long text in m2m tags' avatar fields would overflow and be cut off. By adding a 'truncate' class, text is now automatically shortened with an ellipsis when it exceeds the available space, providing a cleaner and more user-friendly display.
Original PR description
Currently, the m2m tags avatar field does not have the truncate class for the spans. When the text is too long, it overflows and the rest is cut off. This commit adds the truncate class to the spans of the m2m tags so that the text is truncated with an ellipsis when it exceeds the available space. task-4809319 https://github.com/odoo/odoo/pull/256817 Forward-Port-Of: odoo/enterprise#112590
This update resolves an issue where the ecommerce file viewer on the website displayed multiple instances simultaneously when the livechat module was active. The fix ensures that only one file viewer appears, improving the user experience and preventing visual clutter. This was a minor visual glitch addressed to maintain a clean interface.
Original PR description
Before this commit, ecommerce file viewer on website may show more than 1 file viewer at once. This happens because when livechat is installed, the overlay container of livechat mistakenly shows the overlay, therefore the overlay is displayed on main page's overlay container and on the livechat container. The regression was made with [1], where the root id is not longer picked from a target DOM but instead relies on the `env`. This change was motivated to fix a flicker, but the tradeoff is that this requires good passing of the `env` with `rootId`. This was properly set on `MainComponent`, but the overlay container of livechat is exceptionally not the `MainComponent` but instead in `LivechatRoot` that is manually mount. This app lacked the `rootId` in the `env`, which this commit solves. opw-6227540 [1]: https://github.com/odoo/odoo/pull/263860 Forward-Port-Of: odoo/odoo#265603
This update fixes a visual issue in the stock picking operations report, which previously lacked table borders, making it difficult to read. The change restores the standard table borders, significantly improving the report's clarity and usability for users.
Original PR description
Issue before this commit: ========================= The picking operations report displays the operations table without borders, making it difficult to read and distinguish between rows and columns.…
Issue before this commit: ========================= The picking operations report displays the operations table without borders, making it difficult to read and distinguish between rows and columns. Steps to Reproduce: ========================= - Install the stock module - Create a delivery order with products - Print the picking operations report Cause of the issue: ========================= In this commit (https://github.com/odoo/odoo/commit/21cd7e6), the `o_report_stockpicking_operations` class was added to a div, which removed the table borders. After This Commit: ========================= This change restores the table borders in the operations report, improving readability. Before: <img width="796" height="523" alt="2026-04-17_16-30" src="https://github.com/user-attachments/assets/084861e9-3c5b-4ca7-a237-32a56bf2267d" /> After: <img width="795" height="596" alt="2026-04-17_16-30_1" src="https://github.com/user-attachments/assets/e43ed341-8e8b-47c9-9820-66a53823b26c" /> Task: 5462122 Forward-Port-Of: odoo/odoo#253498
This update fixes a potential error that could cause the website to crash when a media item's image is deleted. The change now hides the option when an image is missing and provides an 'add image' option, ensuring a smoother user experience. This improves stability and usability of the website.
Original PR description
Before this commit, the deletion of a `s_media_list_item` image triggered a traceback because `SetMediaLayoutAction.isApplied()` attempted to calculate the option's state on a missing element. Steps to reproduce: - Enter edit mode - Drop `s_media_list` snippet - Select the first media item - Delete its image - The image is deleted, but a traceback appears This commit hides media layout options when the item has no image and introduces an add image option instead. task-6229179 Forward-Port-Of: odoo/odoo#265271
This update fixes an issue where Time Off requests weren't correctly calculating hours when created with a duration type of 'Hours'. The fix ensures that 'request_hour_from' and 'request_hour_to' display the correct hours, preventing zero values. This improves the accuracy of Time Off requests.
Original PR description
…to hours ## Issue: 'request_hour_from' and 'request_hour_to' should be computed using the default calendar attendance values, but instead they display 12:00 AM, meaning their values remain 0.0. ##…
…to hours ## Issue: 'request_hour_from' and 'request_hour_to' should be computed using the default calendar attendance values, but instead they display 12:00 AM, meaning their values remain 0.0. ## Steps to Reproduce: - Open the Time Off app. - Configure a Time Off Type with the Duration Type (request_unit) set to Hours. - Set this Time Off Type as the default one while creating a new Time Off. - Create a new Time Off request. - Observe that 'request_hour_from' and 'request_hour_to' are not computed and display 12:00 AM (0.0). ## Root Cause: While fixing the issue related to preserving leave hours when changing Time Off Types, a regression was introduced. Related PR: https://github.com/odoo/odoo/pull/227235 During the creation of a new Time Off with the duration type set to Hours by default, the field 'request_unit_hours' is already True. This prevents the computation of 'request_hour_from' and 'request_hour_to', resulting in both values remaining 0.0. ## Solution: Compute 'request_hour_from' and 'request_hour_to' when their values are still 0.0 (initial Time Off creation case), and skip recomputation only when switching between Time Off Types in order to preserve manually entered hours. Steps to reproduce : [Video](https://drive.google.com/file/d/1P2MFIj8ZxFtFxv2FlX4Zdq6P-5veTxUb/view?usp=sharing) OPW: 6209992 Forward-Port-Of: odoo/odoo#264707
This update fixes a bug that allowed users to order unlimited quantities of rental products. The system now limits the available quantity based on the product's rental availability, ensuring accurate resource allocation and preventing overbooking. This change improves the reliability and efficiency of our rental service.
Original PR description
It is possible to order as many products as we want of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. You can add as many quantity of the product to your cart Issue: We don't limit the maximum quantity of the product Solution: Look through the renting availabilities of the product and set the maximum quantity to the minimum of the availabilities relevant to the renting dates selected opw-6009928 Forward-Port-Of: odoo/enterprise#111793
This update corrects an issue where the 'Send to Kitchen' toast message in the restaurant ordering system was displaying incorrect formatting for items in languages other than English. The fix uses a language-aware method to join items, ensuring the message accurately reflects the order contents in the user's selected language. This improves the clarity and accuracy of notifications for restaurant staff.
Original PR description
Steps to reproduce: ------------------- 1. Set the user language to French. 2. Configure a preparation display. 3. In PoS, add 2 products of different categories (e.g. 2 starter and 1 main) 4. Send to kitchen -> Toast shows "2 starter et 1 €, envoyé à la cuisine" instead of "2 starter et 1 main, envoyé à la cuisine". What's happening: ----------------- The summary is built with a regex that uses `$1` to replace the ", <last_item>" with an "and <last_item>", however, this `$1` in languages other than english is being translated, in our case to `1€`, and the regex replacement logic does not work properly anymore. The fix: -------- Use `formatList` to join the items, it uses the user language to apply locale-specific joining rules. opw-6149616 Forward-Port-Of: odoo/odoo#265712
This update corrects a bug where re-invoiced expenses on sales orders incorrectly displayed the total expense amount as the unit price. The fix ensures that the quantity of the expense is properly reflected in the sales order line, resolving the pricing discrepancy. This improves the accuracy of sales order reporting.
Original PR description
Currently, when re-invoicing an expense paid by company, the line added to the sale order will show a price unit equal to the whole expense amount. Steps to reproduce: - Create a new Expense Category with Re-Invoice Costs set to 'At cost' - Create a new Expense, set the new category, and set Paid By to 'Company' - Set Quantity to greater than 1, and Customer to Re-Invoice to any Sales Order - Confirm and Submit Journal Entry on the Expense record Issue: - On the linked Sales Order you will see the total of the expense is used as the unit price This occurs because we don't pass the quantity to the move line creation vals, which then default to 1. In turn, when the sale order line is added, the unit price will be based on the move line vals but the quantity will match the expense. opw-5883290 Forward-Port-Of: odoo/odoo#246816
This update resolves an issue where a white background on the website would clash with product details, creating an unprofessional design. The fix removes the unwanted white background from product detail cards, ensuring a consistent and visually appealing experience when using website backgrounds. This improves the overall user experience and brand image.
Original PR description
When a background is set on the website, we can't remove the background of the product information card making the design unaesthetic Steps to reproduce: 1. Install eCommerce 2. Go to Website and click on Edit in the top right corner 3. Open the "Theme" tab, set an image (not plain white) to the website's background and save 4. Go to the shop and open any product 5. The product details are shown on a white block that disrupts the background image Issue: We set a background-color on `#product_details` with value `$body-bg` which is an opaque white Solution: Remove the white background of `#product_details` opw-6214514 Forward-Port-Of: odoo/odoo#265021
This update fixes a visual issue where the user rights widget sometimes overflowed its container. By adding scrolling functionality to the popover component, the widget now displays all content correctly, regardless of the amount of information. This ensures a consistently clear and usable experience for users managing access permissions.
Original PR description
This PR adds the `overflow-auto` class to the popover component to enable scrolling and prevent content overflow. **Task-ID: 6137031** Forward-Port-Of: odoo/odoo#261216
This update corrects a translation issue in the Odoo Gantt view. The button used to toggle display modes was not correctly translated, preventing users from seeing the view in their preferred language. This commit ensures all button labels are translated, improving the user experience for international users.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
Features or functions removed from Odoo
This commit removes a plugin that was no longer needed for translating the website's table of contents. The underlying functionality is now handled automatically, improving website performance and reducing complexity. This change was made to streamline the codebase and ensure ongoing efficiency.
Original PR description
The plugin `TranslateTableOfContentOptionPlugin` is not needed anymore, the replication between the headers in the content of the `s_table_of_content` and its navbar is now completely handled by the `FieldChangeReplicationPlugin` plugin since a5f1af347b55da8662d6d6802b57e14aab574d78. The test is removed because it is not representative of real edition situation (the nodes it changes are not inside `contenteditable=true` or `o_savable`), and the test added in a5f1af347b55da8662d6d6802b57e14aab574d78 covers this usecase. task-5892636 Forward-Port-Of: odoo/odoo#265779 Forward-Port-Of: odoo/odoo#264325
5 changes
Resolved issues and error corrections
This update improves the performance of Odoo's subscription module by adjusting how it tracks usage. The change ensures the system accurately reflects actual subscription usage, leading to faster query responses and a smoother user experience for subscription management. This optimization addresses a potential performance bottleneck.
Original PR description
runbot-163667
This update removes a redundant step in creating embedded actions within Odoo. Previously, manual translations were required; now that embedded actions automatically inherit translations from their linked actions, this workaround is no longer necessary. This simplifies the process and ensures consistent translations.
Original PR description
Now that `ir.embedded.actions` delegates its display name to the linked action, the manual translation copy on embedded action creation is no longer needed. Related: https://github.com/odoo/odoo/pull/262981 Forward-Port-Of: odoo/enterprise#116793 Forward-Port-Of: odoo/enterprise#116369
This update ensures that when a food delivery order is cancelled through the aggregator (Atlas), the corresponding PoS order is also correctly marked as cancelled in the system. Previously, PoS orders remained in an active state, leading to inaccurate order tracking. This fix improves order visibility and accuracy for both staff and customers.
Original PR description
pos*: pos_urban_piper, pos_enterprise When a food delivery order is cancelled from the aggregator side, the PoS order remains active on the frontend instead of reflecting the cancelled state. Steps to reproduce: - Configure UrbanPiper with Atlas - Place an order via Atlas - Open the order from the notification bar - Cancel the order from Atlas Issues: - Cancelled orders continue to appear in `Draft` - Accepted/preparation orders are not cancelled on the preparation display Fix: - Synchronise the PoS order state with the delivery state on cancellation - Update preparation display orders when delivery orders are cancelled Task-6217704 Forward-Port-Of: odoo/enterprise#117942 Forward-Port-Of: odoo/enterprise#117374
This update resolves an issue where signed PDF documents lost their original bookmarks and links. The fix ensures that signed documents remain fully navigable and preserve the original document structure and integrity, improving user experience and data consistency.
Original PR description
Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links. 2. Sign the document and download the signed PDF. 3. Open the downloaded file and check the bookmarks and links. Issue: When a signed document was downloaded, the original PDF bookmarks And the links were not working. This broke structured navigation and affected document integrity. Fix: The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing. Impact: - Signed documents remain navigable and consistent with the original PDF. - Preserves document structure and integrity. Task- 4915124 Forward-Port-Of: odoo/enterprise#117881 Forward-Port-Of: odoo/enterprise#108684
This update corrects a translation issue in the Odoo Gantt view. The button used to toggle display modes was not correctly translated, preventing users from seeing the view in their preferred language. This fix ensures all users can consistently access and understand the Gantt view's options.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
5 changes
Resolved issues and error corrections
This update corrects a bug where the tax amount on purchase bills wasn't being calculated correctly. When a user manually sets the tax on a bill, the system was resetting it to a default value. This fix ensures the manually set tax amount remains accurate on the bill.
Original PR description
Issue is really similar to commit 21877c09863222a237fe99334787ac46935dcca4 except here the compensations amls are created in _stock_account_prepare_anglo_saxon_in_lines_vals because of a difference…
Issue is really similar to commit 21877c09863222a237fe99334787ac46935dcca4 except here the compensations amls are created in _stock_account_prepare_anglo_saxon_in_lines_vals because of a difference between bill price and product cost **Steps to reproduce:** - create storable product with category standard auto - on the category, set an account in the field 'price difference account' - set a cost of 10 - set a purchase tax - confirm a PO for 1 @ 15 and validate receipt - create bill, set a date, save - on the Bill set the total tax at 100 (it's bellow 'untaxed amount' on the bottom right of the bill and should be 2.25 before you change it, if the tax is 15%) - confirm the bill **Current behavior:** tax was reset to 2.25 **Expected behavior:** It should stay 100 as it was manually set **Cause of the issue:** The total tax amount is computed based on the tax lines in Journal Items https://github.com/odoo/odoo/blob/2744396733bb3ad60813e9e093d67192c0d38b36/addons/account/models/account_move.py#L1171 So the problem is actually that a recomputation of the balance of the tax account.move.line (the one with the account "tax paid" in journal items) is triggered when we confirm the Bill. That's because: When we confirm the bill, _stock_account_prepare_anglo_saxon_in_lines_vals() creates two amls : - one debiting 5 on the account set in the field 'price difference account' - one crediting 5 in the stock interim received account (This makes sense and is there to realign with the fact that, on the account move linked to the svl, the amount credited from stock interim received is rightfully 10 because that's cost of the product and it's a standard price product) When we create those amls from, the create method from account.move.lines calls super() inside a context manager calling _sync_dynamic_lines(). https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move_line.py#L1628-L1635 the yield of sync_dynamic_lines() is inside a context manager calling _sync_tax_lines. https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3250 Therefore, the first half of sync_tax_lines() (untill the yield) is ran before the call to super and the rest (from the yield) is ran after the call to super. Because we added two lines in the account.move, get_changed_lines will return those 2 new line and because there is a tax_ids on the new lines round_from_tax will be False. https://github.com/odoo/odoo/blob/5583cbcebae00d8122dce5ce929b650929966a90/addons/account/models/account_move.py#L3034-L3041 Therefore we won't reach continue. https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3055-L3059 And the tax line will be recomputed using _prepare_tax_line() https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move.py#L3065 Here is why there is a tax_ids on the new lines : The field is precompute so if we don't set a value for it, _compute_tax_ids will be ran to compute it. As the account move on which the lines are added is a bill, the tax_ids will the supplier_tax_id of the product. https://github.com/odoo/odoo/blob/73d73c5c6606e0b34c754bfc4de035840951dd3b/addons/account/models/account_move_line.py#L898-L901 **fix** There is no need for a tax_ids on these lines as they are not meant to (and should'nt) impact the taxes. opw-6014710 Forward-Port-Of: odoo/odoo#263306
This update fixes an issue where re-invoiced expenses on sales orders incorrectly displayed the total expense amount as the unit price. The fix ensures the quantity of the expense is properly reflected on the sales order line, accurately calculating the cost. This improves the accuracy of sales order pricing.
Original PR description
Currently, when re-invoicing an expense paid by company, the line added to the sale order will show a price unit equal to the whole expense amount. Steps to reproduce: - Create a new Expense Category with Re-Invoice Costs set to 'At cost' - Create a new Expense, set the new category, and set Paid By to 'Company' - Set Quantity to greater than 1, and Customer to Re-Invoice to any Sales Order - Confirm and Submit Journal Entry on the Expense record Issue: - On the linked Sales Order you will see the total of the expense is used as the unit price This occurs because we don't pass the quantity to the move line creation vals, which then default to 1. In turn, when the sale order line is added, the unit price will be based on the move line vals but the quantity will match the expense. opw-5883290 Forward-Port-Of: odoo/odoo#246816
This update fixes an issue where backorders created during POS sales weren't properly linked to the original order. Now, all backorder pickings are correctly associated with the POS order, improving inventory tracking and reporting in the Point of Sale module. This ensures accurate order history and simplifies inventory management.
Original PR description
The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer…
The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number). Steps to reproduce: ------------------- * Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand * Open Pos * Sell in one order, both products without providing SN * Validate payment * Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders > Observation: The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order. Why the fix: ------------ Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`. opw-6090606 Forward-Port-Of: odoo/odoo#264803 Forward-Port-Of: odoo/odoo#259370
A recent update to the l10n_be_coda module incorrectly commented out a test instead of updating it. This fix ensures that the test runs properly, maintaining the functionality of the Belgian accounting integration. This resolves a minor issue that could have prevented test execution.
Original PR description
Test was commented instead of updated in this commit https://github.com/odoo/enterprise/commit/f1fafe0060c221e4a268c897af30455cc3d029ef task-none Forward-Port-Of: odoo/enterprise#117924
This update corrects a translation error in the Odoo Enterprise Gantt view. The button used to toggle display modes was not properly translated, preventing users from seeing the view in their preferred language. This fix ensures all users can access and understand the Gantt view's settings.
Original PR description
The title of the button allowing to toggle the display mode in the Gantt view was not translated. This commit adds a getter to compute the title based on the current display mode, and uses it in the template. Issue reported by translator. Forward-Port-Of: odoo/enterprise#117807 Forward-Port-Of: odoo/enterprise#117739
14 changes
New functionality added to Odoo
This update adds required fields for legal first and last names in the HR payroll module. This ensures accurate reporting and compliance with Belgian regulations, improving the accuracy of payroll calculations and employee data.
Original PR description
task-6175622
Enhancements to existing features
This update improves the calculation of sick leave compensation within Odoo Enterprise. It introduces a new rule to accurately reflect the amount covered by the CNS organization for sick leave payments, ensuring accurate payroll processing. This change aligns with current regulations regarding sick leave benefits.
Original PR description
A new logic has been introduced to calculate the amount covered by CNS organization due to sick leaves.
This update allows sales managers to set commission targets that are calculated based on the combined performance of multiple sales team members. Previously, targets were fixed and identical for all salespeople. This change improves flexibility and accuracy in commission calculations, particularly for teams with multiple contributors.
Original PR description
Before this commit, the target amounts were static and identical for all
salesperson for a given period. As previous commit allows to define the
source of achievement coming from several users for a single commission
user, we can now define dynamic targets.
In this commit, targets of the salesperson can be the sum of the targets
of the underlying user_ids on the commission plan user.
task-6030393This update optimizes the way data is sent between the user's browser and the Odoo server for account reports. Previously, a large amount of information was transmitted unnecessarily. Now, only the essential data is sent, resulting in faster report loading and reduced server load.
Original PR description
When formating the values of columns or getting the annotations for the lines, we previously send the entire lines dict. Now, we only send the elements on the line and columns that are required to reduce the size of the dict sent from the client to the server. task-5922438
This update ensures the test case for stock barcode picking is aligned with recent changes in the Odoo system. This improves the reliability of our testing process and helps maintain compatibility within the enterprise module.
Original PR description
- Applied minor adjustments and updated the test case to align with recent changes and ensure compatibility. Community PR:- odoo/odoo#259859 TaskId:-6127981
This update enhances the map's location search functionality, making it faster and more intuitive for users to find addresses. Key changes include a quicker search trigger, a clearer visual indicator, and improved pin interaction for a smoother user experience. The update also cleans up the interface by folding unused location data.
Original PR description
This commit introduces several UX improvements to the map's location features: * **Search Input:** Address search now triggers after 3 characters, displaying an italic hint below the threshold. A floating search icon (`oi-search`) appears inside the input while it is not empty. * **Pin Interaction:** The user position pin is now clickable, opening a popup that reuses the `markerPopup` template (the "Navigate to" button is omitted for user GPS coordinates). * **Visual Feedback:** Added cross-highlighting between the user location pin and the address input on hover, matching the standard pin-list ↔ marker behavior. * **Clean UI:** The unlocated records section is now folded by default to reduce initial visual clutter. It is also now properly reactive inside the mobile bottom sheet. task-6175904
Resolved issues and error corrections
This update eliminates a redundant type definition file that was causing issues with the OWL package. Removing this file resolves a technical problem, ensuring the enterprise version of Odoo functions correctly. This change improves stability and performance.
Original PR description
This commit removes the `@types/main.d.ts` file, as it seems it is not necessary and was preventing the types from the installed OWL package from being used. Before: <img width="689" height="74" alt="image" src="https://github.com/user-attachments/assets/f25ca51d-0ef7-466d-9b89-0c80047b0f97" /> After: <img width="571" height="52" alt="image" src="https://github.com/user-attachments/assets/c54455ed-279f-4449-aa77-08dd822203d2" />
This update ensures that reconciliation models created directly by users in Odoo always take precedence over those automatically generated by the system. Previously, there could be conflicts in prioritization, leading to potential issues with reconciliation processes. This change improves reliability and user control over reconciliation workflows.
Original PR description
The reconciliation models created by users now always have priority over the models that are automatically created by odoobot no matter what the sequence is. task-6086528
This update fixes an error in the WPS payroll report generation process. Specifically, it ensures the report accurately reflects payment dates and values, preventing potential discrepancies. The changes include correcting a tooltip and adding a validation check to ensure payment dates are before the value date.
Original PR description
In this commit, we: - corrected the tooltip description of `l10n_sa_wps_value_date`; - added back the Debit Date to the WPS file and assigned it the value of the `effective_date`; - added back the user error in case the Payment Date is greater than or equal to the Value Date. TaskID-6130969 Forward-Port-Of: odoo/enterprise#115762
This update resolves an error that occurred when automatically checking out employees with no defined check-out date, specifically when the hr_attendance and hr_work_entry_attendance modules are used. The issue stemmed from incorrect timezone handling, leading to the creation of duplicate overtime entries. This fix ensures accurate automatic check-out calculations.
Original PR description
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both…
__ ## Short functional explanation of the error While investigating for bug reported on ticket 6036064, I found this other bug. It only occurs when hr_attendance and hr_work_entry_attendance are both installed. When setting an attendance for an employee that has a check-in date but no check-out date, and running the scheduled action `Automatically check-out employees`, an `expected singleton` error occurs. ## Reproduction Steps 1. Install hr_work_entry_attendance. 2. Create an Employee. In the Payroll tab, set a start date for the contract. In the Settings tab, make sure their timezone is set to Brussels, and set the Overtime Ruleset field to Default Ruleset. 3. In Settings, check the Automatic Check-out box. 4. Go to Attendances. Create an attendance for the employee you just created. Set a Check-in date to 8 am on April 17th, for example, and leave the check-out field empty. 5. Open Scheduled Actions. Search the action Automatically check-out employees and click Run Manually. ### Expected behavior The attendance check-out should be set at the end of April 17th. ### Unexpected behavior An error occurs: `Expected singleton: hr.attendance.overtime.line(39, 40)` ## Origin of the issue When the attendance goes over several days, we set the check-out date to: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L618 This is a Naive date. However, it will later be considered as a UTC date. Because the employee's timezone is Brussels, this time will be transformed to 2 am next day when we retrieve attendance intervals. This will result in the creation of overtime entries for both days, causing the Expected Singleton error. https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L687 https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L667-L672 In our case, `self.check_in` = April 17th at 06:02:00 and `self.check_out` = April 17th at 23:59:59. Converted, we will obtain April 17th at 08:02:00 and April 18th at 1:59:59. Because of that, at the return: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L706 We will return a dict containing 2 intervals: one for 17th April and one for 18th April. We will then create overtime entries with such attendances: https://github.com/odoo/odoo/blob/b293ce50e0fc9355ffd233557f079916b514eac7/addons/hr_attendance/models/hr_attendance.py#L333 leading to the creation of 2 different overtimes for the same attendance. So, when we retrieve the overtime for that attendance: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L185, We get the 2. Thus when trying to access their status with: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_work_entry_attendance/models/hr_version.py#L191 An Expected Singleton Occurs. __ opw-6036064 Forward-Port-Of: odoo/enterprise#115828
A test related to embedded account reports was failing due to inconsistencies in demo data. The fix ensures the test accurately validates report options by generating the necessary account reports within the test itself, regardless of whether demo data is loaded. This resolves a runbot error and maintains test reliability.
Original PR description
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report,…
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377). In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`). When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass. In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors. To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present. runbot-error-id~242235 Forward-Port-Of: odoo/enterprise#117231 Forward-Port-Of: odoo/enterprise#112486
This update corrects a visual issue where the project sharing notebook was using dark styles, causing a conflict with the light mode theme. The team removed a specific style file to ensure consistent appearance across Odoo Enterprise.
Original PR description
The project sharing notebook previously used dark-themed styles, which conflicted with the light mode .Removing the notebook.dark.scss file from the imported files in the manifest. task-4922564 Forward-Port-Of: odoo/enterprise#99161
This update adjusts the formatting of numeric values in account reports to align with the overall column styling. The change adds a small padding to the header, creating a more consistent and visually appealing report. This improves the readability and presentation of financial data.
Original PR description
the following commit slightly modified the styling of reports header by alligning the text on the right for numeric values to match the styling of the values in the column. However, the forward port in 19.3 didn't notice that a small padding was now present in the version. https://github.com/odoo/enterprise/commit/196aa04b301499fdb2ea0769f7f07ff504a46b2b In addition, no class is needed for budget columns since no names are provided. **BEFORE** <img width="776" height="252" alt="image" src="https://github.com/user-attachments/assets/02c9dbb2-ab68-4b81-abb4-08db7f663794" /> **AFTER** <img width="518" height="276" alt="image" src="https://github.com/user-attachments/assets/3fb86584-6699-4b49-b2b9-87685bad0c16" /> Forward-Port-Of: odoo/enterprise#117920
Code cleanup and technical improvements
This update prepares our system for the upcoming OWL3 upgrade by running a preparatory script. This script ensures the system is correctly configured to seamlessly transition to the new OWL3 environment, streamlining the migration process. If any issues arise during this preparation, a notification is sent to the JESC team for immediate attention.
Original PR description
In preparation for OWL3, we run the `upgrade_code/owl3_migration` script, which prepares master for owl3 (iw. the premigration to make the actual migration which is happening in parralel easier) If this script did an incorrect change send msg to JESC. task: OWL3 prep - add this. to template variables Community PR: https://github.com/odoo/odoo/pull/264651
6 changes
Resolved issues and error corrections
This update resolves an issue where the check-out cron process was generating duplicate overtime records, leading to errors. The fix ensures accurate overtime calculations, preventing disruptions to employee time tracking and improving system stability. It addresses a technical bug related to timezone handling.
Original PR description
Steps to reproduce: **Setup** 1. Install Work Entries (which will install the other necessary modules) 2. Create a new employee with a fully fixed working schedule 3. Make sure their contract date is…
Steps to reproduce: **Setup** 1. Install Work Entries (which will install the other necessary modules) 2. Create a new employee with a fully fixed working schedule 3. Make sure their contract date is set (preferably in the past) 4. Ensure that the employee and working schedule are in a timezone that has a positive UTC offset 5. Ensure that "Automatic Check-Out" is enabled in Attendances **Reproduction** 1. Create an attendance for your employee that falls right before a non-working day a. Make sure you do this so it spills over into the next day and will be picked up by the cron. I did this by going to the previous Friday and having the attendance start that morning. b. The date has to be after the employee's contract has begun 3. Remove the check-out time so the attendance is still running 4. Go into "Scheduled Actions" and manually run the cron 5. Observe the traceback In the "Automatic Check-Out" scheduled action for Attendances, we attempt to calculate the correct check-out time for attendances that are over the set hour tolerance. To do this, we temporarily set the check-out time of the attendance to 11:59PM of the date of check-in. When we set this, in timezones with a positive UTC offset, the time will spill over into the next day. This causes two overtime records to be temporarily generated when normally, only one is generated. Ths causes issues when a function in teh Work Entries module is ran, as it checks the status of the overtime lines. Since there are two, we get a singleton error here, as it only expects one overtime line. This fix corrects this by ensuring that the write method is not called on the attendance record, utilizing a temporary variable instead, and preventing the multiple overtimes from ever being generated. [opw-6198323](https://www.odoo.com/odoo/project/49/tasks/6198323?debug=assets)
This update corrects a restriction in the MPF account validation process, allowing employers to manage multiple accounts under the same registration number – a common business practice. Previously, the system incorrectly blocked valid multi-account configurations. This change ensures accurate tracking of employer MPF accounts and simplifies payroll processing.
Original PR description
An employer can legitimately hold multiple employer account numbers under the same MPF registration number. The previous constraint rejected any two MPF schemes sharing the same registration number, blocking valid multi-account configurations. Fix the validation to only restrict the duplicate based on the combination of registration number and employer account number. task-6232561
This update corrects a previous issue where Avatax fiscal positions weren't being created correctly for specific countries, particularly the US. With the US now having its own CoA, the system now automatically generates the appropriate Avatax fiscal positions based on localization, and also includes Canada for broader coverage. This ensures accurate financial reporting.
Original PR description
The fiscal position was being created specifically for countries using the Generic CoA. This stems from before the US had its own CoA [1]. Because of this, US companies no longer had an Avatax fiscal position created for them. Now that the US has its own CoA, we move to a simpler `@template()` approach and take the opportunity to add Canada as well. [1] odoo/odoo#223745 task-6228639
This update resolves an issue preventing users from unreconciling SEPA CT batch payments with a 'pending' online status. Previously, the system incorrectly blocked this process, causing errors. The fix allows for proper bank statement reconciliation, ensuring accurate financial reporting.
Original PR description
**Issue:** The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'. This…
**Issue:** The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'. This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification. **Steps to reproduce:** - Setup a 'sepa_ct' payment method on a bank journal. - Create a bill with a vendor with a trusted bank account. - Create a payment for that bill with a 'sepa_ct' payment method. - Add the payment to a batch. - Manually set the `payment_online_status` = 'pending'. - Create a bank transaction and reconcile it with the batch. - Try to unreconcile the lines on the transaction - Result: UserError 'You cannot modify a payment that has already been sent to the bank.' **Fix:** Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow. OPW-6080464
This update resolves a bug that caused errors during rental order confirmation in versions 17 and 18, and a subsequent division-by-zero error in newer versions. The fix skips unnecessary calculations when a Bill of Materials (BoM) isn't found, ensuring the order can be confirmed smoothly. This improves the reliability of the rental order process.
Original PR description
**Steps to produce:** - Install `sale_mrp_renting`. - Enable `Rental Transfers` from settings. - Create a rental product. - Create two variants of the product. - Create a BoM for one variant and set…
**Steps to produce:** - Install `sale_mrp_renting`. - Enable `Rental Transfers` from settings. - Create a rental product. - Create two variants of the product. - Create a BoM for one variant and set its type to `Kit`. - Create a rental order using the other variant. - Try to confirm the order. **Issue:** In versions 17 and 18, a UserError is raised- ``` The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category. ``` From version 18.2 onward, a different error occurs ``` ZeroDivisionError: float division by zero ``` **Root cause:** In versions 17 and 18: At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from `_compute_quantity` method. In version 18.2+: At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error. **Solution:** Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`. [1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13 [2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20 [3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21 [4] https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676 **opw-6082434**
Miscellaneous changes
13 changes
Resolved issues and error corrections
This update resolves an issue where extra space appeared on the right side of signed documents when scrolling horizontally. The change removes this empty area, ensuring signed documents display cleanly within the view and providing a better user experience.
Original PR description
When scrolling horizontally on a signed document, an empty area appeared on the right side of the view. This commit hides that extra space so the document fits cleanly within the view. task-6235457
This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module, particularly on databases with extensive sales order data. By ensuring newly created fields default to 'null' during installation, the module now avoids unnecessary calculations and improves installation stability.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267
This update fixes an issue where CFDI (Mexican electronic invoice) documents were being generated with incorrect length limits for key data fields. The swap of values has been corrected, ensuring that generated invoices comply with Mexican regulations and avoid potential rejection by tax authorities. This change does not impact existing valid invoices.
Original PR description
Issue: length limits for attributes `Folio` and `Serie` of the `<cfdi:Comprobante>` elements were swapped, which could result in generation of invalid documents. Solution: swapping the values. This should not affect anything for existing valid documents. task-6046738 Forward-Port-Of: odoo/enterprise#116955
This update fixes a bug that prevented users from adding combo items when creating quotes on mobile devices. The issue stemmed from a mismatch in the widgets used to configure combo products. The fix adds a specialized widget to ensure combo items can be correctly added and saved via the mobile interface.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Switch to mobile view; 2. create a new quotation; 3. click "Add Product"; 4. add combo product; 5. click Save & Close. Issue ----- None of the combo items were added. Cause ----- The combo configurator is called via the `sol_product_many2one` widget. The `o_kanban_mobile` view however uses the `many2one_barcode` widget instead. Solution -------- Add a `sol_product_many2one_barcode` widget which has all the functionality of the `sol_product_many2one` widget, but also sets the `canScanBarcode` prop to `true`. opw-5161797
This update fixes an issue where the 'CopyButton' on mobile devices would overflow its container, causing labels to be cut off. The change ensures the button adjusts to available space, providing a cleaner and more consistent user experience on smaller screens. This improves usability for mobile users.
Original PR description
Description of the issue/feature this PR addresses: On mobile view, the CopyButton can be rendered with a long label, for example in the payment link wizard. Before this PR: The button keeps its intrinsic width and may overflow its container, appearing cut off. After this PR: The CopyButton takes the available width and no longer overflows on mobile. Before: <img width="504" height="520" alt="image" src="https://github.com/user-attachments/assets/0e677ce0-b39e-4e28-88d0-89f4a278daa0" /> After: <img width="504" height="520" alt="image" src="https://github.com/user-attachments/assets/dac9f702-5e54-42c8-aad2-f91d9534033d" /> @Tecnativa TT58871 @CarlosRoca13 @pedrobaeza please take a look! --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where users couldn't reliably select formatted text within a single table cell. The change simplifies the selection process by directly checking cell boundaries, ensuring consistent and accurate cell selection within the HTML editor. This improves the user experience when working with tables.
Original PR description
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through…
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through mouse. - observe that it is not selected ### Description of the issue/feature this PR addresses: - The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected. ### Desired behavior after PR is merged: - Cell selection was simplified using areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected. task-6207941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the way Odoo stores HTML editor history mutations was incorrect. Specifically, it ensures that node additions and removals are represented accurately, preventing potential errors when applying or reverting changes. This improves the reliability of the HTML editor's history functionality.
Original PR description
This is a backport of [commit](bf86b89f7cdab0ae378a1d897bfef625ccb4cb38). #### Description of the issue: A "childList" mutation record with multiple added or removed nodes is transformed and stored…
This is a backport of [commit](bf86b89f7cdab0ae378a1d897bfef625ccb4cb38).
#### Description of the issue:
A "childList" mutation record with multiple added or removed nodes is transformed and stored as a sequence of individual "add" or "remove" mutations.
Before this commit, each of the resulting "remove" mutations would contain the same previousSibling/nextSibling pair of the original record. The same happened for "add" mutations (in the form of the equivalent operation, e.g. "append", "after", etc).
This was incorrect, as the previousSibling/nextSibling pair of the original record would not be the same for each added/removed node. Inserting nodes A and B between nodes P and N (previous and next siblings) is NOT equivalent to
[
insert A between P and N,
insert B between P and N // wrong,
]
The second resulting mutation does not make sense, as there's already a node A between P and N at this point, so it is ambiguous whether the insertion should should be done between P and A, or between A and N. So the correct equivalence, when converting a batch insertion of nodes A and B between P and N into a sequence of individual insertions, would be:
[
insert A between P and N,
insert B between A and N // correct
]
Similarly, when removing nodes A and B, having N an P as their outer siblings, the correct sequence of mutations would be: [
remove A between P and B, // A's nextSibling is B at this point
remove B between P and N
]
This incorrect information about siblings in stored mutations would lead, in some cases, to incorrect results when later applying or reverting mutations, as demonstrated by the test added by this commit.
Moreover, a mutation record having both added and removed nodes, when transformed into a sequence of individual mutations, should first contain the "remove" mutations, and then the "add" mutations, as the latter assumes that the original previous and next siblings, as references for inserting point, are siblings between each other, which is only true after the "remove" mutations took place.
task-4678910, 6205143
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a bug in the HTML Editor where resizing the table would cause a crash when a table was removed. The fix restricts resizing to the primary mouse button and prevents errors when resizing with a non-existent table target, ensuring a more stable and reliable user experience.
Original PR description
#### Description of the issue this PR addresses: - Table resize listeners are not cleaned when the table is removed while resizing - Next mousemove runs resize logic with a null target and throws traceback #### Desired behavior after PR is merged: - Restrict resize start to primary mouse button only - Prevent resize logic execution on null targets #### Steps to reproduce: - Open the todo app - Insert a table and select whole table - Move cursor on a table cell border to see resize cursor - Right click and choose Cut from browser context menu - Move the mouse again - Resize logic crashes with null target traceback task-6212279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that work entry data exported to the Acerta payroll system adheres to the correct formatting requirements. Specifically, the external reference number is padded to 17 digits with 3 spaces, and the work entry type code is padded to 4 digits with 2 spaces, aligning with Acerta's specifications. This ensures accurate data transmission and processing.
Original PR description
We want to adhere to the correct format for the export of work entries to Acerta. There, the number of external reference is padded to 17, not 20, and is followed by 3 spaces, before the date. Also, the code of the work entry type is padded to 4 and followed by 2 spaces. Task: 6168106
This update resolves an issue where attachments added when sending emails through the 'Send by Email' action were disappearing after refreshing the chatter window. The fix restricts attachment saving to the full composer view, ensuring consistent behavior for action composers. This prevents data loss and improves the email sending process.
Original PR description
**Steps to reproduce:** - Install Sales app - Create a Sales Order - Click on the 'Send by Email' action - Add an attachment and send it - Open the chatter to create a log note - Attachment is attached to the new message - It disappears on refresh **Issue:** Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`. Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers. But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`. **Fix:** Restrict the attachment save to the full composer using context. [1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027 [2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3 opw-5164504
This update fixes a technical issue where the ‘Configuration’ menu item within the Contracts module was being incorrectly positioned due to a low sequence value. This conflict caused disruptions in Odoo’s menu hierarchy when other modules added menu items to the same section. Adjusting the sequence ensures the Contracts menu remains in its intended last position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when sending invoices to MyInvois when the invoice number used a year-range sequence. The fix corrects a mismatch in data returned by a key method, ensuring invoices with these numbers can now be successfully transmitted.
Original PR description
Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence. **Steps to Reproduce:(v-19.0)** 1. Install the `accountant` and `l10n_my_edi`…
Currently, an error is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence. **Steps to Reproduce:(v-19.0)** 1. Install the `accountant` and `l10n_my_edi` modules (with demo data). 2. Switch to "MY Company"(Malaysian company). 3. Enable "_Quick Encoding_" for Customer Invoices in Settings. 4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice. 5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again. 6. Open the invoice list view and click **"Send to MyInvois"**. **Error:** `ValueError: not enough values to unpack (expected 4, got 2)` The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1]. [1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146 Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263 sentry-7320998540
This update ensures that sales services from European companies to Northern Ireland are correctly excluded from the EC Sales List report. This change aligns with regulations and accurately reflects sales transactions, particularly when goods and triangular transactions are involved. The update was specifically tested and implemented for the Belgium localization.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#110007
1 change
Resolved issues and error corrections
This update resolves an issue where setting Intrastat information on product templates without associated products would trigger an error. The fix ensures that the system correctly handles product templates without variants, preventing unexpected RPC errors and improving data integrity. This ensures Intrastat reporting functions smoothly for all product types.
Original PR description
Problem: The Intrastat fields on product.template are computed without being stored. They are stored in product.product and the same values are used when computing the values on product.template. When trying to set the Intrastat fields on a product template without any product, an RPC error is raised without specifying the reason. Steps to reproduce: 1. Create a new product (product.template) 2. Add an attribute to the product with Variant Creation set to Dynamic, this will set no product variants (product.product) for the product template. 3. Try to set the Intrastat Commodity Code on the product template 4. Save the product template 5. Notice the RPC error raised without any explanation opw-6179705