Daily updates from Odoo
Thursday, April 9, 2026
51 changes · saas-19.2
Enhancements to existing features
This update optimizes how Odoo searches for calendar resources, specifically when filtering by user. By adding an index, the system now responds more quickly to these queries, leading to a smoother user experience. This change focuses on internal performance improvements.
Original PR description
This commit adds an index on `planning.calendar.resource.user_id`, as it's the only criteria used in `get_calendar_filters` for the `search_count` and the `search_read` done after. Forward-Port-Of: odoo/enterprise#113304
Resolved issues and error corrections
This update fixes an issue where users couldn't manually digitize vendor invoices when the 'Digitize on demand' setting was enabled. The previous version required a bill date, but this change now allows digitization to proceed without a specified date, while still ensuring data consistency through a validation step afterward. This improves the flexibility of the invoice digitization process.
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 resolves a stability issue in the expense tracking wizard by switching to a temporary model. Using a `TransientModel` is the correct approach for wizards, ensuring the wizard data is handled efficiently and reliably. This change improves the overall stability of the expense reporting process.
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 ensures that negative values in the Mod 390 tax reports for Spain (l10n_es_reports) are accurately marked with the 'N' indicator, as required by Spanish tax regulations. Previously, these values were missing the necessary indicator, leading to potential reporting errors. This fix aligns with official documentation and ensures accurate data submission to the tax authorities.
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 SendCloud delivery service encountered an issue. A helpful hint has been added to the error message, guiding users to resolve the problem and ensuring smoother delivery processes. This improves the 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, such as INPS contributions. The fix ensures that the total amount calculated on the tax return accurately reflects only the withholding tax obligations, improving the reliability of Italian tax reporting. This update addresses a previous issue impacting financial accuracy.
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 fixes a minor performance issue with the breadcrumb visibility preview on the website. Previously, the system unnecessarily saved option changes even when simply viewing the preview. This change streamlines the process, ensuring faster preview updates and a smoother user experience.
Original PR description
The option for the visibility option of the breadcrumbs uses a custom save handler (the same as for the header and the footer). To avoid making the rpc to save the options when nothing has been changed, it keeps a flag telling whether there has been any change. This flag was set when changing the visibility option for the breadcrumb even when simply previewing the option. This commit uses the same strategy as for the header and footer's option, and only set the flag if not previewing. task-5149984 Forward-Port-Of: odoo/odoo#250206
This update resolves an issue where expected hours weren't consistently calculated for attendance records, particularly with overtime. The change ensures that expected hours are always accurately updated, preventing discrepancies in reporting and improving the accuracy of time tracking. This fix addresses a bug that caused incorrect hour calculations when overtime was recorded.
Original PR description
The expected_hours field was not always being computed for attendances. self.add_to_compute is used here to ensure that it is always recomputed. 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#256744 Forward-Port-Of: odoo/odoo#251989
This update fixes an issue where invoicing a Point of Sale order multiple times would create unnecessary stock pickings. Previously, clicking 'Invoice' repeatedly resulted in duplicate stock movements, especially when using the 'Anglo-Saxon' accounting method. This change ensures that pickings are only created once, streamlining inventory management and reducing potential errors.
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 fixes an issue preventing portal users from saving changes to their profile information. The change in how access rights are handled in the system required a manual `sudo` check before saving user data. This ensures users can correctly update their profile details, improving the user experience.
Original PR description
# How to reproduce - Install the eLearning module - Log in as a portal user - Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course) - Go to Courses >…
# How to reproduce - Install the eLearning module - Log in as a portal user - Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course) - Go to Courses > View your profile (on the right side) > Edit Profile - Edit any value and confirm by clicking on the Update button # The problem The popup is not saved and a warning notification is displayed with : "You are not allowed to modifiy 'User' (res.users) records" # Why In 19.0, there was no access rights problem because the write operation was done in `sudo` due to this code that checked that every edited field was safe : https://github.com/odoo/odoo/blob/4f77b4c8f7a3ee9f85f045eea02a5749affd4b6a/odoo/addons/base/models/res_users.py#L615 This was the case because we preventively filtered only the safe fields in the save controller : https://github.com/odoo/odoo/blob/355643291e2f4bb05185b996adce6e1f403ecbd4/addons/website_profile/controllers/main.py#L153 In 19.1 though, this commit totally changed the way the acces rights for the fields of the user model were handled : https://github.com/odoo/odoo/commit/a816d151ae16afc62d7980cedc492942bc181884 One of the purpose of this improvement was to make sure a `sudo` is not automatically introduced and rather should be done explicitely when it is needed. # Proposed solution We first check that the current user can modifiy the specified user. If that is the case, we write with `sudo` opw-6032339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256888
This update resolves an issue where the 'Export XML' button wasn't consistently producing the correct EU Standard (Peppol Bis 3.0) invoice file. Now, users can download invoices in this format when selecting it, ensuring accurate data exchange with trading partners in regions like Croatia.
Original PR description
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice…
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice Type as "EU Standard (Peppol Bis 3.0)" - Create an invoice - Confirm it - Click on the Wheel -> Download Current behavior: - without l10n_hr_edi: only "PDF" and "PDF without Payment" - with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file Cause: "Export XML" button appear only if: - there is a default ubl option for the partner country - there is an XML attached to the invoice when clicked it exports the corresponding one. Whereas, the 'send' button rely on: 1) the partner defined edi format, 2) the default ubl option for the partner country 3) "ubl_bis3" To be noted: The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice. opw-5943500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257990 Forward-Port-Of: odoo/odoo#253650
This update corrects an issue where special characters (&) in vendor bill references were causing errors during SEPA payment file generation. The fix replaces '&' with '+' to ensure compliance with SEPA/SIX standards, preventing payment rejection by banks and ensuring accurate export of payment data.
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 fixes an issue where invoices for downpayments were incorrectly using a default expense account instead of the designated ACC1 account. The change ensures that downpayment invoice lines now automatically use the correct account, streamlining the accounting process and preventing misallocation of funds. This improves accuracy and simplifies financial reporting.
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 ensures compliance and accurate invoice delivery.
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 automatically renews the KSeF token for our Polish users every 6 days. Previously, expired tokens caused disruptions in bill and invoice synchronization. This change ensures seamless and uninterrupted data exchange with the Polish tax authority, avoiding 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 consistent reporting of tax amounts in the Dutch (nl) version of Odoo. Previously, a negative sign was used to represent tax deductions, aligning with how taxes were configured. This change standardizes the report output for improved clarity and accuracy.
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 resolves a potential issue in our Point of Sale tests where refreshing the page prematurely interrupted database transactions. By increasing the timeout for these transactions, we've enhanced the reliability of our test suite and reduced the risk of test failures. This ensures our POS functionality continues to perform consistently.
Original PR description
In some tests, we use refresh which will refresh the page after letting the indexedDB finish its transactions. In some cases, the transactions take more time than expected. In this commit, we increase this timeout to avoid failures that could be caused by not letting the time to the db to finish its transactions. runbot-errors: 240911, 240912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253095
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 are correctly identified as available for rental, aligning with their time-based stock management. 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#113280 Forward-Port-Of: odoo/enterprise#112660
This update ensures that subtasks created from project templates, particularly those linked to Sales Orders, correctly inherit the sale_line_id from their parent task. Previously, this resulted in issues with timesheet logging. The fix corrects a technical detail in how project templates are copied, guaranteeing accurate data propagation for all task types.
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 corrects a previous issue where the Amazon fulfillment channel in the sales module was incorrectly displayed as read-only. The change ensures users can now modify this channel setting, allowing for greater flexibility in managing Amazon sales operations. This resolves a reported usability problem.
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 display issue in Danish balance sheet and profit & loss reports. It simplifies the report format using account sublines and ensures accurate Danish translations for improved accounting accuracy. This resolves a bug where amounts weren't shown when certain report settings were active.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113101 Forward-Port-Of: odoo/enterprise#112430
A technical glitch in the UrbanPiper test order wizard was causing errors. This update removes a feature that was attempting to open product forms, resolving the issue and preventing the error from occurring. This ensures the test order wizard functions correctly.
Original PR description
Steps to Reproduce ---------- - Make an UrbanPiper Test Order - Select a product - Click the external-link (open) icon - POS traceback appears Issue ----------- Clicking the “open product” icon triggered a traceback because the POS attempted to load the missing hr_expense_product_form view. Fix -------------- Disable form open/create for the product field to remove the quick-open product icon, as there is no need to open the product form from this wizard. Task-6089707 Forward-Port-Of: odoo/enterprise#112819
This update resolves a technical issue that could cause instability in the Gantt chart feature. The fix ensures that invalid drag actions are properly prevented, enhancing the overall reliability and user experience of the chart. This improves the stability of the enterprise version.
Original PR description
This commit fixes an oversight introduced in https://github.com/odoo/enterprise/pull/106130 regarding the pill dragging safeguard. Previously, the validation check in `onWillStartDrag` correctly halted the drag initialization logic when no valid target was found, but it failed to actually cancel the drag action itself. This commit ensures the failing scenario is virtually impossible so that the fail-safe can be removed.
This update fixes a problem where sending letters with more than 8 pages in the Snailmail module would result in a generic error. The change now provides a more specific error message, helping users quickly identify and resolve the issue when sending large letters. This improves the user experience and reduces support requests.
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, causing the cursor to jump to incorrect locations. The changes ensure that arrow navigation now correctly moves the cursor between code blocks, paragraphs, and other content types, providing a smoother and more intuitive editing experience. This improves the overall usability of the HTML editor for content creators.
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 technical issue that prevented the requirements-check script from correctly parsing package version numbers containing letters and suffixes (like 5.4.2.post1). The fix ensures accurate dependency validation, improving the stability and reliability of the Odoo system. This change addresses a potential error that could have impacted software updates.
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 resolves an issue where creating reconciliation models without specifying a partner or account would cause errors. The fix ensures that either a partner or an account must be provided when adding a counterpart, preventing the system from defaulting to a liquidity account and triggering the error.
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
A technical update has been made to ensure that caching proxies don't store the 'load menus' response from Odoo. Previously, this response was not being properly handled, leading to potential issues where all users might receive the same menu structure. This fix prevents the proxy from storing the data, ensuring a consistent experience for our users.
Original PR description
Since odoo/odoo@ff53267db5d3, the `unique` parameters previously passed to `/web/webclient/load_menus` has been removed. That commit, also instructed the browser not to store the result, but this is not sufficient; in case a caching proxy sits in between the user and Odoo, it will see the `Cache-Control: public` and still store the result. As a consequence, depending on the caching proxy configuration, it could happen to serve the same menus structure to all users. This commit ensures the intermediaries proxies do not store the result. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257064
This update fixes a bug in the website builder where options would unexpectedly fold closed after being expanded. Now, users can reliably keep groups of options unfolded, regardless of target changes, improving the user experience when customizing website elements. This ensures consistent and predictable behavior for website design.
Original PR description
Commit 64d35ccd6fade9e0473686b8484f561b5f4215ce added folding of groups of options. On every target change, all groups were folded, except the last one. But this leads to friction in some cases where the user wants another groups than the last one to stay unfolded. With this commit, a group that stays in the sidebar stays unfolded if the user clicked to unfold it, or if they used an option that changed the target to a descendant. Steps to reproduce: - Open website builder - Drag and drop a banner snippet - Click "add elements/text" - Bug: Banner options folds for no reason #### - Open website builder - Click on a column in the footer - Unfold the options of the footer - Click on another column of the footer - Bug: the options of the footer closes task-5999383
This update ensures the Danish version of Odoo's accounting system aligns with the latest tax regulations from Denmark. It includes updated account details, translations, and migration scripts to maintain accurate financial reporting for Danish businesses. This improves compliance and data integrity.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#257789 Forward-Port-Of: odoo/odoo#256541
This update corrects a technical error that could prevent the system from correctly determining the appropriate work entry type for holiday calculations. This ensures accurate holiday tracking and reporting, improving the reliability of our HR data. The fix was a minor code adjustment.
This update fixes an issue where proforma invoices were incorrectly displaying 'Order' as the document title instead of 'Pro Forma'. The fix ensures the correct title is generated when printing proforma invoices, improving the accuracy of sales documentation. This change was triggered by a previous update and resolves a discrepancy in how document titles are set.
Original PR description
Issue: --- `layout_document_title` is not correctly set in proforma document. Steps to reproduce: 1- Create a SO and confirm. 2- Print the Pro forma invoice. The title is Order while it should be Pro Forma. Cause: --- This issue is introduced after #232539. `is_proforma` is not set before setting `layout_document_title`. opw-6043669
This update fixes an issue in the website editor where links embedded within non-editable icons wouldn't open. The change enables a link popover when clicking these icons, ensuring users can still access the intended links. This improves usability and functionality within the website builder.
Original PR description
Problem: When the website editor is enabled and icons inside links are marked as non-editable, it becomes impossible to open those links. Solution: Enable the link popover when clicking on non-editable icons inside links so the link can still be accessed. Steps to reproduce: - In the website editor, drop a "Social Media" inner snippet anywhere inside the header. - Click on one of the social media icons. - Observe that the link popover does not open, making it impossible to test the link. task-6009319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where marketing emails sent in RTL languages (like Arabic) were incorrectly displayed in a left-to-right format. The fix ensures that RTL content is properly formatted by adding the 'direction' style to the allowed CSS, improving the user experience for international customers. This resolves a bug impacting campaign delivery and presentation.
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 the HTML editor would unexpectedly scroll to the top when the command palette was closed. The fix ensures the editor's selection is maintained, improving the user experience and preventing disruptions while editing content. This was a related fix building on a previous change.
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 ensures that refused time off requests are now correctly highlighted in the calendar view within the Overview menu. Previously, these requests weren't visually marked, making it harder to track their status. This change improves clarity and accuracy for managing employee time off.
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 an issue where invoices were incorrectly using the previous day's currency rate instead of the selected date's rate. The change ensures that invoices accurately reflect the current exchange rate chosen by the user, improving financial reporting accuracy. This was caused by a recent code update and is now resolved.
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 Forward-Port-Of: odoo/odoo#256041
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 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 bug that caused tests in the HTML editor to fail intermittently due to timing issues. By ensuring tests wait for the HTML editor's initial state to fully load, the tests are now more reliable and consistent. This improves the overall stability of the HTML editor functionality.
Original PR description
See individual commits. Forward-Port-Of: odoo/odoo#258148 Forward-Port-Of: odoo/odoo#257620
This update fixes an issue where the Delivery Slip report didn't display the units of measure for backorder lines. The fix removes a technical restriction that was hiding this information, ensuring all line items, including backorders, show their correct units. This improves clarity and accuracy for users generating 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 fixes an issue where automatic invoicing caused guest contacts to be prematurely archived, preventing invoice emails from being sent. Now, archiving is tied to automatic invoicing and only happens after the invoice is successfully sent, ensuring reliable email delivery and proper contact management for invoices.
Original PR description
Before this fix, when automatic invoicing was disabled, manually sending an invoice by email resulted in an empty "Send To" field because the guest contact had already been archived. To prevent this issue, guest archiving is now triggered only when automatic invoicing is enabled. Additionally, to avoid problems with email delivery, the guest is archived only after the invoice has been sent. This ensures that the email generation process sees the guest as active. If the guest were archived immediately after the Sales Order confirmation, the email generation logic in `mail_thread.py` would skip the archived partner (`pdata['active'] is False`), preventing the invoice email from being sent. Forward-Port-Of: odoo/odoo#253674
This update fixes an issue where project template tasks weren't correctly filtered when viewing all tasks or using the 'Template Tasks' filter. Now, template tasks are hidden when viewing general task lists and are correctly displayed when the 'Template Tasks' filter is selected, providing a clearer and more accurate view of project tasks.
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 resolves an issue where invisible website snippets appeared as blank in the preview dialog. The changes ensure that all snippets, regardless of their visibility settings, are correctly displayed in the preview, improving the user experience when building website content. A visual indicator has also been added for custom 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#258084 Forward-Port-Of: odoo/odoo#250395
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, providing a more consistent and user-friendly experience for all 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 were displayed as raw code instead of properly formatted HTML. The fix converts HTML content to text specifically for Outlook Calendar, ensuring event details are displayed correctly. This improves the user experience when downloading and viewing event information.
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 prevents unnecessary camera permission requests when hiding the camera preview during call invitations. Previously, users were repeatedly prompted for permissions, even when the camera was hidden. This change improves the user experience by streamlining the call invitation process and also resolves a related issue with a local 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 Forward-Port-Of: odoo/odoo#257855
This update ensures that the milestone list view, regardless of whether it's accessed from the Kanban or top bar, displays all relevant sales-related information. Previously, the top bar action used a simpler view, missing key data. This fix standardizes the view for a better user experience.
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 before the user typed anything. This was causing a brief, disruptive behavior in the expense creation process. The fix ensures the dropdown remains open while updates occur, improving the user experience.
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
This update ensures that company-paid expenses using SEPA credit transfers correctly require a vendor to be specified. Previously, the system would post these expenses without a vendor, leading to SEPA XML generation failures. The fix adds a validation step to enforce vendor selection before posting, ensuring accurate financial reporting.
Original PR description
**Steps to reproduce:** * Install `account_iso20022` and `hr_expense` module. * Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method. * Leave the `Vendor` field…
**Steps to reproduce:** * Install `account_iso20022` and `hr_expense` module. * Create an expense with `Paid by Company` and `SEPA credit transfer` as the payment method. * Leave the `Vendor` field empty. * Submit, approve, and post the expense. **Observed behavior:** * The expense is posted successfully without a vendor, creating a payment with `partner_id = False`. * The payment cannot be reset to draft due to the missing vendor, and SEPA XML generation fails because the creditor name (`<Cdtr><Nm>`) requires a partner. **Cause:** * The `hr_expense` module overrides `_compute_show_require_partner_bank`. to set `require_partner_bank_account = False` for expense payments, bypassing the partner bank validation in `account.payment.action_post`. * `_prepare_payments_vals` uses `self.vendor_id.id` for `partner_id`, which evaluates to `False` when no vendor is set. * The `_post` method on `account.move` only validates partner presence for invoices (sale/purchase documents), not for `entry` type moves, which payments use. **Fix:** * Add a validation in `hr.expense.action_post` that checks whether the payment method is `sepa_ct`. If so, `vendor_id` must be set before posting. * This catches the issue early in the expense flow, before the payment and journal entry are created. opw-5930687 Forward-Port-Of: odoo/odoo#252384
This update addresses a technical error that was preventing the generation of QR codes for UPI payments within the In-POS module. The fix ensures that the payment process functions correctly, avoiding unexpected errors and improving the user experience. This change was implemented to maintain code clarity and adherence to best practices.
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 Forward-Port-Of: odoo/odoo#251531
This update improves how charges are handled on invoices generated for UBL/BIS3 transactions. Instead of creating a separate invoice line for charges, the charge amount is now directly added to the original invoice line's price unit. This simplifies invoice processing and ensures accurate reporting of charges.
Original PR description
Before this commit: A charge in an InvoiceLine was creating a new invoice line with the amount of the charge. After this commit: The charge is added in the price unit of the original line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257186 Forward-Port-Of: odoo/odoo#254111