Daily updates from Odoo
Wednesday, May 6, 2026
35 changes · saas-19.1
New functionality added to Odoo
This update prepares Odoo for a new Belgian tax regulation. Starting May 1st, businesses will need to use a dedicated 'Tax Provision Account' (411800) instead of their existing accounts for VAT periodic returns. This change ensures compliance with updated Belgian accounting standards.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Enterprise PR: odoo/enterprise#111599 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/odoo#262715 Forward-Port-Of: odoo/odoo#255272
This update prepares Odoo for the new Belgian VAT reporting requirements, effective May 1st. It adds a dedicated 'Tax Provision Account' (411800) to ensure accurate reporting of VAT provisions, aligning with current regulations. This change simplifies VAT reporting for Belgian businesses using Odoo.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Community PR: odoo/odoo#255272 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/enterprise#116182 Forward-Port-Of: odoo/enterprise#111599
Resolved issues and error corrections
This update optimizes how the HTML editor recalculates styles during updates, leading to a smoother and faster user experience. By reducing unnecessary style calculations, the system now responds more quickly to changes, improving overall performance. This change addresses a technical issue that was causing delays in the HTML editor's responsiveness.
Original PR description
Description of the issue this PR addresses: Before this PR, updateHooks retrieved the computed style for each visible element and accessed marginTop and marginBottom inside the loop. Accessing properties of CSSStyleDeclaration may trigger style resolution, causing repeated 'Recalculate Style' work during hook updates. This PR extracts marginTop and marginBottom after getComputedStyle outside the loop, which reduces style reads during hook updates and avoids unnecessary style recalculations. task-6063534 closes odoo/odoo#252385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259341
This update fixes a bug where unallocated earnings weren't appearing in the general ledger CSV export. The change adds a 'Currency' column to the export and updates the report generation process to ensure all earnings are included, providing a more complete financial overview. This improves the accuracy of financial reporting.
Original PR description
1) The unallocated earning lines were missing from the general ledger csv export, as they are added in post-processing. The fix is to call `_get_lines` instead of the report custom engine directly. 2) Also adding the "Currency" column to the csv export. Forward-Port-Of: odoo/enterprise#115987
A test related to rental stock management was failing due to a duplicate configuration within the demo data. This update ensures the test runs correctly by preventing the creation of redundant 'out of stock' ribbons. This resolves a technical issue that could have impacted test results.
Original PR description
Currently, running test `test_out_of_stock_ribbon_is_not_applicable_for_rentals` with demo data enabled leads to a validation error: `Only one ribbon with the "assign when out of stock" option is allowed.` This happens because, with demo data loaded, an "out of stock" ribbon is already created via XML data. The test then attempts to create another ribbon with the same configuration, triggering the constraint and causing the failure. Related PR: https://github.com/odoo/enterprise/pull/112660 runbot-[242457](https://runbot.odoo.com/odoo/error/242457) --- Forward-Port-Of: odoo/enterprise#116162
This update resolves an issue where users would lose focus while searching for companies in the dropdown menu. The fix ensures the search input remains focused, providing a smoother and more reliable experience when typing. This prevents interruptions and improves usability.
Original PR description
If a user leaves their mouse resting over a company in the dropdown and starts typing in the search bar, the search bar loses focus, interrupting their typing and removes focus from the search input. Update the `onSearch` method to: - Remove focus from the highlighted dropdown item. - Put focus immediately back into the search input. - Briefly disable mouse events on the menu (for 100ms). This prevents the system from registering a fake mouse hover while the list updates. Forward-Port-Of: odoo/odoo#259369
This update corrects a bug where attachments weren't uploading correctly when navigating between records in the chatter. The fix ensures attachments are properly associated with the intended record, preventing data inconsistencies and improving the reliability of attaching files.
Original PR description
Currently, when uploading a bunch of attachments or a big one to the chatter, if you click on the pager (e.g. next) before the upload is complete, the attachments that have not yet been uploaded are uploaded to the next record. Due to the persistence of the Chatter component during record navigation and the fact that the `FileUploader` logic is tied to `state.thread`, an async callback that finishes after a record switch will attempt to update the currently active thread rather than the one that initiated the upload. With this change we tie uploader lifecycle to a specific record and ensure the completion callback only affects that record. task-5119290 Forward-Port-Of: odoo/odoo#262714 Forward-Port-Of: odoo/odoo#261552
This update fixes an issue where a horizontal scrollbar obscured the bottom border of the code view when content overflowed. The change repositioned the scrollbar to ensure the border remains visible, improving the overall visual consistency and user experience of the code editor.
Original PR description
Problem: When the code view contains content that overflows horizontally, the horizontal scrollbar hides the bottom border of the code view. Solution: Move the scrollbar inside the code view so the bottom border remains visible. Before: <img width="716" height="76" alt="image" src="https://github.com/user-attachments/assets/05b16d8e-4014-488f-84d6-f4e4c0dcae23" /> After: <img width="707" height="108" alt="image" src="https://github.com/user-attachments/assets/7151e3e0-254c-4e7c-bcda-bea2d7ab2cea" /> Steps to reproduce: - Add content in the code view that overflows horizontally. - Observe that the scrollbar hides the bottom border. task-6124267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261554
A technical error preventing cash payments on POS terminals using Razorpay was resolved. The fix ensures the system correctly handles payment selections, preventing a crash and improving the reliability of the POS payment process. This update ensures smooth transactions for our retail partners.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update optimizes the way the spreadsheet component interacts with field selections, reducing unnecessary processing steps. Previously, the system was repeatedly calling a costly function, leading to performance slowdowns. This change ensures a smoother and faster experience when using the spreadsheet feature.
Original PR description
Currently, the component `ModelFieldSelector` will call the field service on `willUpdateProps` regardless of its current state. Since the introduction of the persistent cache, there is a slight overhead when calling the fieldService (notably caused by the call to deepCopy) and this call can now become costy when called repeatedly, which occurs in the spreadsheet component for instance. Task-6185388 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#262497
A minor typographical error in the French Profit & Loss report (P&L) has been fixed. Specifically, the term 'exceptionnel' was incorrectly using masculine form when it should be feminine to accurately reflect charges. This ensures correct reporting for French accounting standards.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves a duplication issue in the Profit and Loss report for French accounting (l10n_fr_reports). The fix removes a mistakenly included account, ensuring accurate financial reporting. This improves the reliability of financial data for French-speaking customers.
Original PR description
This commit is an addon to this commit[[1]] where we tried to avoid duplicate accounts in the Profit And Loss report. The problem is that we don't exclude the separated account 6492 from the original one (649). This commit adds the removal of this account in the report formula. task-6053784 Here is the coverage: [Profit and loss account (FR) - Accounts Coverage Report (2).xlsx](https://github.com/user-attachments/files/27011824/Profit.and.loss.account.FR.-.Accounts.Coverage.Report.2.xlsx) The correct separation: <img width="837" height="485" alt="image" src="https://github.com/user-attachments/assets/ebe98976-f689-4389-866a-c9a0c8b50534" /> [1]: https://github.com/odoo/enterprise/commit/4587c49c4b220305652150d2f21a95fb7cfa188d Forward-Port-Of: odoo/enterprise#115060 Forward-Port-Of: odoo/enterprise#114858
This update resolves an issue where Amazon's fulfillment channel data caused stock synchronization problems. The system now uses a more reliable field from the Listings API to determine channel availability, defaulting to FBM when necessary. This ensures accurate stock updates and avoids disruptions in Amazon sales.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#115899 Forward-Port-Of: odoo/enterprise#114473
This update corrects a technical issue in the Discuss module that prevented proper sorting of partners based on email prefixes. The fix ensures that partners with matching email addresses are prioritized correctly, improving the functionality of the Discuss feature. This resolves a bug impacting partner organization.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
This update resolves a visual bug where text highlights in the website editor were incorrectly displayed in front of the text on Firefox. The fix adjusts how SVG highlights are added to the HTML, ensuring they render behind the text as intended. This improves the overall user experience for website editing.
Original PR description
# How to reproduce - Go to the website editor - Select some text that wraps - Add text highlight to that text # The problem On firefox, for every line of text that wraps, the highlight is displayed in front of the text instead of behind. # Why The highlights are made of SVG's that are added to the html element of the selected text. To be sure that theses SVG's are displayed behind the text, they have position: absolute and z-index: -1. Sadly, z-index and absolute positionning in an inline context (like in a span) is a browser specific behavior and in the case of firefox, seems to sometimes be ignored. Since the SVG's are appended in the html element after the text, they are rendered after. This fix aims to insert the SVG's in the html element before the text to make sure the rendering order is correct opw-5976647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254196
This update resolves an issue where the last column of accounting reports was partially cut off when scrolling. The fix adds bottom padding to the reports, ensuring all data is fully visible and accessible. This improves the clarity and usability of financial reports.
Original PR description
Before this commit, there was no bottom padding in the accounting reports, which caused the last column’s values to appear partially cut off when scrolling to the bottom. This issue started occurring after the PR: https://github.com/odoo/enterprise/pull/99198 opw-6130981 **Before fix (runbot)** <img width="1920" height="1005" alt="image" src="https://github.com/user-attachments/assets/808bbb2b-3b4e-4b5c-a872-b8bd7bf589ba" /> **After fix:** <img width="1917" height="1006" alt="image" src="https://github.com/user-attachments/assets/55f04e1f-0469-46e1-af69-f5055a7232d9" /> Forward-Port-Of: odoo/enterprise#116168
This update fixes an issue where users could accidentally select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents misdirected support requests.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#116157 Forward-Port-Of: odoo/enterprise#111909
This update fixes an issue where the emission factor date range wasn't showing correctly. The missing 'always_range' option was the root cause, preventing accurate display of valid dates. This ensures users see the correct period for emission factor calculations.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#115832 Forward-Port-Of: odoo/enterprise#114784
This update resolves a bug that prevented accurate balance calculations during multi-currency bank reconciliation edits. Specifically, changing the currency of a bank statement move line and then re-editing it would reset the balance to zero. This ensures correct balance tracking for financial reporting.
Original PR description
Fixed an issue where when editing a move line for the bank reconciliation and setting the currency to a currency other than the company's currency if we edit the move line again we will find that the balance is equal to 0. task-6037835 Forward-Port-Of: odoo/enterprise#114898
This update resolves an issue where referenced refunds in Viva.com were incorrectly reversing payments. The problem stemmed from a previous update removing a necessary session ID. This fix restores the session ID, allowing refunds to function as intended and ensuring accurate payment reversals. A new test tour has also been added to verify the full refund process.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262788 Forward-Port-Of: odoo/odoo#262475
This change corrects a visual issue in the online shopping cart where a product offering free shipping (a reward) incorrectly displayed a border. The fix removes this border, improving the user experience and ensuring the cart looks clean and professional. This was a minor cosmetic issue addressed to maintain a consistent and polished presentation.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program…
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program and edit the reward to set the reward type to `Free Shipping`. - Create a new product, set its price to 1000, and publish it. - Open the product on the website and add it to the cart > open the cart. Issue: --- - The quantity field for the unsellable product (Free Shipping reward) displays a border in the cart. Root cause: --- - The form-control class is applied to the quantity field at [1]. - This class includes a default border style defined in Bootstrap at [2]. Solution: --- - Apply the Bootstrap utility class `border-0` to remove the border from the quantity field for unsellable products. [1]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/website_sale/views/templates.xml#L2901 [2]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/web/static/lib/bootstrap/scss/forms/_form-control.scss#L5-L31 Before: --- <img width="822" height="135" alt="image" src="https://github.com/user-attachments/assets/d66c0445-5fd4-45c5-ae81-b4270cab6378" /> After: --- <img width="827" height="132" alt="image" src="https://github.com/user-attachments/assets/9cc2bd65-c542-4d1f-89de-2212fa968c8e" /> opw-6153161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261275
This update corrects a technical issue that caused a traceback when users removed the Unit of Measure (UOM) from a sales order line. The fix prevents unnecessary calculations related to discounts, ensuring the system functions smoothly when a UOM is not initially set. This improves overall sales order processing reliability.
Original PR description
Issue: --- Due to this issue, there is a TB when you try to remove uom. Steps to reproduce: 1- Create a SO and add a line. 2- On SOL, remove uom. You get a traceback. This is because of `ensure_one` here: https://github.com/odoo/odoo/blob/saas-18.4/addons/product/models/product_pricelist_item.py#L588 We can prevent the discount compute on the line which is causing the `compute_price`, when uom is not set. opw-6144426 Forward-Port-Of: odoo/odoo#262266
This update corrects a rounding error that occurred when importing purchase orders processed through OCR. The fix restores the standard rounding precision, which was originally designed for EDI, rather than the OCR process. This ensures accurate invoice calculations and prevents discrepancies.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116141 Forward-Port-Of: odoo/enterprise#116021
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly appearing in the Mod347 BOE export. The fix removes a redundant search process that was adding partners unnecessarily, ensuring only relevant partners are included based on the primary export requirements. This improves the accuracy of the BOE reports for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#115744 Forward-Port-Of: odoo/enterprise#110947
This update resolves an issue preventing employees from directly modifying their work location within the system's preferences. The change utilizes a specific function to correctly handle access to employee data, addressing a restriction introduced in a previous update. This allows employees to accurately reflect their work arrangements.
Original PR description
**Steps to reproduce** - Have a user without HR rights and linked to an employee - With this user, open Preferences and in the calendar tab and try to change the work location for one of the days - Error: You do not have enough rights to access the field "version_id" on Employee (hr.employee). **Cause** Issue after 72ac4b03657d617644ae75f2957aaec7acf6c1a8 which removed SELF_READABLE_FIELDS and SELF_WRITEABLE_FIELDS. **Change** Use the `field_employee` function introduced in 9605045313953b4c8c734c0d52e8032e3c36bf3a (commit message contains the explanation as to why it is necessary for fields coming from the employee model). opw-6127522
This update resolves an issue where quantities were incorrectly doubled when settling sales orders in POS with the 'Pick then Deliver' warehouse method. The fix ensures accurate lot tracking by filtering move lines correctly, preventing double-counting of inventory. This improves the reliability of sales order settlements.
Original PR description
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading…
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots. Steps to reproduce: ------------------- * Create a product with Tracking by lots * In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)" * Create a quotation with the product and confirm it * Validate the delivery * In POS, settle the sale order from Quotation/Order * When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes > Observation: Quantity doubled. Why the fix: ------------ read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice. We now use move lines from exactly one picking and filter by sale_line_id. opw-6001585 Forward-Port-Of: odoo/odoo#262237 Forward-Port-Of: odoo/odoo#253539
This update fixes an issue where the CustomGroupByItem select within the search bar menu wasn't properly styled on hover. The fix ensures the dropdown items appear correctly, enhancing the user experience and visual consistency. It also restores keyboard navigation functionality for this item.
Original PR description
The CustomGroupByItem select was missing the `o-navigable` class, so the navigation system never registered it. On hover, it would not receive the `focus` class, which ensures proper styling of dropdown items. The fix also restores the ability to reach the CustomGroupByItem select with keynav. task-6108677 Forward-Port-Of: odoo/odoo#262608 Forward-Port-Of: odoo/odoo#260675
This update optimizes how Odoo searches for products, specifically when using 'like' operators in domain filters. The change utilizes 'UNION ALL' instead of 'OR', allowing the database to efficiently use indexes and significantly reducing search times. This results in a faster and more responsive product search experience, especially with large product catalogs.
Original PR description
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product…
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.
When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.
Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.
In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.
#### speedup
In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.
In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.
opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239369
Forward-Port-Of: odoo/odoo#229275This update resolves an issue where custom snippets weren't correctly applying translated content when using the delayed translation feature. The change ensures that translated values are properly reflected in the second language version of a website page, improving the consistency of multilingual content. This fix addresses a bug impacting the website builder's functionality.
Original PR description
The feature "delayed translation" and "copy translation in custom snippet" have been worked on in parallel, but had buggy interactions. This commit changes the way translations terms are copied in custom snippets to read and write the translated values as expected with delayed translations. Steps to reproduce: - With a page with some content on a website in 2 languages - Open the website builder in the main language - Drop a custom snippet - Save - Bug: The change is immediate on the version in the second language (instead of being only available after user translated it) Delayed translations: 2d08f97c0778469b409fca23f2be5f5a98ce3df8 Copy translation in custom snippet: d3426b7714012e833caae10281cfb8433223299a Re-enabling delayed translations: 03a85b13b2c46ef7174123d902e95d5103031c6c task-5474184 Forward-Port-Of: odoo/odoo#245850
This update fixes an issue where the table menu options weren't updating when users switched to different cells. The change ensures that the menu accurately reflects the current target cell by updating values in real-time. This improves the user experience and prevents incorrect menu options being displayed.
Original PR description
After this commit [1], setup is executed only on the initial mount of the table menu and not on subsequent target cell changes. As a result, colItems, rowItems, and other values found in setup become stale, causing the menu to display options that do not reflect the current target cell. This commit moves the necessary values from setup into useEffect so they update correctly when the target cell changes. task-6111986 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Backport of Commit https://github.com/odoo/odoo/commit/729c45ddf3d1e377507d93997c5ca45984d64d75 Forward-Port-Of: odoo/odoo#260435 Forward-Port-Of: odoo/odoo#258590
This update prevents users without write permissions from dragging and dropping files into the Chatter interface. This improves security and prevents accidental file uploads to restricted conversations. The change ensures that only authorized users can contribute files to chatter threads.
Original PR description
This commit disables the drag&drop of files into the chatter if the user cannot post on the thread. Part of task-6071789 PR enterprise: https://github.com/odoo/enterprise/pull/115658 Forward-Port-Of: odoo/odoo#262018
This update resolves an issue where the 'attach file' button wasn't appearing correctly in the email testing environment. The fix ensures the button is enabled only after the email thread has fully loaded, improving the user experience and preventing errors when attempting to attach files.
Original PR description
Wait for the attach file button to be enabled, meaning that the thread is loaded. PR community: https://github.com/odoo/odoo/pull/262018 Forward-Port-Of: odoo/enterprise#115658
This update fixes an issue where the product carousel displayed fewer than 16 products when a product had over 256 variants. The fix removes a previous workaround that artificially increased search limits, allowing the carousel to accurately display products with a large number of variations. This ensures a better user experience when browsing products with many options.
Original PR description
# How to reproduce - Create a Product with more than 256 variants - Publish it to the website - Go to the website and add a Product Carousel - Set it to display newest products & hide variants # The…
# How to reproduce - Create a Product with more than 256 variants - Publish it to the website - Go to the website and add a Product Carousel - Set it to display newest products & hide variants # The problem Fewer than 16 products are displayed # Cause This issue was already adressed by this commit : https://github.com/odoo/odoo/pull/195857 But because of limitations for specifically the "Newest Products" filter (cf. original commit message), the fix was only a workaround. Indeed, it increased the search limit to 256 before filtering out the variants, which caused problems when there was more than 256 variants. But since then, big changes made in 19.0 has allowed us to implement a better fix : https://github.com/odoo/odoo/commit/e3b062e5d3820 # Proposed Solution Since we can now pass the model in the options : https://github.com/odoo/odoo/blob/b5069328734e623c12b0de50a177d501f7f0c995/addons/website/models/website_snippet_filter.py#L90 We give "product.template" when the `hide_variants` option is enabled and we filter on products. This allows use to remove the whole workaround that needed increase the limit on product searchs then getting their templates. A recent commit blocks passing "product.template" since it does not have a dedicated snippet filter : https://github.com/odoo/odoo/pull/257208/changes/8e264ae4ea6ae16bbd410ac384733ff8759938a6 But in the commit message, they mention that this targets snippet in single-record mode, which is not our case. So, we move the logic to only be applied for single-record filters opw-6054059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260340
This update resolves a problem where Nilvera was not sending recently created invoices to Odoo. The change extends the date range used to fetch invoices by 3 hours to align with Nilvera's timezone (Istanbul), ensuring that all invoices are synchronized correctly. This prevents data loss and improves the reliability of the integration.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera does not return recently created documents (within ~3 hours), which can lead to missing invoices during synchronization. # Current behavior before PR: The end_date was set to the current time, causing recently created documents to be excluded from the fetch results. # Desired behavior after PR is merged: The end_date is extended by 3 hours (TR GMT+3), ensuring recently created documents are included and not missed during synchronization. task-id: [6123171](https://www.odoo.com/odoo/my-tasks/6123171) I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#259306
This update fixes an issue where a delay in website navigation transitions could cause dropdown menus to close unexpectedly. By ensuring the menu fully renders before other actions are taken, this change improves the overall stability and reliability of the website experience for users. This resolves a potential disruption to the user flow.
Original PR description
[FIX] website: wait for extra menu to fully render before continuing When clicking on the extra menu item, a Bootstrap dropdown is displayed with a transition. Because this transition takes time, it can lead to undeterministic behavior especially in tests. For example, if a tour clicks on the extra menu item and then clicks on the "Site" button in the navbar, the dropdown transition may still be in progress. This can cause the "Site" dropdown to close prematurely. runbot-240955 Forward-Port-Of: odoo/odoo#262660 Forward-Port-Of: odoo/odoo#261179