Daily updates from Odoo
Thursday, April 9, 2026
46 changes · saas-19.1
Resolved issues and error corrections
This update fixes a display issue where rental products would show an 'out of stock' ribbon even when their quantity was zero. The change ensures that rental products don't incorrectly show this ribbon, aligning with their time-based stock availability. This improves the customer experience for rental orders.
Original PR description
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock…
Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product. Steps to produce: --- - Install the `eCommerce Rental with Stock Management` module. - Create a rental product and set Quantity On Hand to 1. - Under the Sales tab, disable `Sell when Out of Stock`. - Under the Rental Prices tab, add pricing. - Go to `website > ecommerce > products > product ribbons`. - Open `out of stock` ribbon > set assign as `when out of stock`. - Create and Confirm a rental order for that product and validate the pickup. - The product's Quantity On Hand drops to 0. - Opening the product on the website Observation: --- - The product shows the out-of-stock ribbon. Cause: --- - At [1], the or condition evaluates to True because the ribbon is configured as `when out of stock`, `Sell when Out of Stock` is disabled under the Sales tab, and `_is_sold_out` also returns True since the quantity dropped to 0 after the pickup was validated. As all conditions are met, the ribbon is returned and displayed without ever checking whether the product is a rental. Skip the out-of-stock ribbon assignment for rental products, since their stock availability is time-based. [1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28 opw-6081483 --- Forward-Port-Of: odoo/enterprise#112660
This update fixes an issue preventing users from manually digitizing vendor invoices when the Bill Date is initially missing. A previous change required a Bill Date to trigger digitization, which was inconvenient. Now, users can manually initiate digitization without a Bill Date, while still ensuring data consistency through a validation step afterward.
Original PR description
### Issue: When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set A missing required fields error is raised ###…
### Issue: When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set A missing required fields error is raised ### Cause: This PR: https://github.com/odoo/odoo/pull/238911 introduced a required field to prevent an error modal from appearing While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically ### Fix: A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date The validation modal is still enforced afterward to ensure data consistency in case of manual edits ### Steps to reproduce: - Install `account` - In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only` - Create and print an invoice (any data) or use an existing one - Import it into Vendor Bills - Click Digitize Document ### Before the fix: A missing required fields notification is raised, preventing digitization opw-5886012 Forward-Port-Of: odoo/enterprise#112585
This update corrects a stability issue within the Odoo Enterprise's expense tracking system. By switching to a 'TransientModel' for the wizard, the system is now more reliable and efficient. This change ensures smoother operation for users managing expense reports.
Original PR description
`HrExpenseStripeTestPurchaseWizard` is currently using a normal `Model`, but it's a wizard, so use a `TransientModel`. Forward-Port-Of: odoo/enterprise#113313
This update resolves an issue where negative values in the Mod 390 tax report were not being properly marked with the 'N' indicator, as required by Spanish tax regulations. The fix ensures accurate reporting by adding a necessary parameter to the BOE export, aligning with official documentation for data submission.
Original PR description
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative…
### Issue: Negative values in the Mod 390 report were not properly marked with the N indicator for several fields ### Cause: The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export ### Note: According to the official specification, negative amounts must be explicitly marked with N Latest documentation: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` with demo data and switch to the ES company - Create a Bill (Price: 100, Taxes: 21% G) - Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year - Open the VAT Deductible tab - The last line (65) should be negative - Export the BOE file using the gear menu - Check the last value of section 4 in the file ### Before the fix: Negative values were not marked with N opw-5482706 Forward-Port-Of: odoo/enterprise#113200 Forward-Port-Of: odoo/enterprise#111262
This update fixes a problem where users weren't receiving clear error messages when the delivery service failed. A helpful hint has been added to the system, guiding users to resolve the issue and ensuring smoother delivery processes. This change improves user experience and reduces potential delays.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855 Forward-Port-Of: odoo/enterprise#112463
This update fixes an error in the Italian tax returns that was incorrectly including taxes beyond withholding taxes (like INPS). The fix ensures the total amount calculated on the tax return accurately reflects only the withholding tax, improving the reliability of Italian tax reporting. This prevents inaccurate financial reporting.
Original PR description
### Issue before this commit: Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes…
### Issue before this commit: Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect. ### Steps to reproduce the issue: 1. Download Accounting and l10n_it and switch to italian company 2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF) 3. Mark them as paid and reconcile them 4. Open a tax return and validate it 5. See that the total amount calculated includes also other taxes than only witholding taxes ### Cause of the issue: The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation. ### Reason to introduce the fix: To restore the correctness of the tax return totals. opw-5905355 Forward-Port-Of: odoo/enterprise#112638
This update corrects a problem where special characters (specifically '&') in payment references were incorrectly formatted during SEPA XML export. This prevented payments from being processed by banks, ensuring compliance with SEPA regulations and accurate financial reporting. The fix replaces '&' with '+' to meet SEPA/SIX requirements.
Original PR description
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net &…
Steps to reproduce: 1. Install modules `account_batch_payment` and `l10n_ch`. 2. Configure SEPA Credit Transfer for a CH company. 3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer. 4. Create a batch payment with the SEPA payment and validate it. Issue: The `&` character is exported as `&` in the generated PAIN XML, while according to the SIX specification it should be replaced with `+` Cause: The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed. Solution: Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML. Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf opw-5941724 Co-authored by @bhra-odoo Forward-Port-Of: odoo/enterprise#110809
This update resolves a critical issue where users could cancel documents after all signatures were collected, potentially compromising legal records. Now, the cancel button disappears automatically once signing is complete, and backend cancellations are blocked to ensure document permanence and security. This protects the integrity of agreements and provides a more reliable record.
Original PR description
Before this commit, users could cancel documents after everyone had signed. This weakened legal records and proof of agreement. After this commit, the cancel button disappears once signing is complete. We also blocked backend cancellations to keep finished documents permanent and secure. task-5980337 Forward-Port-Of: odoo/enterprise#112617 Forward-Port-Of: odoo/enterprise#109353
This update corrects a bug that prevented users from editing the Amazon fulfillment channel within the Odoo Enterprise system. The issue was due to a read-only display widget, which has now been replaced with an editable option. This ensures users can accurately manage their Amazon selling operations.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#113196 Forward-Port-Of: odoo/enterprise#112866
This update corrects a discrepancy in the calculation of employment bonuses for Odoo Enterprise users in Belgium. The change reflects the latest regulations from Partena Professional, ensuring accurate bonus payments up to April 2026. This update maintains compliance with Belgian tax laws and avoids potential financial discrepancies.
Original PR description
https://www.partena-professional.be/fr/le-bonus-lemploi-au-1er-avril-2026?utm_source=sfmc&utm_medium=email&utm_campaign=InfoFlash+Daily+Mail+-+FR&utm_content=article-read-more-cta&utm_term=All%20Subscribers&utm_id=81873&sfmcContactKey=litom@odoo.com Forward-Port-Of: odoo/enterprise#112970
This update fixes a technical issue where sending snailmail letters with more than 8 pages would result in a generic error. The change provides a more specific error message to users, making it easier to diagnose and resolve sending failures. This improves the user experience and reduces support requests related to this limitation.
Original PR description
When a user attempted to send a letter with snailmail that had more than 8 pages, sending would fail, and a generic error message is logged on the letter. This commit makes the error message generated in that flow more specific to help users better understand the root cause of sending failure. task-5883011 Forward-Port-Of: odoo/odoo#257867
This update fixes an issue where navigating with arrow keys around code blocks within the HTML editor was unreliable, leading to caret positions being incorrect. The changes ensure that arrow navigation now correctly moves between code blocks and paragraphs, providing a smoother and more intuitive editing experience. This improves the overall usability of the HTML editor for users.
Original PR description
### Description of the issue/feature this PR addresses: - When navigating with ArrowUp/ArrowDown around a code block, the caret could end up in an unexpected position. - Arrow navigation from start or end of a paragraph did not correctly enter the adjacent code block. - Arrow navigation from the start or end of a code block did not correctly move the caret to the previous or next sibling block. ### Desired behavior after PR is merged: - Paragraph start + ArrowUp moves to the end of the previous code block. - Paragraph end + ArrowDown moves to the start of the next code block. - Code block start + ArrowUp moves to the end of the previous paragraph. - Code block end + ArrowDown moves to the start of the next paragraph. task-5384549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241798
This update resolves a problem where the website's footer copyright information would break when editing the footer layout, particularly with the mega footer option. The fix ensures the copyright displays correctly by adjusting how Odoo handles template updates and prioritizing the footer template execution.
Original PR description
Steps to reproduce: =================== 1. Go to website and switch footer to mega footer 2. Add a language & edit copyright text 3. Save & change the language => breaks Cause: ====== Editing…
Steps to reproduce: =================== 1. Go to website and switch footer to mega footer 2. Add a language & edit copyright text 3. Save & change the language => breaks Cause: ====== Editing triggers Odoo's Copy-On-Write (COW) mechanism, creating a customized template with a higher database ID. This causes it to execute after the mega footer templates, which expect col-sm classes that were already changed to col-md. The xpaths fail and the footer breaks. The existing patch in html_editor/models/ir_ui_view.py (from [1]) that re-adds col-md when saving one of the affected views was not working in this case because the write was done with delayed_translations=True in context, causing the ancestor patch to be skipped. Solution: ========= - Add `delayed_translations=False` to the ancestor write in `ir_ui_view.py` so the patch is applied immediately when editing the footer. This prevents the issue without requiring a module update. - Add priority="15" to `footer_copyright_company_name` so that even for already-broken databases (where COW was created before this fix), the template runs before mega footer templates after a module update. The priority is inherited by COW-generated views. [1]: https://github.com/odoo/odoo/commit/2d6699b4c460084110ccada0392845156af4a135 opw-5485986 Forward-Port-Of: odoo/odoo#248833
This update resolves a technical issue that prevented the requirements-check script from correctly parsing version numbers containing letters and suffixes (like 'post1'). This ensures accurate dependency checks and prevents potential errors when specifying software requirements, improving stability.
Original PR description
This commit fixes a crash in the parse_version() function where it doesn't support non-integer castable version parts (i.e. 5.4.2.post1). Forward-Port-Of: odoo/odoo#257946
This update corrects a bug in the reconciliation process where errors occurred when creating reconciliation models without specifying a partner or account. Now, the system requires either a partner or an account to be set, preventing the use of default liquidity accounts and ensuring accurate reconciliation reporting. This resolves a previous issue impacting financial data accuracy.
Original PR description
**Steps to reproduce:** - Go to Accounting dashboard - From Bank journal, open Reconciliation Models list - Create a new reconciliation model - Add counterpart line without partner and account - Click on "Automate" **Issue:** The operation fails because the default account of the bank journal is used as there is no user and no account configured for the counterpart. Which results on several lines using a liquidity account (i.e. the cause of the error). Either a partner or an account should be set on a counterpart line. opw-6056737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257923
This update fixes an issue where the currency rate selected in invoices was incorrectly defaulting to the previous day instead of the selected date. This ensures accurate currency conversions for invoices, improving financial reporting and reducing potential errors. The change was triggered by a previous code update.
Original PR description
Issue: When selecting a rate with the date picker, it applies the rate of the previous day Steps to reproduce: - Add a currency - On this currency, add a currency rate to today's date - Create en invoice in the added currency - On the currency rate picker take today's rate Current behavior: - take the first currency rate before selected date Expected behavior: - take the currency rate of the selected date Cause: Since 59f6a4848a160f99eb9f5c43755bb18f2f8b8a4b, account move take the currency rate of the date before the Bill/Invoice date. As the date picker uses the same methods, it returns the currency rate of the date before the selected date. opw-6046169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where kiosk payments with connected payment terminals were failing, despite successful transactions on the terminal. The fix allows payment data in kiosk mode with valid amounts and adds validation to prevent spoofing. This ensures seamless payment processing for self-order kiosks.
Original PR description
Since odoo/odoo#249455 the order payload from the self order frontend is being checked to ensure the data is valid. However, these checks did not account for the situation where payment data is…
Since odoo/odoo#249455 the order payload from the self order frontend is being checked to ensure the data is valid. However, these checks did not account for the situation where payment data is included, as is the case when using a self order kiosk with a payment terminal connected. The result was that using the kiosk with a payment terminal would result in an error even though the payment was successful on the terminal. Steps to reproduce: - Configure a self order kiosk POS - Connect a payment terminal (Adyen, Stripe, Viva etc.) - Try to pay for an order from the kiosk EXPECTED: - The order is made successfully. ACTUAL: - A generic error message is shown and the order fails. The payment goes through successfully on the payment terminal. The fix is to allow a payment to be included in the self order data, but only in Kiosk mode and only if the payment amount is valid. We also now validate that the self ordering type is correct, this ensures that a kiosk payment cannot be spoofed for a mobile self order POS. Finally, there is also a small change for Viva.com to use the PoS config name instead of UUID, since UUID is no longer loaded in self order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoicing a Point of Sale order multiple times would create unnecessary stock pickings. This change ensures that only one picking is generated when an order is invoiced, regardless of how many times the 'Invoice' button is clicked. This improves efficiency and avoids potential stock discrepancies, particularly in configurations that automatically update stock levels at closing.
Original PR description
Calling `action_pos_order_invoice` on an already-invoiced POS order (e.g. a backend user clicking "Invoice" more than once) would unconditionally invoke `_create_order_picking`, producing one extra `stock.picking` per click under anglo-saxon + update_stock_at_closing configurations. opw-6092999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257509
This update resolves an issue where COGS wasn't being calculated correctly for orders with multi-step delivery processes. The fix ensures that COGS is accurately reflected in invoices when products are delivered in stages, addressing a previous workaround. This improves the accuracy of cost accounting for these types of orders.
Original PR description
**Problem:** cogs is 0 if the delivery is multi steps with only first picking validated. **Steps to reproduce:** - set the warehouse as 2 steps delivery - create a tracked product avco perpetual -…
**Problem:** cogs is 0 if the delivery is multi steps with only first picking validated. **Steps to reproduce:** - set the warehouse as 2 steps delivery - create a tracked product avco perpetual - set a cost of 10$ and a positive quantity - create and confirm a SO for 1 quantity - validate only the first picking - create and confirm the invoice **Current behavior:** there is no cogs lines in the invoice **Expected behavior:** there should be cogs line for a cost of 10$ **Cause of the issue:** to compute the unit price of the cogs we use _get_cogs_value() https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L122 Inside _get_cogs_value(), because there is done moves, we use _get_cogs_price_unit() https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move_line.py#L67-L68 But because there is no valued quantity (because the done moves are internal), the return value will be 0. https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253 So the cogs will have an amount of 0 and no line will be created https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L125-L126 **fix** The fix for consigned products introduced by this PR https://github.com/odoo/odoo/pull/255043 was working for the wrong reasons. _get_valued_consigned_qty() only works if the moves are partially consigned. If the move is fully consigned, _is_consigned_value_line() will return False for every move line. https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L650-L651 That's because if the move is fully consigned, _is_in() and _is_out() will return False. https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move_line.py#L72-L74 So it only works if the move is not fully consigned because _is_in() or _is_out() will be True thanks to the non consigned line. https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L511-L519 However, _get_cogs_price_unit() still worked fine for fully consigned moves because if the move is fully consigned, total_qty will be 0 and the return value will be 0 https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253 But this was hacky and prevented us to address the issue of this PR. The logic should be: If there is no quantity to value (consigned + not consigned) we fallback on the standard price (just as if there is no move). This solves the issue of this PR because no moves were valued moves in our use case. If there is a quantity to value (and we're in a case where we want the average move value), we use the average move value (which will be 0 if all the moves are consigned) opw-6001694 Forward-Port-Of: odoo/odoo#256383
This update resolves an issue causing inconsistent styling in the point-of-sale category selector. By ensuring the `category-list` class is always applied, the selector now renders consistently across different devices and environments. This improves the overall user experience for sales staff.
Original PR description
Before this commit: ==================== Previously, the `category-list` class was conditionally applied based on `show_category_images`, which caused inconsistent styling and layout issues. After this commit: ======================= This commit ensures that both `product-list` and `category-list` classes are always present, providing consistent rendering of the category selector. Task-6092404 Forward-Port-Of: odoo/odoo#257988 Forward-Port-Of: odoo/odoo#257251
This update fixes an issue where invoices for downpayments weren't using the intended expense account (ACC1). The change ensures that downpayment invoice lines now automatically use the correct account, streamlining the accounting process for downpayment transactions. This improves accuracy and reduces the risk of manual errors.
Original PR description
Steps to reproduce: 1/ install purchase and accountant 2/ create and setup an expense account dedicated to your downpayments (typically code 60-, account type "expense"), ACC1. 3/ setup a service type product named "downpayment" 4/ set the default expense account on that product to be ACC1. 5/ create a PO for any product other than the downpayment (PO1). take note of the partner. 6/ create a bill for the same partner as the one set on PO1. Call it BILL1. 7/ On BILL1, add one invoice line with the "downpayment" product. Set a unit price. 8/ Confirm BILL1 and match it with PO1 via the "bill matching" smart button. Add it as a downpayment. 9/ Back on PO1, receive the products. Create a bill (BILL2). => The account suggested for the downpayment line in BILL2 will use the default expense account instead of ACC1. After this commit, the account suggested will be the one used in BILL1 for the downpayment line. opw-5253877 Forward-Port-Of: odoo/odoo#245518
This update fixes an issue where PEPPOL self-billing invoices weren't correctly including the delivery address and GLN number. The change ensures that the delivery address from the company partner is used in the generated XML, improving data accuracy for PEPPOL transactions. This resolves a previous problem preventing proper delivery information from being transmitted.
Original PR description
**PROBLEM** When selfbilling with peppol, we have no way of providing a GLN number, or modifying the delivery address. Even if we create a delivery address partner on the current company partner, it's not taken into account. **STEP TO REPRODUCE** 1. Create a delivery address on the current company, set up a GLN number. 2. Configure the purchase journal to do selfbilling. 3. Create a vendor bill with this journal and send it using peppol. 4. Download the xml, and look for the Delivery tag, and notice it doesn't have the GLN number. **FIX** We search for a delivery address on the current company. If there is one, we use it for the Delivery tag. opw-6014374 Forward-Port-Of: odoo/odoo#257414 Forward-Port-Of: odoo/odoo#252970
This update ensures seamless integration with Poland's KSeF system by automatically renewing the necessary API tokens every 6 days. Previously, expired tokens caused disruptions in bill and invoice synchronization. Now, users will experience uninterrupted service without manual intervention.
Original PR description
The KSeF refresh token issued by the Polish Ministry of Finance expires after a week. Once it expires, the automatic fetching of incoming bills and sending of invoices will fail until the user manually re-authenticates in the settings. To ensure uninterrupted synchronization with the KSeF API, this commit adds a new scheduled action that runs every 6 days to automatically renew the tokens. task-6041758 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256700
This update ensures that tax report lines in the Dutch (nl) version of Odoo consistently display negative signs, aligning with existing supply reporting practices. Previously, the sign was missing, causing inconsistencies and potential confusion for users configuring taxes. This change maintains a standard reporting format.
Original PR description
It is be better to change the sign, because it is under supplies and the other report lines in that section also have a negative sign. In other words, anyone who would have configured the tax, would have used the negative tag to configure it right before. Now that the sign on the tags is gone, we need to put it correctly on the report line. opw-5874677 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255039
This update corrects a minor typo within the Odoo test code. The issue was partially addressed previously but lost during a conflict resolution. This change is being reintroduced in the 19.1 SaaS version and is not relevant for older versions.
Original PR description
This was partially fixed in another [pr](https://github.com/odoo/odoo/pull/228977) but the fix was lost while solving conflicts. Reintroducing the fix starting from 19.0 since we don't really care about this specific test in eol saas-18.x versions Forward-Port-Of: odoo/odoo#258278
This update fixes an issue where subtasks created from project templates didn't correctly inherit the sale line ID from their parent task. Previously, logging hours on subtasks resulted in an empty timesheet line. The fix ensures that all tasks, including subtasks, accurately reflect the associated sales order, improving data consistency and reporting.
Original PR description
When creating tasks from a project template via a Sales Order, the main task is created with its sale_line_id set correctly, but subtasks from the template do not inherit the sale_line_id from their…
When creating tasks from a project template via a Sales Order, the main task is created with its sale_line_id set correctly, but subtasks from the template do not inherit the sale_line_id from their parent. Steps to reproduce: 1. Create a project template with a parent task and subtasks 2. Create a service product that uses this project template 3. Create and confirm a Sales Order with this product 4. Check the created tasks: main task has sale_line_id, subtasks don't 5. Log hours on a subtask: the timesheet's so_line remains empty Root cause: When copying a project template, the copy_data() method for subtasks was resetting the default dict to only contain 'parent_id': False. This meant that whitelisted fields like sale_line_id from the parent task were not propagated to the subtasks during the copy operation. Solution: When copying from a template (copy_from_template context), preserve whitelisted fields (including sale_line_id) in the default dict before copying subtasks. This allows subtasks to naturally inherit sale_line_id from their parent during creation, so the compute method works correctly. opw-5185519 Forward-Port-Of: odoo/odoo#236342
This update prevents unnecessary camera permission requests when hiding the call invitation's camera preview. Previously, users were repeatedly prompted for permissions, even when the camera was not visible. This change improves the user experience and resolves a related issue impacting a local test tour.
Original PR description
Before this commit, hiding the camera preview in the call invitation would prompt the user for device permissions again. This is unnecessary since we are hiding the camera preview. This commit fixes the issue by aksing for device permissions only when showing the camera preview. This commit also indirectly fixes the `discuss_call_invitation_tour` failing locally. task-6095245
This update resolves a restriction in the l10n_pl_edi module, allowing non-administrator users to perform key KSeF-related tasks. The changes grant necessary access to company settings and certificates, ensuring broader functionality for users handling Polish e-invoicing. This improves usability and compliance.
Original PR description
Fields on `res_company` related to KSeF are marked only for group `base.group_system`, as are the `certificate.certificate` and `certificate.key` models. Adding `compute_sudo` and `sudo()` calls where it's needed in actions that can be performed by non-admin users. task-6018713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253336
This update resolves an issue where custom snippets that were hidden on desktop or conditionally visible appeared as blank in the website builder's preview dialog. The changes ensure that all snippets, regardless of their visibility settings, are accurately displayed, improving the user experience when creating and previewing website content. An icon has also been added to identify invisible snippets.
Original PR description
The (saved custom) snippets which were invisible on desktop or conditionally invisible, appeared as empty in the dialog to preview snippet. This commit changes the css rules so that - conditionally visible elements are always visible in preview - snippet that are device invisible are show with the overlay (and inner elements that are device invisible are not shown) Steps to reproduce: - Open website builder - Drop a section - Change the "Visibility" to hide on desktop - Click on the eye to show it - Save the snippet as a custom snippet - Open the dialog to add a snippet - Bug: the newly saved snippet is shown as empty Same for "Visibility" to "Conditionally". And Same for "Visibility" to hide on mobile, if the window size is reduced when showing the dialog. task-5149984 Forward-Port-Of: odoo/odoo#250395
This update resolves an issue where the department dropdown was empty in the demo activity plan configuration. The fix corrects a misconfiguration in the demo data that was preventing departments from appearing. This ensures users can correctly assign departments to onboarding and offboarding plans.
Original PR description
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The…
# How to reproduce - Be in a single company environment - Employees app > Configuration > Activity Plan > Either demo plan (Onboarding or Offboarding) - Try to select a department # The problem The dropdown is empty even if department exists. This can be check by creating a new plan and trying to assign departments to it. # Cause The demo data for thoses two plan explicitely sets the company_id to false : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L21 https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/data/hr_data.xml#L48 But the department_id has check_company set to true : https://github.com/odoo/odoo/blob/2c14ce9f655a1eea3d7b1cb0e0ce8108cf9da0df/addons/hr/models/mail_activity_plan.py#L12 # Proposed solution Backport of this commit : https://github.com/odoo/odoo/pull/240167 opw-6058697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255842
This update addresses a technical error that occurred when generating QR codes for UPI payments within the In-POS module. The fix ensures that the payment process continues smoothly, preventing errors and improving the user experience. This change focuses on maintaining the integrity of the system's error handling.
Original PR description
With the 'upi' qr method, we get a `NotImplementedError` raised by `ResPartnerBank._get_qr_code_generation_params` when trying to open the payment register wizard from a vendor bill. With this commit, we override the method to return None for the 'upi' method case, that way we keep the correct way of using `NotImplementedError` which expects us to always implement `_get_qr_code_generation_params` when we add `_get_available_qr_methods`, to make it explicit that there is nothing to do and that we didn't forget to implement. opw-5978048
This update ensures marketing emails sent in RTL languages (like Arabic) are correctly formatted. Previously, the system incorrectly converted RTL content to LTR, leading to display issues. The fix adds a necessary style parameter to the email composer, allowing for proper rendering using the rtlcss library.
Original PR description
**Steps to reproduce:** - Install Mail Marketing app - Change user language to a RTL language (such as Arabic) - Create a marketing campaign with RTL content - Send it (with the campaign, test mail works properly) - Mail received changes from RTL to LTR **Issue:** Table `direction` style is removed by the `_Cleaner` as it is not in its `_style_whitelist` during the composer creation. **Fix:** Add it to the valid styling to ensure rtl mails are properly formatted by the rtlcss library. related fix: https://github.com/odoo/odoo/commit/4ac3766fa5b458864c1728441cf4a157df943d39 sanitize on `mail.composer.mixin`: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 opw-5982854 Forward-Port-Of: odoo/odoo#257886
This update resolves an issue where button styling was inconsistently applied in the website editor. The fix ensures that buttons with size or shape classes are correctly identified as 'custom', aligning with recent changes to Odoo's styling options. This improves the visual consistency and functionality of buttons within the website editor.
Original PR description
Before this commit: Since the removal of button style options for the preset primary and secondary styling, the type of a primary/secondary button with size or shape defined in the class should be "custom". The fix is made to saas-18.4 cause the custom button option is removed in saas-18.3 and reintroduced only from saas-18.4. The button option removal commit: https://github.com/odoo/odoo/commit/a7b71d700e4997e4a2f646e2ae12f58f20058dc4 The button custom option reintroduction: https://github.com/odoo/odoo/commit/ea22b28bbae009c9eab4ff397affa9a3cb71037a After this commit: when the button has size or shape classes, we consider it as "custom" button. task-6061443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257156 Forward-Port-Of: odoo/odoo#256015
This update resolves an issue where the HTML editor would unexpectedly scroll to the top when the command palette was closed. The fix ensures the editor's selection is maintained, preventing this disruptive behavior. This improvement enhances the user experience within the HTML editor.
Original PR description
Before this commit: the editable area scrolls to the top when the command palette is closed by clicking the gray zone After this commit: we override the focus function of the editable and use focusEditable instead, which keeps the selection. Note it's a succession fix of https://github.com/odoo/odoo/pull/250624 and both of them are a workaround without touching the ui_service and command palette. Also added super.destroy() in the previous fix till 18.4. task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256695 Forward-Port-Of: odoo/odoo#253638
This update fixes a bug that was limiting product searches to a single category, even when users arrived directly at a product page. Now, product searches will perform a global search across all products, regardless of how the user accessed the product. This enhances the user experience and ensures accurate search results.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page.…
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page. - Now search for `drawer`. Issue: --- - Searching from a product page always scopes results to the product's category, even when the user navigated directly to the product without selecting any category. Root cause: --- - The issue occurs because `_prepare_product_values()`[1] always assigns a category using the fallback `product.public_categ_ids[:1]` when no category is explicitly provided. As a result, the `keep` object is generated with `_get_shop_path(category)`[2], which produces a category-based shop URL. Since the search form action is defined as `keep(search=0)` [3] in the template, the generated search URL always includes `/shop/category/<slug>`, even when the user accessed the product page directly. This unintentionally scopes all searches to the product’s first public category instead of performing a global `/shop` search. Solution: --- - Separate the breadcrumb logic from the search context logic. Before automatically assigning a default category for breadcrumb display, store the originally requested category (which is None when navigating directly to a product). - Use the auto-assigned category only for breadcrumb display. - Use the originally requested category to build the keep QueryURL [1]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L796-L799 [2]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L806-L812 [3]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/views/templates.xml#L360-L372 opw-5969662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251751
This update fixes a display issue in the Delivery Slip report where backorder lines were missing their unit of measure. The fix removes a technical restriction that was previously hiding this information, ensuring all delivery line details are consistently shown. This improves clarity and accuracy for users reviewing delivery reports.
Original PR description
**Steps to reproduce:** * Install the **Stock** module with demo data. * Create a delivery with quantity **N** and click **Mark as To Do**. * Set the delivered quantity to less than the demanded…
**Steps to reproduce:**
* Install the **Stock** module with demo data.
* Create a delivery with quantity **N** and click **Mark as To Do**.
* Set the delivered quantity to less than the demanded quantity .
* Validate the delivery, with the creation of a **backorder**.
* Print the **Delivery Slip** report.
**Observed behavior:**
* Backorder lines appear **without units of measure**, while
other lines correctly display their units.
**Cause:**
* The backorder line includes a **group restriction** that hides
the unit unless the *Unit of Measure* setting is enabled.
**Fix:**
* Remove the group restriction so units of measure are
always visible on backorder lines same as others.
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/5f21139a-a4ab-4c39-8b16-3c68c94a163e" />
After:
<img src="https://github.com/user-attachments/assets/dd4de18b-dc2e-4686-8435-30864fe40aa4" />
</details>
---
> NOTE - This fix done after receiving confirmation from PO(dala)
---
opw-5265051
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258235
Forward-Port-Of: odoo/odoo#238470This update clarifies the instructions for setting up printers in the Point of Sale system. The previous help message was inaccurate, leading to confusion. This change ensures users correctly connect IoT printers using the appropriate settings, improving the overall user experience.
Original PR description
The "help" message displayed on the Printers settings was misleading: "connect devices without IoT Box", even though the IoT printer has to be connected using the same field.
This update ensures that refused time off requests are now clearly marked on the calendar view within the Overview menu. Previously, these requests weren't visually distinguished. This change improves clarity and accuracy for managers reviewing employee time off requests.
Original PR description
Before this commit, the calendar view in Overview menu does not strike the time off refused. The reason is because `is_strike` field is not fetched inside that view. This commit adds the field in the view to make sure the time off refused are striked as it is the case in the other menus. Closes #248868 Forward-Port-Of: odoo/odoo#256723 Forward-Port-Of: odoo/odoo#256579
This update fixes a visual issue in the mass mailing editor where setting button sizes (Large, Small) or styles (Outlined) didn't actually change the button's appearance. The update now correctly applies the selected size and style, providing a more consistent and customizable user experience for creating marketing emails.
Original PR description
Currently, setting a button as Large, Small, or Outlined has no impact on the appearance of the button, as it instead remains dependent on mailing-wide set button dimensions and colors. Steps to reproduce: - Create a new mailing - Type /button in the editor to insert a button - Select the button and set its size as Large/Small or its nature as Outlined - The button's appearance does not change This commit allows Large, Small and Outlined button attributes to have an effect on button appearance. Sizes will scale linearly with mailing-wide button dimensions. task-5910193 Forward-Port-Of: odoo/odoo#252033
This update resolves a problem causing inconsistent test results in the HTML editor. The fix ensures tests wait for the system to fully initialize before running, preventing failures due to timing issues. This improves the reliability of the HTML editor's testing process.
Original PR description
See individual commits. Forward-Port-Of: odoo/odoo#258148 Forward-Port-Of: odoo/odoo#257620
This update fixes an issue where project template tasks were incorrectly displayed in standard task views. Now, template tasks are hidden by default, but can be easily viewed when the 'Template Tasks' filter is selected. This ensures a cleaner and more intuitive task management experience.
Original PR description
## Current behavior before PR: - When a user viewed All Tasks or My Tasks, tasks related to project templates were visible. - When a user specifically selected the Template Tasks filter, tasks associated with template projects were not visible. ## Desired behavior after PR is merged: - When a user views My Tasks or All Tasks, tasks related to template projects are hidden. - When a user selects the Template Tasks filter, both template tasks and tasks associated with template projects are shown. ## Additional note A modification to `project_report.py` was required because it inherits from the project task view and overrides the view’s reference model. Task-[5485658](https://www.odoo.com/odoo/project/4105/tasks/5485658) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245920
This update ensures that new purchase orders, repairs, and stock picking batches display translated names instead of the default 'New' in English. This change aligns with existing Odoo logic and provides a more consistent and user-friendly experience, especially for international users.
Original PR description
New POs, repairs, and batch pickings always showed "New" in English for the name of a new (not saved) record. We now make it match the SO logic to show up as translated so as to not confuse users (even though it will automatically change to another name once saved) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258156
This update fixes an issue where event descriptions in Outlook Calendar downloads were displayed as raw code instead of properly formatted HTML. The fix converts HTML content to text specifically for Outlook compatibility, ensuring event details are displayed correctly when users download and view their events.
Original PR description
### Steps to reproduce: - Download Events app. - Pick an event and click "Go to website". - Download the Outlook Calendar. ### Issue: - The HTML content within the event description is displayed as raw code and not converted properly - This happens because outlook takes the description as text and displays it in the ics file without conversion ### Solution: - Since we're working with *Outlook Calendar*, X Alt formatting was added to format HTML to text opw-5237027 Forward-Port-Of: odoo/odoo#257978 Forward-Port-Of: odoo/odoo#246603
This update ensures that the milestone list view, accessed through both the Kanban and top bar actions, displays all relevant sales-related information. Previously, the top bar action didn't include these key metrics, leading to an incomplete view of project milestones. This change standardizes the view for improved reporting and analysis.
Original PR description
Steps to reproduce: - 1. Install the sale_project module. 2. Open a project and ensure it is billable. 3. Compare the view opened from the "Milestones" link in the Kanban view with the view opened from the "Milestones" top bar action. Issue: - The milestone list view opened from the top bar action does not display sales-related fields (e.g., "Quantity (%)"). Cause: - The Kanban view calls the `action_get_list_view` python method, which is overridden in sale_project to add a custom list view including sales-related fields. The top bar action was using a static XML action, bypassing this python logic. Fix: - Update the Milestones embedded actions to call the `action_get_list_view` python method instead of using a static XML action, ensuring top bar uses the same view as others. task-5993183 Forward-Port-Of: odoo/odoo#258149 Forward-Port-Of: odoo/odoo#254102
This update resolves an issue where the AutoComplete dropdown would unexpectedly close when its value changed without user input. Specifically, this prevented the dropdown from staying open while the system updated the category selection in the Expenses module. This ensures a smoother user experience when selecting categories.
Original PR description
Before this commit, when the props of the AutoComplete were updated such that the value changed while the dropdown was opened, but the user didn't type anything yet, the dropdown was closed. This could be reproduced in Expenses: - click "New" to create a new expense - set a description - blur the description field by clicking on the category many2one => the autocomplete dropdown briefly opened and closed itself again while the onchange returned, as it set the value of category_id. This commit fixes the issue by never closing the dropdown when the value is changed. Issue reported in the rd-framework-js channel Part of task 5491410 Forward-Port-Of: odoo/odoo#258070
Features or functions removed from Odoo
This change removes a previously added and now unnecessary module, `l10n_it_edi_ndd_account_dn`, that was created during a forward port. This module was removed from a previous version and is now being cleaned up to ensure consistency across Odoo saas-18.4 through saas-19.1. This ensures a stable and streamlined system.
Original PR description
This commit removes the files of the zombie module `l10n_it_edi_ndd_account_dn` that was added with the forward port of this commit: https://github.com/odoo/odoo/commit/3f85d1032b9784cd15341c0f6d40c13d4146d764 It was removed from saas-18.4+ this PR should remove the zombie module from saas-18.4 till saas-19.1 (included) opw-5930596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257275