Daily updates from Odoo
Wednesday, June 24, 2026
203 changes
23 changes
Resolved issues and error corrections
This update corrects a bug in how Odoo calculates the total value of stock items across multiple companies and currencies. Previously, the system didn't account for currency conversion, leading to an inaccurate value of $20 instead of the correct $30. This ensures accurate stock valuation reporting.
Original PR description
**Steps to reproduce:** - make sure your main company (company 1) has dollars as its main currency - create second company (company 2) and a warehouse in this second company - set euro has the main…
**Steps to reproduce:** - make sure your main company (company 1) has dollars as its main currency - create second company (company 2) and a warehouse in this second company - set euro has the main currency in the company 2 From company 1: - set an exchange rate of 1$ = 0.5 eur on the euro currency - create a storable product with a cost of 10$ and an on-hand quantity of 1 From company 2: - set the cost to 10 eur and set an on-hand quantity of 1 with both company selected and company 1 as the main company selected: - open the stock view and look for your product **Current behavior:** the total value is 20$ **Expected behavior:** with conversion rate, it should be 30$ **Cause of the issue:** when computing the total value we do not apply a conversion rate from the value of the company to the main company selected https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/stock_account/models/product.py#L273 opw-6280108 Forward-Port-Of: odoo/odoo#270575
A recent update to the Odoo Enterprise software (19.2 and later) caused a test for the 'hr_holidays_gantt' module to fail. This was due to an issue with a payroll-related field in the test's configuration. This fix ensures the test runs successfully, maintaining the stability of the holiday planning feature.
Original PR description
__ ## Error description When the test runs with only the module `hr_holidays_gantt` installed, it fails. ## Origin of the issue There's a payroll related field in the `read_specification` variable. ### Note The error is only triggered since 19.2. __ original commit: https://github.com/odoo/odoo/pull/256636 Forward-Port-Of: odoo/enterprise#121119
This update fixes an issue where work order durations were inaccurately calculated by double-counting overlapping time entries. The change filters time entries to include only productive and performance time, ensuring a more precise duration for cost valuation. Additionally, a fix was implemented to prevent timestamp issues during testing, guaranteeing accurate duration calculations.
Original PR description
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current…
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current Situation: Currently real duration is total duration of each time tracking which is not consistent with the time that use to calculate the cost for valuation , see https://github.com/odoo/odoo/pull/205154 .The real duration of a work order was incorrectly summing all time tracking entries regardless of their loss type, and using simple addition which double-counts overlapping intervals. * Solution: - Filter time entries to only 'productive' and 'performance' loss types, excluding 'availability' and 'quality' as they represent downtime/blocking time, not actual work duration. - Pool all productive and performance entries into a single Intervals call so that overlaps across both types are merged in one pass. Note: the enterprise17 implementation groups time entries by loss_type into separate buckets before calling Intervals, which means overlaps between 'productive' and 'performance' entries are not merged and get double-counted. Pooling both types together before the Intervals call avoids this. * This also fix: - Fix _set_duration to ensure newly created time entries start after the latest existing entry's end date. Without this, calling _set_duration twice in quick succession (e.g. in tests) produces two entries with overlapping timestamps, which Intervals correctly merges into one, causing the computed duration to be half the expected value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248381
This update resolves a problem where emojis, such as the firefighter emoji, were being displayed incorrectly due to how they were encoded. The fix backports a more robust regex pattern from the 19.4 release to correctly handle these variations in emoji formatting, ensuring consistent and accurate emoji display.
Original PR description
Bug === Some emoji like `👨🚒` are separated, because they are built using `👨 + Emoji_Modifier + 🚒` (`\uFE0F` can also be used to get the variant of the emoji). Adapt the regex to take into account those Unicode variations. Task-5491124 Forward-Port-Of: odoo/odoo#271373 Forward-Port-Of: odoo/odoo#269719
This update resolves a technical issue that previously caused errors when creating expense accounts without assigned codes. The fix ensures the system handles accounts without codes gracefully, preventing a 'TypeError' and improving overall stability. This change ensures consistent functionality across all expense account types.
Original PR description
## Steps to Reproduce: 1. Install the **Accounting** module. 2. Enable **Analytic Accounting** in Settings. 3. Create and switch to a new company. 4. Create an expense type of account without setting a code. 5. Go to **Analytic Distribution Models** and create a new record. ## Error: `TypeError: 'bool' object is not subscriptable` ## Cause: Since commit https://github.com/odoo/odoo/commit/c3313b336b9f1305c363097745926f2bdf61e277, account codes are optional. When an expense type account exists without a code, `_compute_prefix_placeholder()` tries to extract the first two characters of the account code at [1]. However, an unset code field is treated as False, and slicing this boolean value will raise an error. ## Fix: Only use the expense account code to compute prefix suggestions when the account has a code. Otherwise, keep using the default prefix values. sentry-7553918989
This update resolves an issue where disconnecting and reconnecting serial devices caused performance problems, leading to devices being missed. The fix adds a health check to ensure Odoo properly handles device disconnects and reconnects, improving reliability and preventing deadlocks. This ensures Odoo consistently detects and connects to serial devices.
Original PR description
Quick disconnects/reconnects of serial devices crash the serial driver thread, leaving "ghost" processes that cause deadlocks. It's way faster than the main 3s discovery loop, leading to the interface not seeing the device left then came back. This fix adds a health check to SerialInterface.get_devices(): if a driver thread is dead, it is excluded from the discovery list. This triggers Odoo's native removal flow to cleanly shut down the stale connection, allowing the device to auto-recover on the next poll cycle. opw-6201161, opw-6122057 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271326
This update resolves an issue where the delivery date on a sales order wasn't correctly applied to manufacturing orders, leading to incorrect finished move deadlines. The fix ensures that the delivery date is consistently used, preventing scheduling conflicts and improving the accuracy of production timelines. This impacts order fulfillment and production planning.
Original PR description
Steps to reproduce: - Create a storable product with a BoM, routes MTO + Manufacturing, costing method FIFO + Perpetual (at invoicing) - Confirm a sale order for 1 unit → a manufacturing order is…
Steps to reproduce: - Create a storable product with a BoM, routes MTO + Manufacturing, costing method FIFO + Perpetual (at invoicing) - Confirm a sale order for 1 unit → a manufacturing order is created - Set a Delivery Date on the SO (Other Info tab) - Increase the SO line qty to 2 - Validate the MO → traceback on finished_move.ensure_one() Problem: When a delivery date is set on the SO, it propagates to the MO's finished move via date_deadline. However, `production.date_deadline\ was not updated (guarded by `if not production.date_deadline`) because the MO already had a deadline set at planning time: https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L476 When the SO qty then increases, change_production_qty copies the finished move to create a delta move. That delta move receives production.date_deadline (the stale planning date) instead of the delivery date, so the two finished moves end up with different deadlines and cannot be merged: https://github.com/odoo/odoo/blob/19.0/addons/mrp/wizard/change_production_qty.py#L43 Solution - always update production.date_deadline from its finished moves - link the new delivery move to the finished move after the qty wizard runs so it gets reserved after MO validation opw-6273076 Forward-Port-Of: odoo/odoo#269405
This update ensures Odoo's server processes efficiently load necessary data, leading to faster response times. Previously, a key setting wasn't being applied correctly, but this fix now proactively loads these data sets, optimizing the server's performance. This change improves the overall user experience.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
This update ensures Odoo generates PDF invoices that fully comply with ZUGFeRD standards, a crucial requirement for electronic invoicing in Europe. Specifically, it adds a necessary tag to the PDF file to accurately link the underlying XML data, improving data exchange and reducing potential errors. This change supports current ZUGFeRD specifications.
Original PR description
Adapt `add_attachment` to allow setting the "AFRelationship" tag on the PDF filespec object, In compliance with Factur-X/ZUGFeRD specs that require the AFRelationship tag in the PDF filespec object to reflect the relationship between the embedded XML and the visual PDF content: - /Data: the visual PDF contains more invoicing data than the XML. - /Alternative: the XML and the PDF are two equivalent representations of the same invoice. Additionally, update the embedded XML filename from `zugferd-invoice.xml` to `factur-x.xml`. The former is marked as deprecated since ZUGFeRD 2.0 Ref: sections 6.2.2, 6.3.1, 6.3.2 of the ZUGFeRD 2.4 specification: https://www.ferd-net.de/en/downloads/publications/details/zugferd-24-english opw-6252082 Forward-Port-Of: odoo/odoo#271406 Forward-Port-Of: odoo/odoo#269117
This update fixes a visual inconsistency within the Odoo application. The flag image for Mauritania was incorrectly displayed. This change ensures accurate representation of countries within the system, improving the overall user experience.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
This update restores the creation of rounding move lines within the Point of Sale module. Previously, when the pos_stock module wasn't installed, rounded payments weren't properly accounted for, leading to inaccurate financial records during session closing. This fix ensures accurate financial reporting by correctly handling rounded payment amounts.
Original PR description
Before this commit: = - The rounding move line creation was moved from point_of_sale to pos_stock while removing the dependency of stock on point_of_sale. - As a result, when pos_stock was not installed, no rounding move lines were created for rounded PoS payments, leading to unbalanced journal entries during session closing. After this commit: = - Restored the rounding move line creation in point_of_sale so that rounded payments are correctly handled. task-6214240 runbot-error-242920
This update prevents role warning messages from appearing to users who don't have administrative access to planning. Only administrators, who are responsible for managing roles, will now see these alerts. This improves the user experience by reducing unnecessary notifications.
Original PR description
This commit hides the warning about a resource missing the shift's role from users without the "Planning > Administrator" access right, as only administrators can assign roles and act on the warning. task-6303545
This update corrects a bug where the number of closed tickets displayed was incorrectly including tickets closed today. The change filters out closed tickets to provide a more accurate count, ensuring reporting and data analysis are reliable. This improves the transparency and accuracy of helpdesk metrics.
Original PR description
Before: The Tickets Closed number matches the actual tickets when clicking on it. It shows the tickets closed today, which should be excluded. After: Change the domain of the `ticket_closed` to be able to exclude tickets that are closed today --- task-6234330
This update fixes an issue where long 'Discard' or 'Save' labels in the website builder sidebar would overflow, causing display problems in certain languages. The change now uses ellipsis and tooltips for these labels, ensuring a clean and consistent user experience across all languages.
Original PR description
Before this commit, long `Discard` or `Save` labels could overflow in the website builder sidebar in some languages. After this commit, these labels use an ellipsis and show a tooltip when they are truncated. task-6251151
This update resolves an issue where E-Way Bill amounts were incorrectly calculated when sales prices included tax. The fix ensures that the tax is properly accounted for, leading to accurate E-Way Bill generation for sales with tax-included prices. This impacts sales orders and delivery challans.
Original PR description
`*` = `ewaybill_Stock, sale_stock, purchase_stock` **Steps to reproduce:** * Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`. * Set the Default Tax Price Setting to "Tax Included". * Create…
`*` = `ewaybill_Stock, sale_stock, purchase_stock` **Steps to reproduce:** * Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`. * Set the Default Tax Price Setting to "Tax Included". * Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order. * Generate an E-Way Bill from the Delivery Challan. **Observed behavior:** * The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON. * The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it. **Cause:** * `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped. * `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24). **Fix:** * Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before. opw-6273101 Forward-Port-Of: odoo/odoo#271684 Forward-Port-Of: odoo/odoo#268504
This update enhances the Redsys payment process by translating cryptic error codes into clear, understandable messages. Previously, failed transactions were difficult to diagnose, leading to customer frustration. Now, support teams can quickly identify and resolve payment issues, improving the overall customer experience.
Original PR description
Raw Redsys response codes were not human-readable, making it hard to diagnose failed transactions or provide meaningful feedback. See: https://pagosonline.redsys.es/desarrolladores-inicio/integrate-con-nosotros/parametros-de-entrada-y-salida/#tablepress-11_wrapper --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269968
This update fixes an issue where the tag container overlapped with the header due to changes in translated strings. The fix automatically adjusts the container's position and reduces its height to ensure a clean and consistent layout across different languages and header configurations. This improves the overall user experience.
Original PR description
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and…
Description: - The `.o_sign_template_tags_and_save` container relied on a hardcoded vertical offset (`top: 65px`) while being absolutely positioned. This assumed a fixed control panel height and caused the tags container to overlap with the header content when the neutralized red header bar expanded to multiple lines due to longer translated strings. - Replaced `top: 65px` with `top: auto` to remove the dependency on a fixed vertical offset and allow the element to be positioned according to its computed static position. - Reduced the height of `.o_field_widget.o_field_many2many_tags` from `50px` to `35px` to better fit the available space within the header area and prevent visual overlap between tag rows and surrounding elements. - This change preserves the existing positioning strategy while making the layout resilient to variable header heights caused by translations and other content-dependent UI variations. 19 - https://github.com/odoo/enterprise/blob/3db8db2eac3dff1485c6a1c977c80e573bfe6cab/sign/static/src/scss/sign_backend.scss#L486 Before fix: <img width="1874" height="443" alt="image" src="https://github.com/user-attachments/assets/196feab3-3460-4ed9-9f57-d7744e9c4e4b" /> After fix: <img width="1319" height="412" alt="image" src="https://github.com/user-attachments/assets/93ae5bcd-f0f0-4999-9cf7-f83b82d689ac" /> Forward-Port-Of: odoo/enterprise#118937
A technical issue preventing the creation of opportunity buttons on the website was resolved. The fix corrects a problem caused by recent code changes that incorrectly called a function used to create HTML elements. This ensures that users can now successfully create opportunities from their accounts.
Original PR description
**Steps to reproduce:** - Install CRM app with website_crm_partner_assign - Go to the current user contact page > Partner Assignment - Set its partner level (e.g. Gold) - Go the `/my/opportunities` url of the website - Create opportunity button should be available - On click an error is raised: `TypeError: this.el.createElement is not a function` **Issue:** `createElement` is a method of `Document`, but it's called from a dom element after some `Interactions` refactoring. **Fix:** Properly call the method like before. related: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba opw-6267473 Forward-Port-Of: odoo/odoo#268036
This update fixes an issue where certain configuration settings, specifically a 'bin_path' option, weren't being saved correctly when updating configuration files. Previously, these settings would be lost during a save operation. Now, any setting defined within a configuration file will be preserved across subsequent saves, ensuring consistent system behavior.
Original PR description
Have a configuration file with a "bin_path" entry. Use that config file and --save it. The "bin_path" entry is removed from the new config file, it should had been persisted. The problem is common to all "undocumented options", options that did not exist in `config.py` before ConfigCleaner(7) and that were not created upon --save. We can argue about creating or not those options upon --save with the default config, but what's sure is that when the option be set in the config file, then it must be persisted across saves. Task-6106771 Reference-to: 80007415d621 ([REF] core: ConfigCleaner(7) remove deprecated options) 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#270191 Forward-Port-Of: odoo/odoo#258377
This update resolves an issue where switching between models within the Website Studio form builder caused a crash. The fix ensures both the currently displayed form and the newly selected model are retained in the system's memory, preventing errors and improving the overall stability of the form switching process. This enhances the user experience and reduces the risk of data loss.
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878 Forward-Port-Of: odoo/enterprise#121492
This update removes an outdated method for retrieving system parameters in the l10n_fr_pdp module. Switching to a more standard approach ensures greater reliability and consistency in French payroll processing. This change is a technical update focused on internal improvements.
Original PR description
This commit will remove the use of the get_param for system parameter and instead use get_str no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271342
This update resolves an issue where the due date calculation for French payroll was incorrect, particularly in November. It also corrects a technical error that prevented the system from properly processing records, improving data accuracy and reliability. This change ensures proper French payroll processing.
Original PR description
- Fix due date calculation (returned month 0 if move date was in November) - Fix ensure_one error, avoid calling _deduce_country_code() on an empty recordset opw-6293701 Forward-Port-Of: odoo/odoo#270148 Forward-Port-Of: odoo/odoo#270003
This update resolves a potential instability issue in our spreadsheet testing process. Previously, tests were failing unpredictably due to a lack of awaiting asynchronous operations. By adding the necessary 'await' calls, we've made the tests more reliable and consistent, preventing random test failures.
Original PR description
Some tests did a `model.exportXLSX()` to verify it didn't crash, but did not `await` so a crash would break another test at random. Task: [6328937](https://www.odoo.com/web#id=6328937&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#271721
18 changes
Resolved issues and error corrections
This update fixes an issue where product pricing in the Point of Sale (PoS) system was incorrectly calculating VAT and total prices. The fix ensures that prices, including VAT, accurately reflect the configured pricelist and fiscal position mappings, leading to more reliable sales calculations. This improves the accuracy of transactions and reporting.
Original PR description
Steps to reproduce: ------------------- 1. Create a product with a tax (e.g. 15%). 2. Create a pricelist that changes the price (e.g. 100 to 200). 3. Create a fiscal position mapping the tax (e.g.…
Steps to reproduce: ------------------- 1. Create a product with a tax (e.g. 15%). 2. Create a pricelist that changes the price (e.g. 100 to 200). 3. Create a fiscal position mapping the tax (e.g. 15% to 30%). 4. Add the pricelist and the fiscal position in PoS. 5. Add the product to the cart, and select the tax and the pricelist created in the previous steps. 6. Long press on the product to see its info. The price should be 200 now after selecting the pricelist. Also the tax should be 30% bc of the FP mapping, i.e. total price should be 200 + 30% = 260. However, we observe that VAT shows 15 (15%) instead of 60 (30%), and Price incl. Tax shows 230 instead of 260. What's happening: ----------------- On the frontend, `getTaxDetails()` is called with no options, so it uses the product `list_price` (100) and `taxes_id` (15%), giving VAT = 15. Alos, on the backned, `self.taxes_id` is used directly to compute the taxes, even though the pricelist price is correct (200), fiscal position is ignored, hence 200 + 15% = 230 instead of 200 + 30% = 260. The fix: -------- On frontend, we pass the pricelist and fiscal position to `getTaxDetails`, and compute the tax name from the mapped taxes. On the backend, we read the `fiscal_position_id` from the context and apply the tax mapping, so the correct taxes are used. opw-6200632 Forward-Port-Of: odoo/odoo#266012
This update resolves an issue where disconnecting and reconnecting serial devices caused temporary disruptions in Odoo's device discovery process. The fix ensures that stale connections are properly closed, preventing deadlocks and allowing devices to reconnect smoothly. This improves the reliability of the IoT device integration.
Original PR description
Quick disconnects/reconnects of serial devices crash the serial driver thread, leaving "ghost" processes that cause deadlocks. It's way faster than the main 3s discovery loop, leading to the interface not seeing the device left then came back. This fix adds a health check to SerialInterface.get_devices(): if a driver thread is dead, it is excluded from the discovery list. This triggers Odoo's native removal flow to cleanly shut down the stale connection, allowing the device to auto-recover on the next poll cycle. opw-6201161, opw-6122057 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271326
This update fixes a scheduling issue in manufacturing order planning where operations with dependencies were not always processed in the correct order. The change ensures that operations are planned based on their dependencies, preventing delays and improving production efficiency. It addresses a bug related to recursive planning that caused operations to be scheduled incorrectly.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe Steps to reproduce the bug: - Create a product with a BoM with operation dependencies enabled - Add 4…
Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe
Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
- opA: no blocker
- opB: blocked by opA
- opC: blocked by opA
- opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan
Problem:
opA was scheduled after opB, violating the dependency.
`_plan_workorders` starts planning from the "leaf" workorders (those with no dependents). Given the structure above, the initial set is [opB, opD]. Processing opB first correctly plans opA then opB. But processing opD triggers a recursive chain opD→opC→opA which calls `action_unplan(opA)` and replans it from scratch. By then, opB already occupies the workcenter slot that opA originally held, so opA ends up scheduled after opB.
Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.
opw-6299179This update adds a new setting to our spreadsheet tests that allows us to bypass waiting for data to fully load. Previously, tests would fail if the spreadsheet data wasn't immediately available. This change ensures tests run reliably and accurately reflect the spreadsheet's behavior, especially when data is being prepared.
Original PR description
Added the parameter `skipWaitForDataLoaded` to `createSpreadsheetWithList` to test what happens when the list is not ready yet. Task: [6289944](https://www.odoo.com/odoo/2328/tasks/6289944) 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#271144 Forward-Port-Of: odoo/odoo#269096
This update resolves an issue where tooltips in the list autofill feature were displaying error messages instead of the correct information. The fix ensures that tooltips accurately reflect the list's data when it's ready, improving the user experience. This was part of a larger effort to enhance the reliability of the Odoo Enterprise application.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#121228 Forward-Port-Of: odoo/enterprise#119876
This update resolves a problem where Italian fiscal printers would intermittently stop printing POS orders due to unsupported characters in product or payment method names. The fix replaces these characters with spaces, following official EPSON documentation to ensure proper printing functionality. This prevents incomplete order prints and improves the POS experience for Italian users.
Original PR description
Steps to reproduce: - Setup an Italian fiscal printer - Modify the name of a product to use the non-blocking space character "\ "; - In the POS, create an order with the product. Error: the fiscal device will stop midway in the printing process and return an incomplete response to the frontend. The issue can also be reproduce if the character is included in the payment method name or the POS config name. Solution: When formating the xml command, replace all non-supported character by a space character. The non-supported character list is provided by the official [EPSON fiscal printer documentation](https://support.epson.net/setupnavi/?PINF=bsmanual&OSC=WS&LG2=EN&MKN=FP-90III%20RT) in the document "ePOS Fiscal Print Solution Development Guide". Other: Rename the file "dispaly_text.xml" to "display_text.xml". [opw-6244089](https://www.odoo.com/odoo/project/49/tasks/6244089) Forward-Port-Of: odoo/enterprise#121248 Forward-Port-Of: odoo/enterprise#120169
This update fixes a performance issue within the Odoo gevent server by proactively loading database registries. Previously, the server wasn't properly configuring these registries, leading to slower startup times. This change ensures optimal performance and responsiveness of the Odoo SaaS platform.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
This update corrects a display issue in the rental product configurator, ensuring the rental price is correctly formatted with a slash separating it from the rental duration. Previously, the price and duration were shown without this crucial separator, leading to an unclear presentation. This fix improves the user experience and accuracy of rental product information.
Original PR description
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product…
Steps to produce: --- - Install the `Rental and eCommerce `modules. - Create a rental product and configure a rental price for it. - Add an optional product from the Sales tab. - Publish the product on the website. - Open the product page on the website and click` Add to Cart`. Issue: --- - In the product configurator, the rental price is displayed without the `/` separator between the price and the rental duration period. Cause: --- - The string used to generate the rental duration label does not include the `/` separator. Fix: --- - Add the missing `/` separator to the rental duration label so that rental prices are displayed correctly. Before: --- <img width="974" height="185" alt="image" src="https://github.com/user-attachments/assets/64a88a60-bcc0-4657-97fd-584da57d0aff" /> After: --- <img width="967" height="188" alt="image" src="https://github.com/user-attachments/assets/b4d50019-1db4-4817-a8ce-446cc3c55df4" /> opw-6293015 Forward-Port-Of: odoo/enterprise#121246 Forward-Port-Of: odoo/enterprise#120223
This update fixes a visual inconsistency within the Odoo system. The flag image for Mauritania was incorrectly displayed. This change ensures accurate representation of countries within the system, maintaining a professional and reliable user experience.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
This update ensures Odoo generates PDF invoices that fully comply with ZUGFeRD standards, a crucial requirement for accurate electronic invoicing. Specifically, the PDF now correctly identifies the relationship between the embedded XML data and the visual invoice, and the XML filename has been updated for compatibility with the latest ZUGFeRD version.
Original PR description
Adapt `add_attachment` to allow setting the "AFRelationship" tag on the PDF filespec object, In compliance with Factur-X/ZUGFeRD specs that require the AFRelationship tag in the PDF filespec object to reflect the relationship between the embedded XML and the visual PDF content: - /Data: the visual PDF contains more invoicing data than the XML. - /Alternative: the XML and the PDF are two equivalent representations of the same invoice. Additionally, update the embedded XML filename from `zugferd-invoice.xml` to `factur-x.xml`. The former is marked as deprecated since ZUGFeRD 2.0 Ref: sections 6.2.2, 6.3.1, 6.3.2 of the ZUGFeRD 2.4 specification: https://www.ferd-net.de/en/downloads/publications/details/zugferd-24-english opw-6252082 Forward-Port-Of: odoo/odoo#271406 Forward-Port-Of: odoo/odoo#269117
This update resolves an issue where users without fleet access were unable to import UBL invoices referencing vehicles. The fix now allows users with vendor bill import permissions to successfully import UBL invoices containing vehicle references, improving data import flexibility. This ensures accurate record-keeping regardless of user access rights.
Original PR description
When a user has no rights to access the fleet models but is allowed to import vendor bills, he should be able to import a bill (UBL) with referenced vehicle(s) inside. task-6289956
This update corrects a bug in the SEPA Direct Debit testing process. The test was failing because the payment status was incorrectly transitioning between 'paid' and 'reconciled'. The fix ensures the payment is always in the 'paid' state before validation, preventing the error and improving test reliability.
Original PR description
The `test_expiry` test creates a payment via the `pay_with_mandate` method. Depending on eg. the installed modules, the resulting payment ends up either `paid` or `reconciled`. Afterwards, the test tries to validate the payment, which requires that it not be in the `reconciled` state. This causes an error linked below. This PR adds a condition to ensure the payment is in the `paid` state before attempting to validate it. Error: https://runbot.odoo.com/odoo/error/240557
A technical issue preventing the creation of opportunity buttons on the website was resolved. The fix corrects a problem caused by recent code changes that incorrectly called a function for creating HTML elements. This ensures that users can now consistently access the opportunity creation feature.
Original PR description
**Steps to reproduce:** - Install CRM app with website_crm_partner_assign - Go to the current user contact page > Partner Assignment - Set its partner level (e.g. Gold) - Go the `/my/opportunities` url of the website - Create opportunity button should be available - On click an error is raised: `TypeError: this.el.createElement is not a function` **Issue:** `createElement` is a method of `Document`, but it's called from a dom element after some `Interactions` refactoring. **Fix:** Properly call the method like before. related: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba opw-6267473 Forward-Port-Of: odoo/odoo#268036
A recent update (19.2) caused a test to fail when only the HR holiday Gantt chart module was installed. The issue stemmed from a payroll-related field within the test's configuration. This fix resolves the test failure and ensures the module's functionality remains stable.
Original PR description
__ ## Error description When the test runs with only the module `hr_holidays_gantt` installed, it fails. ## Origin of the issue There's a payroll related field in the `read_specification` variable. ### Note The error is only triggered since 19.2. __ original commit: https://github.com/odoo/odoo/pull/256636
This update fixes an issue where a specific configuration setting, 'bin_path', wasn't being saved correctly when updating configuration files. Previously, changes made directly to a configuration file weren't reflected after using the '--save' command. This ensures that all configuration settings, especially those not present in the core system, are reliably saved across updates.
Original PR description
Have a configuration file with a "bin_path" entry. Use that config file and --save it. The "bin_path" entry is removed from the new config file, it should had been persisted. The problem is common to all "undocumented options", options that did not exist in `config.py` before ConfigCleaner(7) and that were not created upon --save. We can argue about creating or not those options upon --save with the default config, but what's sure is that when the option be set in the config file, then it must be persisted across saves. Task-6106771 Reference-to: 80007415d621 ([REF] core: ConfigCleaner(7) remove deprecated options) 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#270191 Forward-Port-Of: odoo/odoo#258377
This update resolves a bug that caused the Website Studio form builder to crash when switching between different model types via the 'More models' option. The fix ensures both the current and newly selected models are retained in the system's memory, preventing errors and improving the user experience.
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878 Forward-Port-Of: odoo/enterprise#121492
This update removes an unnecessary 'external' tag from a key delivery module component. Previously, errors related to this component were only caught during nightly testing, leading to delayed detection. Fixing this tag requires updating some tests to ensure accurate and consistent monitoring.
Original PR description
Test class was tagged as external although calls are mocked. This means errors were only caught in nightly and not by CI. Removing the tag requires fixing some of the tests. For `test_multicollo`, we send the average weight of packages instead of the total since 97f82442c9fee7dcb3e8c5e9bacddcd6bb864e11. Forward-Port-Of: odoo/enterprise#121404 Forward-Port-Of: odoo/enterprise#111660
This update fixes an issue where long customer addresses in the Field Service kanban view would be cut off and displayed incorrectly. The change adjusts the layout to ensure addresses fit neatly within the kanban card, improving the user experience and readability of customer information. This ensures a cleaner and more professional appearance.
Original PR description
Steps to reproduce: - 1. Open the Field Service planning view in kanban. 2. Make sure a shift's customer has a long address (long street lines). 3. Look at that shift's card in the kanban view. Issue: - The customer address overflows the card and is clipped at its right edge instead of staying within the card boundaries. Cause: - The customer is rendered with the `many2one` widget and `show_address`, which marks each address line `text-truncate`. Truncation only works inside a width-bounded container, but the field root `.o_field_many2one` is an inline-flex item with the default `min-width: auto`, so it grows to fit the longest address line instead of shrinking to the card. As a result, `text-truncate` never engages and the address spills past the card. Fix: - Add the `min-w-0` class to the partner field so the flex item shrinks to the available card width. task-6272209
14 changes
Resolved issues and error corrections
This update fixes a minor issue where changes to many-to-many tag fields didn't automatically update related data in the main form view. Now, when users edit tags within a form dialog, the system correctly recomputes dependent fields, ensuring data consistency and a smoother user experience. This improves the reliability of form calculations.
Original PR description
Since [1], one can setup many2many_tags fields to allow editing tags in a form view dialog when clicking on them. However, it may happen that the main record/form view contains computed fields that depend on fields of the edited tag, and that must be recomputed when the user saves the dialog. This works fine of many2one fields, as we trigger an onchange after the save. However, before this commit, we did not trigger the onchange in the m2m case. Now we do. [1] https://github.com/odoo/odoo/pull/234280 Issue reported in the Framework JS discord channel. Issue spotted in task~6088824 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the MZ demo company setup. Previously, the demo company lacked a valid NUIT number, causing issues with testing and compliance. This fix ensures the demo company now adheres to the required NUIT number format, improving the accuracy and reliability of the MZ localization demo.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
This update resolves an issue where disconnecting and reconnecting serial devices caused temporary disruptions in Odoo's device discovery process. The fix ensures Odoo properly handles device connections and disconnections, preventing 'ghost' processes and improving the reliability of serial device integration. This enhances the overall stability of the system.
Original PR description
Quick disconnects/reconnects of serial devices crash the serial driver thread, leaving "ghost" processes that cause deadlocks. It's way faster than the main 3s discovery loop, leading to the interface not seeing the device left then came back. This fix adds a health check to SerialInterface.get_devices(): if a driver thread is dead, it is excluded from the discovery list. This triggers Odoo's native removal flow to cleanly shut down the stale connection, allowing the device to auto-recover on the next poll cycle. opw-6201161, opw-6122057 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271326
This update resolves an issue where event titles were being saved as "(no title)" when users quickly saved events using the Alt+C shortcut. The fix utilizes a framework mechanism to ensure all field data is committed at save time, preventing the default blank title from being applied.
Original PR description
When creating an event using the quick create form from the calendar view if the user saves the record while the title is still being edited (using alt+c) the record will be saved with the default title: "(no title)" The code currently relies on the record data being up to date by the time onRecordSave is reached. However in the case of a text field, it is only saved when blurred. While there is a mechanism to blur the field when saving using a hotkey, it is completely asynchronous from the save logic of the form. To ensure all fields have comitted their data at save time, the framework has a mechanism to "request changes" which notifies all fields to update the record with their latest value and waits for them to do so. We can simply reuse this mechanism to ensure the data is up to date at recordSave time already, as we don't expect fields to have any changes after it. task-6321702
This update adds a new setting to our spreadsheet tests that allows them to bypass waiting for data to fully load. Previously, tests were blocked if the spreadsheet data wasn't immediately available, which could cause delays. Now, tests can be run faster and more reliably by skipping this data loading check.
Original PR description
Added the parameter `skipWaitForDataLoaded` to `createSpreadsheetWithList` to test what happens when the list is not ready yet. Task: [6289944](https://www.odoo.com/odoo/2328/tasks/6289944) 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#271144 Forward-Port-Of: odoo/odoo#269096
This update resolves an issue where the spreadsheet edition's autofill tooltips displayed error messages instead of the correct information when the list data wasn't immediately available. The fix ensures tooltips show the intended data, improving the user experience and data accuracy within the spreadsheet feature. This was part of a larger effort to improve stability and reliability.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#121228 Forward-Port-Of: odoo/enterprise#119876
This update fixes an issue where inserting mentions in the email composer caused text editing to behave unexpectedly. Specifically, it adds a special character to ensure the cursor moves to the correct end of the line when typing, improving the user's ability to format emails. This ensures a smoother and more accurate email composition experience.
Original PR description
### Purpose of this PR: - Inserting a mention in the composer results in a paragraph ending with a bare `<a>` element and no trailing text node. This causes the browser to mishandle the End key, moving the caret to the start of the next paragraph instead of the end of the current line. - Fix by appending a \uFEFF (zero-width no-break space) text node. task-6295924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271160 Forward-Port-Of: odoo/odoo#269699
This update fixes a minor visual issue where the flag for Mauritania was incorrectly displayed in the system. The change ensures accurate representation of the country flag, maintaining a consistent and professional user experience. This is a simple correction with no impact on core functionality.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
This update ensures Odoo's server processes efficiently load necessary data, leading to faster response times. Previously, the server wasn't properly preparing data for use, causing delays. This fix optimizes the server's startup and performance.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
This update ensures Odoo generates PDF invoices that fully comply with ZUGFeRD standards, a crucial requirement for electronic invoice processing. Specifically, the PDF files now correctly identify the relationship between the underlying XML data and the visual invoice, addressing a technical detail related to invoice formatting. This update also updates the XML filename to align with current ZUGFeRD specifications.
Original PR description
Adapt `add_attachment` to allow setting the "AFRelationship" tag on the PDF filespec object, In compliance with Factur-X/ZUGFeRD specs that require the AFRelationship tag in the PDF filespec object to reflect the relationship between the embedded XML and the visual PDF content: - /Data: the visual PDF contains more invoicing data than the XML. - /Alternative: the XML and the PDF are two equivalent representations of the same invoice. Additionally, update the embedded XML filename from `zugferd-invoice.xml` to `factur-x.xml`. The former is marked as deprecated since ZUGFeRD 2.0 Ref: sections 6.2.2, 6.3.1, 6.3.2 of the ZUGFeRD 2.4 specification: https://www.ferd-net.de/en/downloads/publications/details/zugferd-24-english opw-6252082 Forward-Port-Of: odoo/odoo#271406 Forward-Port-Of: odoo/odoo#269117
A technical issue preventing users from creating opportunities on the website was resolved. The fix corrects a problem caused by recent code changes that incorrectly called a function needed to create elements on the page. This ensures the opportunity creation button is consistently available for users.
Original PR description
**Steps to reproduce:** - Install CRM app with website_crm_partner_assign - Go to the current user contact page > Partner Assignment - Set its partner level (e.g. Gold) - Go the `/my/opportunities` url of the website - Create opportunity button should be available - On click an error is raised: `TypeError: this.el.createElement is not a function` **Issue:** `createElement` is a method of `Document`, but it's called from a dom element after some `Interactions` refactoring. **Fix:** Properly call the method like before. related: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba opw-6267473 Forward-Port-Of: odoo/odoo#268036
This update resolves a potential issue where spreadsheet tests could unexpectedly fail due to unhandled asynchronous operations. By adding `await` to test operations, the system is now more stable and reliable, preventing cascading test failures. This ensures consistent and predictable test results.
Original PR description
Some tests did a `model.exportXLSX()` to verify it didn't crash, but did not `await` so a crash would break another test at random. Task: [6328937](https://www.odoo.com/web#id=6328937&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where switching between models within the website studio's 'More models' feature caused a crash. The fix ensures both the current and newly selected models are retained in the system's memory, preventing errors and improving the overall stability of form switching. This enhances the user experience for managing multiple forms.
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878 Forward-Port-Of: odoo/enterprise#121492
This update resolves an issue where the due date calculation for French payroll was inaccurate, particularly in November. It also corrects a technical error that prevented the system from properly processing certain records. These changes ensure accurate reporting and data processing for French businesses using this module.
Original PR description
- Fix due date calculation (returned month 0 if move date was in November) - Fix ensure_one error, avoid calling _deduce_country_code() on an empty recordset opw-6293701 Forward-Port-Of: odoo/odoo#270148 Forward-Port-Of: odoo/odoo#270003
3 changes
Resolved issues and error corrections
This update prevents an error that occurred when the 'Company Car (To order)' option was enabled in the salary configurator. The fix ensures that a car model is selected before attempting to extract data, resolving a technical issue that previously blocked users from configuring this option. This ensures the salary configurator functions correctly for all users.
Original PR description
## Steps to Reproduce: (v18.0) 1. Install `l10n_be_hr_contract_salary` without demo data. 2. Create a Belgian company and switch to it. 3. Create an employee. 4. Create a contract for the employee. 5. Click Generate Offer and open the Salary Configurator. 6. Enable the 'Company Car (To order)' option. ## Error: `AttributeError: 'NoneType' object has no attribute 'split'` ## Cause: When the salary configurator is used without demo data, no car model is selected. The method assumes that select_wishlist_car_total_depreciated_cost always contains a value and directly calls split() on it, resulting in an error, when the field is None. ## Fix: This commit checks that both the company car option is enabled and a car model has been selected before trying to extract the model ID. sentry-7554712017 Forward-Port-Of: odoo/enterprise#121138
This update fixes an issue where the spreadsheet edition's autofill tooltips would display error messages instead of the correct data when the list was not yet loaded. The fix ensures tooltips display the intended information reliably, improving the user experience. This was part of a larger effort to enhance stability and usability.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#121228 Forward-Port-Of: odoo/enterprise#119876
This update resolves an issue where users were encountering access rights errors when accessing certain fields within the AI module. The fix ensures all field fetches are handled with error catching, preventing errors related to restricted fields and improving AI functionality. This improves the reliability of the AI features.
Original PR description
Prior to this fix, when accessing some fields to add to the ai context, we would get an access rights error bubble up to the user. The original intention was for the code to fetch all fields for a record, catch access rights errors and if one was caught skip the field from the context. For some reason though, the try-catch was only added around where we are handling the values of relational fields and not when fetching the value of all the fields. That meant that for reguluar fields which are computed using a restricted field, the access rights error would not get caught and bubble up to the user. In this commit we add the regular field accessing inside the try-catch. Task-5948687 Forward-Port-Of: odoo/enterprise#107799
11 changes
Resolved issues and error corrections
This update resolves an issue where foreign currency vendor bills were incorrectly flagged as 'Partially matched' during GSTR-2B reporting. The fix ensures accurate reconciliation by comparing amounts in the company's base currency (INR) regardless of the bill's original currency.
Original PR description
**Steps to reproduce:** * Install the **l10n_in_reports** module. * Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**. * Activate a foreign currency (e.g., USD) and set…
**Steps to reproduce:** * Install the **l10n_in_reports** module. * Go to **Accounting → Configuration → Settings**, and enable **Multi-Currencies**. * Activate a foreign currency (e.g., USD) and set an exchange rate. * Create a new vendor bill for an Indian vendor, setting the currency to USD. * Add lines to the bill and apply IGST/GST taxes, then confirm the bill. * Go to **Accounting → Reporting → GST Return Period** and initiate GSTR-2B matching for the period corresponding to the bill (using a valid JSON payload where the amounts are correctly reported in INR). **Observed behavior:** * The vendor bill is incorrectly marked as "Partially matched" instead of "Fully matched", accompanied by an exception stating that the total amount as per GSTR-2B does not match. **Cause:** * The GSTR-2B data fetched from the GST portal always reports values in the company's base currency (INR). * The `match_bills` method was directly comparing the GSTR-2B INR amounts ( `bill_total` and `bill_taxable_value`) against the bill's `amount_total` and `amount_untaxed` fields. * Because these fields return values in the document's foreign currency (e.g., USD), the mismatch triggers an exception and flags the bill as partially matched. **Fix:** * Modified the matching logic to compare GSTR-2B values against `abs(amount_total_signed)` and `abs(amount_untaxed_signed)`. * This ensures that the amounts evaluated during reconciliation are always correctly converted and compared in the company's base currency (INR). opw-6311097 Forward-Port-Of: odoo/enterprise#121512 Forward-Port-Of: odoo/enterprise#120967
The Time Off Balance report was incorrectly calculating remaining days when overlapping allocations existed. This fix ensures the report accurately reflects the remaining time off by correctly deducting leaves from overlapping allocations. This improves the accuracy of time off tracking for employees.
Original PR description
The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one. ### **Steps to reproduce:** 1) Install time off app. 2) Create a…
The Time Off Balance report shows incorrect remaining days when overlapping allocations exist and a leave only overlaps the later one. ### **Steps to reproduce:** 1) Install time off app. 2) Create a simple time off type. - Create Allocation A (10 days, 01-01-2024 to 31-12-2025) - Create Allocation B (10 days, 01-01-2025 to 31-12-2026) 3) Create a leave of 1 day on 01-01-2026 4) Open the Balance report ### **Observed Behavior:** The report shows 20 remaining days. ### **Expected Behavior:** The report should show 19 remaining days (20 allocated - 1 taken). ### **Cause:** In the taken_per_allocation CTE at [1], each leave is joined to every allocation it overlaps. The [fifo_balances] CTE then uses the formula: ``` GREATEST(alloc_days - GREATEST(taken - prior_cumulative_alloc, 0), 0) ``` This subtracts the prior allocation capacity (A = 10 days) from the taken count (B = 1 day). Since 1 - 10 = -9, GREATEST(-9, 0) = 0, so zero days are deducted from B. The formula wrongly assumes that prior allocations can absorb leaves that do not overlap with them. [1]- https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L126-L142 [fifo_balances]: https://github.com/odoo/odoo/blob/f0fa79fa21d2005dd5cd132c18b2be45424166a6/addons/hr_holidays/report/hr_leave_employee_type_report.py#L145-L164 ### **Fix:** Ensure that leaves are only deducted from allocations they actually overlap by calculating the balance using the delta of cumulative leaves within an overlap group. This prevents earlier allocations from absorbing leaves that occur outside their validity period. **opw-6150161** Forward-Port-Of: odoo/odoo#271596 Forward-Port-Of: odoo/odoo#263029
This update corrects a missing valid NUIT number in the MZ demo company setup. The change ensures the demo company accurately reflects MZ tax requirements, preventing potential errors during testing and demonstration of the l10n_mz module. This resolves a Runbot error related to data validation.
Original PR description
Newer versions of stdnum (2.2) also test the number for MZ We did not have a valid NUIT number in the MZ demo company. Runbot error: https://runbot.odoo.com/runbot/build/114118067 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#271398 Forward-Port-Of: odoo/odoo#271299
This update resolves an issue where outdated map cluster bubbles remained visible after zooming or panning on the customer map. The fix corrects a technical error that prevented the removal of these icons, ensuring the map displays accurately and efficiently. This improves the user experience by eliminating visual clutter.
Original PR description
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times…
Steps to reproduce: =================== 1. Install website_customer, set a Google Maps API key and publish a few companies with coordinates 2. Open /customers 3. Open the map and zoom in a few times => stale blue cluster bubbles remain on the map Cause: ====== On the partner map, zooming or panning left old cluster bubbles behind: the blue count icons piled up and never disappeared, even at the closest zoom level. `ClusterIcon` is meant to be a google.maps.OverlayView. The bundled `markerclusterer.js` wires that up by copying every enumerable https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L213-L221 OverlayView.prototype member onto ClusterIcon.prototype. Google Maps now ships its own OverlayView.prototype.remove, and that copy overwrites ClusterIcon's own `remove()` with it, As a result, when a cluster icon is removed, `ClusterIcon.remove()` is never executed. Consequently, `ClusterIcon.prototype.onRemove()` is not triggered, the cluster icon's DOM element is never detached from the map, https://github.com/odoo/odoo/blob/aed1619c34b1f65bd9a3d155fe76a82d404ef5e7/addons/website_google_map/static/src/lib/markerclusterer.js#L1167 and stale cluster bubbles accumulate after every redraw, zoom, or pan operation. Solution: ========= Inherit from OverlayView through the prototype chain instead of copying it, so ClusterIcon's own remove() is kept and actually detaches the icon. opw-6128531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270733
This update resolves an issue where the sale stock module installation would fail due to a warehouse constraint warning. The fix ensures that the installation process continues smoothly even when a company initially lacks a defined warehouse, preventing unnecessary installation interruptions.
Original PR description
Steps to reproduce the bug:
- Have a database with sale_management installed and at least two companies (Company 1 and Company 2)
- Confirm sale orders with storable products under each company
- Install the stock module (which triggers sale_stock as a bridge module)
Problem:
The installation raised a RedirectWarning ("Please create a warehouse for company 2") and aborted. During sale_stock installation, _init_column initialises the new `warehouse_id` column on `sale.order` via SQL. Orders belonging to companies that have no warehouse yet (company 2, since `create_missing_warehouse` only creates one for the first company at that point) remain NULL. The stored-field recompute then calls write(), which fires _check_warehouse. That constraint calls _warehouse_redirect_warning() for each company without a warehouse, raising a RedirectWarning that aborts the install.
opw-6302537
Forward-Port-Of: odoo/odoo#270480This update adds a new option to our spreadsheet tests that allows them to bypass waiting for data to fully load. Previously, tests were slower because they had to wait for the spreadsheet data to be ready. This change speeds up testing and ensures more reliable results.
Original PR description
Added the parameter `skipWaitForDataLoaded` to `createSpreadsheetWithList` to test what happens when the list is not ready yet. Task: [6289944](https://www.odoo.com/odoo/2328/tasks/6289944) 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#271144 Forward-Port-Of: odoo/odoo#269096
This update resolves an issue where the spreadsheet autofill feature displayed error messages in tooltips when lists were not yet fully loaded. The fix ensures that tooltips now display the correct information, improving the user experience and preventing misleading notifications. This was part of a larger effort to improve the stability of the spreadsheet edition.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#121228 Forward-Port-Of: odoo/enterprise#119876
This update ensures Odoo's SaaS environment efficiently loads databases, leading to faster startup times and improved overall performance. The change addresses a previous oversight where database registries weren't properly initialized, and now preloads them directly within the gevent server. This optimization enhances the user experience for Odoo SaaS customers.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
This update fixes a visual inconsistency within the Odoo system. The flag image for Mauritania was incorrectly displayed. This change ensures accurate representation of countries within the system, improving the overall user experience and data integrity.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
A minor bug preventing the creation of opportunities from the user's dashboard has been fixed. This update corrects an error related to how the website's CRM functionality was being built, ensuring that users can now successfully create opportunities after assigning partners.
Original PR description
**Steps to reproduce:** - Install CRM app with website_crm_partner_assign - Go to the current user contact page > Partner Assignment - Set its partner level (e.g. Gold) - Go the `/my/opportunities` url of the website - Create opportunity button should be available - On click an error is raised: `TypeError: this.el.createElement is not a function` **Issue:** `createElement` is a method of `Document`, but it's called from a dom element after some `Interactions` refactoring. **Fix:** Properly call the method like before. related: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba opw-6267473 Forward-Port-Of: odoo/odoo#268036
This update resolves a technical issue preventing the Spanish EDI (Verifactu) module from functioning correctly during upgrades. The module was missing a key dependency on the 'certificate' module, causing a startup error. This fix ensures the module loads correctly and avoids upgrade problems.
Original PR description
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to…
### Issue `l10n_es_edi_verifactu` builds an inheritance on `certificate.certificate` and loads that module's views/demo, but only declares `depends: ['l10n_es']`. With `certificate` not guaranteed to load first, building the registry without it already present raises: ``` TypeError: Model 'certificate.certificate' does not exist in registry. ``` ### Cause `models/certificate.py` → `_inherit = 'certificate.certificate'`; manifest `data` loads `views/certificate_certificate_views.xml` and `demo/demo_certificate.xml`. Yet `certificate` is absent from `depends`. Every sibling (`l10n_es_edi_facturae`/`sii`/`tbai`, `l10n_sa_edi`) already depends on `certificate`. Present since the module was added in `02f8d5525eb7`. ### Notes - Opened on **18.0** so it **forward-ports to 19.0** (both stable branches carry the bug). `master` already has the equivalent change via #234729 — the forward-port there should be a no-op. - Surfaced via an 18.0→19.0 OpenUpgrade migration that force-updates `verifactu` before `certificate` loads; also reproducible on a plain install where `certificate` isn't otherwise pulled in first. Forward-Port-Of: odoo/odoo#271496
1 change
Resolved issues and error corrections
This update corrects a bug where quality checks remained active after merging Manufacturing Orders. Previously, the merge process didn't trigger the standard cleanup, leading to outdated quality check statuses. Now, quality checks are properly removed when Manufacturing Orders are merged, streamlining the workflow and removing unnecessary indicators.
Original PR description
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that…
Version: -------- - 18.0+ Steps to reproduce: ------------------- - Install `quality_mrp` - Create a manufactured product with a BoM - Create a Quality Point for the `Manufacturing` operation of that product - Create and confirm multiple Manufacturing Orders - Verify that each MO generates a quality check - From the MO list view, select the MOs and merge them from the gear menu(merge) Issue: ------ When Manufacturing Orders are merged, All MOs are cancelled but it keep their quality checks in the 'To Do' state. As a result: - The quality checks remain linked to cancelled MOs - The 'Quality Checks' smart button is still displayed on cancelled MOs Expected behavior: ------------------ - Pending quality checks should be deleted when the MO is cancelled - The 'Quality Checks' smart button should no longer be displayed Cause: ------ A previous fix introduced logic to remove pending quality checks when a Manufacturing Order is cancelled: odoo-dev@db93bd2 This logic was implemented in `action_cancel()` by unlinking quality checks associated with the cancelled MO: https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97 However, when MOs are merged, the merge flow does not call `action_cancel()`. Instead, it directly invokes `_action_cancel()` on the source Manufacturing Orders: https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480 Since the quality check cleanup is implemented only in `action_cancel()`, it is bypassed during the merge process. As a result, the source MOs are cancelled but their pending quality checks remain in place. --- opw-6260735 Forward-Port-Of: odoo/enterprise#119525
2 changes
Resolved issues and error corrections
This update streamlines the automatic onboarding tours within several Odoo modules (Helpdesk, Planning, Sale, Web Studio, and Knowledge) by removing unnecessary formatting wrappers. This fix resolves validation errors and ensures a smoother, more reliable onboarding experience for new users. The change also adds specific validation rules for onboarding tours.
Original PR description
…ntent
This update fixes an issue where report titles within Odoo Knowledge embeds were not consistently translated. The solution involves retrieving the report's name directly, streamlining the process and eliminating a previous fallback mechanism. This ensures accurate and localized report titles are displayed in Knowledge.
Original PR description
Problem: The title of the report is not translated properly in embeds in Knowledge. Considering how `data-embedded-props` are fed, I don't think we can directly feed the translated value that easily ? Possible solution: we have the report_id in options, we can just read the name ? Pro: we wouldn't even need to provide the report name in the first place (so that fallback thing is most likely useless). Cons: There's a bit of back-and-forth with the additional read. Should most likely be fixed in 19.0+ and not in master if we want to fix it. task-none (follow-up of discussion in https://github.com/odoo/enterprise/pull/120077#discussion_r3389814591)
5 changes
Resolved issues and error corrections
This update fixes an issue where non-recurring products were incorrectly included in recurring revenue (MRR/YRR) calculations within subscription reports. This ensured accurate reporting regardless of user-selected filters, preventing misleading revenue figures. The change improves the reliability of subscription performance data.
Original PR description
While investigating a support ticket, we noticed that in subscription reports, recurring revenue values (MRR and YRR) are implicitly calculated for non-recurring products. This doesn't cause a direct problem when using the default search domains applied in Subscription > Reporting > Subscription > Pivot view, because a "Recurring" filter is pre-applied. But if the end user removes said filter, they might accidentally fudge the MRR and YRR numbers because the non-recurring products will contributed to the relevant grouping sums. We fix this by adding a CASE clause to explicitly ignore non-recurring products when calculating the report field for MRR and YRR , i.e. only consider `t.recurring_invoice = TRUE`. OPW-6315091
This update resolves an issue where the tooltip for list autofill features displayed error messages instead of correct information when the list data wasn't yet available. The fix ensures that tooltips display the intended data, improving the user experience and preventing misleading notifications.
Original PR description
The getter `getTooltipListFormula` would return the result of `getListHeaderValue` as the content of the tooltip, but this returned a loading error instead of a string if the list was not ready yet. Task: [6289944](https://www.odoo.com/web#id=6289944&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#121228 Forward-Port-Of: odoo/enterprise#119876
This update corrects a technical error preventing ‘Require Signature’ options for UPS deliveries within the US and some other regions. The fix adjusts the UPS API request to correctly handle signature requirements and ensures proper accessorial scope is applied, resolving delivery errors. This ensures accurate shipping and rating functionality for UPS shipments.
Original PR description
## Issue When a user configures a UPS REST delivery method with **"Require Signature"** enabled, the integration fails during both rating and shipping for US domestic shipments (and certain other…
## Issue When a user configures a UPS REST delivery method with **"Require Signature"** enabled, the integration fails during both rating and shipping for US domestic shipments (and certain other origin-destination pairs). The UPS API rejects the payload with the following error: > `The requested accessory option is unavailable between the selected locations.` ## Cause / Root Analysis There are two distinct issues in the current `ups_request.py` implementation: **1. Invalid Accessorial Scope (Shipment vs. Package level)** The current code unconditionally applies the `DeliveryConfirmation` node to `ShipmentServiceOptions`. However, according to the UPS Delivery Confirmation Origin-Destination rules, US domestic, CA domestic, and PR-to-US shipments **must** apply this accessorial at the package level (`PackageServiceOptions`). Applying it at the shipment level causes the UPS API to immediately reject the request. **2. Invalid DCISType Code** In both the rating and shipping methods, the code injects `'DCISType': '1'`. According to the UPS REST API schema, `1` does not actually request a signature: > `1` - Unsupported > `2` - Delivery Confirmation Signature Required > `3` - Delivery Confirmation Adult Signature Required *References to current implementation:* * [Rating: ups_request.py#L277](https://github.com/odoo/enterprise/blob/6d85b729b96f18df1cb5ecc429b79d3b37671c1f/delivery_ups_rest/models/ups_request.py#L277) * [Shipping: ups_request.py#L394](https://github.com/odoo/enterprise/blob/6d85b729b96f18df1cb5ecc429b79d3b37671c1f/delivery_ups_rest/models/ups_request.py#L394) ## Expected Behavior & Fix This PR aligns the Odoo payload with the official UPS REST routing matrix: 1. Changed `DCISType` from `'1'` to `'2'` to correctly request the signature. 2. Introduced a `_get_signature_scope` helper method that evaluates the origin and destination country codes. 3. Dynamically injects `DeliveryConfirmation` into either `PackageServiceOptions` (P) or `ShipmentServiceOptions` (S) based on the exact routing rules specified by UPS. ## Potential Future Enhancements While this PR resolves the immediate API crash, there are two UX/functional improvements that would better align with real-world shipping workflows: 1. **Move/Mirror Signature Toggle to Order/Transfer Level:** Currently, `ups_require_signature` sits on the `delivery.carrier` method. In practice, shippers rarely use a dedicated shipping method just for signatures; they usually apply a signature requirement dynamically based on order value or contents. Allowing a "Signature Required" boolean directly on the `sale.order` or `stock.picking` would vastly improve usability. 2. **Configurable Signature Type:** This fix defaults to `DCISType: '2'` (Signature Required) to resolve the bug, but exposing a configuration option to select between Standard Signature (`2`) and Adult Signature Required (`3`) would fully round out the integration. ## References (UPS Official Documentation) * [UPS Shipping API Documentation](https://developer.ups.com/tag/Shipping?loc=en_US) * [UPS Shipping Appendix (Delivery Confirmation Pairs)](https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US) * [UPS Rating API Documentation](https://developer.ups.com/tag/Rating?loc=en_US) * [UPS Rating Appendix (Delivery Confirmation Pairs)](https://developer.ups.com/api/reference/rating/appendix?loc=en_US)
This update corrects an inconsistency in how completed document rights are managed within the Enterprise system. The change ensures that rights associated with finalized documents are accurately reflected, preventing potential access issues. This improves data integrity and reliability for document-related workflows.
This update resolves an issue in the website studio where switching between multiple form models through the 'More models' feature would cause a crash. The fix ensures both the original and newly selected models are retained in the system's memory, preventing data loss and improving stability.
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878 Forward-Port-Of: odoo/enterprise#121492
17 changes
Resolved issues and error corrections
This update resolves a technical issue that was causing performance problems when calculating accounting entries for French PDP (Point of Delivery) transactions. By removing unnecessary dependencies on company and partner information, the system now computes these entries more efficiently and reliably. This improves the overall stability and performance of the French PDP module.
Original PR description
- This removes dependency on account move fields to company : Build error 939448 - This removes dependency on account move fields to commercial_partner_id fields (avoid recompute all moves on partner info change)
This update resolves a performance issue in the HTML editor that occurred when handling complex content. The fix prevents a 'Maximum call stack size exceeded' error by efficiently processing large numbers of elements, resulting in faster page loading times. This enhancement ensures a smoother user experience when working with extensive HTML content.
Original PR description
For complex content, descendants(root) can return more than 100K elements. Using the spread operator expands all descendants into individual function arguments, which may exceed the JavaScript's argument limit and trigger a "Maximum call stack size exceeded" error. Replace with push() each node to the targetNodes. ||Before|After| |-|-|-| |getTargetNodes|Page Unresponsive|585 ms| Related ticket: opw-6303814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where work order durations were inaccurately calculated due to overlapping time entries. By filtering and merging productive and performance time, the system now provides a more precise duration for valuation purposes. Additionally, a fix was implemented to prevent timestamp issues during testing, ensuring accurate duration calculations.
Original PR description
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current…
[[FIX] mrp: calculate real duration excluding non-productive intervals](https://github.com/odoo/odoo/pull/248381/changes/fac6b2540a32a015f56085c2c27ba4281eb659cf) and deduplicating overlaps * Current Situation: Currently real duration is total duration of each time tracking which is not consistent with the time that use to calculate the cost for valuation , see https://github.com/odoo/odoo/pull/205154 .The real duration of a work order was incorrectly summing all time tracking entries regardless of their loss type, and using simple addition which double-counts overlapping intervals. * Solution: - Filter time entries to only 'productive' and 'performance' loss types, excluding 'availability' and 'quality' as they represent downtime/blocking time, not actual work duration. - Pool all productive and performance entries into a single Intervals call so that overlaps across both types are merged in one pass. Note: the enterprise17 implementation groups time entries by loss_type into separate buckets before calling Intervals, which means overlaps between 'productive' and 'performance' entries are not merged and get double-counted. Pooling both types together before the Intervals call avoids this. * This also fix: - Fix _set_duration to ensure newly created time entries start after the latest existing entry's end date. Without this, calling _set_duration twice in quick succession (e.g. in tests) produces two entries with overlapping timestamps, which Intervals correctly merges into one, causing the computed duration to be half the expected value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248381
This update resolves an issue where vendor bills auto-completed from purchase orders would sometimes create incorrect invoice line data, including mismatched tax information. The change ensures that invoice line data is consistently updated after auto-completion, maintaining accurate records between invoices and journal entries. This improves data integrity and reduces potential accounting errors.
Original PR description
When a vendor bill is imported and auto-completed from a purchase order, then invoice lines, taxes, fiscal position, and payment terms can change. Existing EPD dynamic lines that lose their epd_key are skipped by sync and keep stale tax tags and amounts, causing mismatches between Invoice Lines and Journal Items. This commit makes EPD sync include keyless existing EPD lines so they are rewritten or removed during dynamic recomputation after PO auto-complete. Journal items remain consistent with the final invoice lines, taxes, and early discount configuration. Ticket [link](https://www.odoo.com/odoo/project.task/6047505) opw-6047505 Forward-Port-Of: odoo/odoo#265539
This update fixes an error in the German accounting template (skr03) that was using incorrect account codes for cash discounts. The template has been updated with the correct codes, ensuring accurate financial reporting for German businesses using Odoo. This ensures compliance and proper accounting practices.
Original PR description
The default cash discout accounts referenced in the
German skr03 template used the wrong account codes.
The template has been updated with the right ones.
task-4915939
opw-4909059
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#271024This update fixes an error in the German (skr03) report template, ensuring it uses the correct account codes for cash discounts. This ensures accurate financial reporting and compliance for our German customers. The change was driven by a task and an operational priority.
Original PR description
The default cash discount accounts referenced in the German skr03 template used the wrong account codes. The template has been updated with the right ones. task-4915939 opw-4909059 Forward-Port-Of: odoo/enterprise#121180
This update corrects an issue where resetting bank entries could incorrectly flag e-reporting statuses as 'False'. The change ensures the status is accurately determined before being displayed, improving the reliability of reporting data. This resolves a potential discrepancy in e-reporting status calculations.
Original PR description
Resetting an out-of-scope bank entry to draft can recompute the e-reporting status to False. Skip that value before resolving the status label for the chatter message.
This update resolves a bug where the cursor would incorrectly snap to the end of a `<t>` block when deleting text within email templates. By removing `<t>` from a list of self-closing tags, the editor now correctly handles cursor placement, ensuring a smoother editing experience for users creating and modifying email templates.
Original PR description
## Problem:
`<t>` elements are classified as self-closing, even if they aren't used that way in a mail template. If you press backspace in the editor on some plain text that happens to be inside a `<t></t>` block, the editor would prevent the cursor from being placed back inside the block after merging because of `normalizeSelfClosingElement`. The result is the cursor being left on the outside edge of the block.
## Solution:
We will remove "T" from the list of self-closing tags.
## Steps to replicate (runbot v18):
1. Open an email template (Purchase: Purchase Order)
2. Place your cursor in some text inside a t-if element ('The receipt is expected for...'). Press backspace. Your cursor will snap to the end of the t-if block.
opw-6124284This update resolves an issue where property labels weren't appearing correctly after adding properties to a record. The fix ensures that the system waits for the update to complete before displaying the property labels, preventing a technical error. This improves the user experience when managing properties within Odoo.
Original PR description
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When…
Description of the issue/feature this PR addresses: This error occurs when a model has properties and a `computed` field or `onchange` method depends on them. `record.update()` is asynchronous. When an onchange or computed field is triggered, an additional request is sent to the server, increasing the time required to complete the update. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/model/relational_model/record.js#L1207-L1211 However, `PropertiesField` is rendered before the `update` is completed. See: https://github.com/odoo/odoo/blob/727fe7412bb37c1664106625e248264d2aab6809/addons/web/static/src/views/fields/properties/properties_field.js#L86 As a result, the property labels are not yet available and the following traceback is raised: `TypeError: Cannot read properties of undefined (reading 'getRootNode') ` After this commit, the update is awaited before rendering PropertiesField, ensuring that the property labels are available. **Steps to reproduce:** 1. Install the example module. [project_task_property.zip](https://github.com/user-attachments/files/29138424/project_task_property.zip) 2. Open or create a project task. 3. From the Action menu, click `Add Properties`. The error is raised. <img width="1520" height="956" alt="image" src="https://github.com/user-attachments/assets/a3051ddf-5af0-4d3a-8ff7-c3fb4f7a69d2" /> TT63331 @Tecnativa @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'undo' function in the planning module didn't correctly maintain allocated hours. The fix creates the necessary planning role directly within the test environment, ensuring a consistent and reliable undo operation. This prevents data inconsistencies and improves the accuracy of planning schedules.
Original PR description
Fix by creating the planning role directly within the test, making it self-contained. runbot error-939985
This update fixes an issue where URL autocomplete suggestions overflowed on mobile devices, creating a poor user experience. The fix adjusts the container's width to dynamically adapt to smaller screens, ensuring suggestions fit neatly within the viewport. This enhances usability for all users.
Original PR description
Step to reproduce: - Open Notes - Open the link popover - Type a URL in the URL input field Description of the issue/: - On mobile devices, URL autocomplete suggestions overflow the viewport. Cause: - The autocomplete suggestions container has a max-width of 600px. - On smaller screens, the container does not shrink to fit the available width, causing it to overflow the viewport. Solution: - Add width: 100% to the autocomplete suggestions container so it adapts to the available screen width on smaller devices while still respecting the existing max-width on larger screens. task-6201175
This update corrects a bug in the payroll system's attachment code matching process. The original code incorrectly used the 'in' operator, leading to unintended matches. Switching to '==' ensures accurate matching of attachment codes, preventing potential payroll errors.
Original PR description
Currently we have for deduction_codes, attachments in slip.salary_attachment_ids.grouped( lambda x: x.other_input_type_id.code ) salary_lines = slip.line_ids.filtered( lambda r: r.code in deduction_codes ) I believe the intent in the second line is to check either r.code is in deduction_codes. This assumes deduction codes is an array. the issue is that it is not an array. The return of "grouped" on the first line implies that deduction_code will always have a string that describe which is the deduction_code, and attachment_ids will be an array Now the bug happens on the comparison "in" on the second line. Since we are matching against a string, suposing we had 2 codes like TEST_CODE and TEST, both would match positively using "in" changing "in" to "==" will ensure we match codes properly opw-6206134
This update fixes a visual inconsistency within the Odoo application. The flag image for Mauritania was incorrectly displayed. This change ensures accurate representation of countries within the system, improving the overall user experience.
Original PR description
[task-6320443](https://www.odoo.com/odoo/project.task/6320443) Forward-Port-Of: odoo/odoo#271488
This update fixes a performance issue within the Odoo gevent server by proactively loading database registries. Previously, the server wasn't properly configuring these registries, leading to slower startup times. This change ensures the server is optimized for speed and efficiency.
Original PR description
The code to set the registry size was moved to `preload_registries`. The gevent server does not preload registries and thus does not set the registries size. Instead of moving the code again, we can preload registries in the gevent server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271640
This update fixes a potential issue where private tasks could be incorrectly set as parents for other tasks. This change ensures tasks remain properly organized and prevents confusion for users managing project workflows. It's a routine maintenance update to improve task management clarity.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#270795
This pull request reverses a recent update that removed standard views and fields from the l10n_fr_pdp module. This change was causing issues with upgrades and is being reverted to ensure continued compatibility and stability. A subsequent update will reintroduce the cleanup with inactive views and fields.
Original PR description
Revert commit 75aff8b7bea3 ([IMP] l10n_fr_pdp: move e-reporting details to chatter). The cleanup removed standard views and fields in stable, which is not upgrade-safe and breaks forward-port upgrade checks. A follow-up PR will reintroduce the cleanup while keeping the obsolete views and fields available but inactive.
This update corrects an issue where the ICS file generated for events didn't reflect the language currently selected on the website. Previously, it always used the backend language, causing confusion for users. This change ensures the ICS description aligns with the frontend language, matching expected behavior and Google Calendar integration.
Original PR description
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings. Make sure the default language is…
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings. Make sure the default language is different from the chosen backend language - Create an event - Go to the event's website page through the smart button - Switch the language of the frontend to one that is different from the backend - Translate (alter) the description for this language - Click on the outlook icon to download the ics Current Behavior: The ics will contain a description based on the backend's chosen language Expected Behavior: The ics will contain a description based on the website's chosen language at the time Clarification: The current behavior is confusing for users as they will expect the ics to match the description of the current webpage which is dependent on the frontend's selected language. This current behavior also contradicts the google calendar behavior which grabs the description based on the frontend's selected language. Also in Odoo 19+, this leads to a "bug" where if a user has a selected backend language that's not present in the website, then the ics will always contain the default description since the language is not present on the website. The only way to circumvent this bug would be to add the language to the website which shouldn't need to happen opw-6235320
6 changes
Resolved issues and error corrections
This change resolves an issue where SVG images uploaded by users without write access to system views were not displayed correctly. The fix ensures that SVG attachments are properly processed, preventing a technical error and ensuring knowledge articles display images as intended. This improves the user experience for adding and managing content.
Original PR description
__Current behavior before commit:__ When an SVG attachment is uploaded by a user that has no `write` access to `ir.ui.view`, its mimetype is set to `text/plain`[1] for security reasons (prevent XSS…
__Current behavior before commit:__ When an SVG attachment is uploaded by a user that has no `write` access to `ir.ui.view`, its mimetype is set to `text/plain`[1] for security reasons (prevent XSS attacks). Now because the mimetype is not in `SUPPORTED_IMAGE_MIMETYPES`, `image_src` will be set to `False`[2]. This results in a traceback when the frontend tries to call `startsWith` on `image_src`[3]. __Description of the fix:__ Add the mimetypes in `attachmentsDomain` so it only fetches the images (like it's done in the [overridden getter][4]). __Steps to reproduce the issue on runbot:__ - Make sure Marc Demo has not write access to `ir.ui.view` (remove him from the group **Website / Editor and Designer**) - Log in with Demo - Go to a knowledge article - Add a cover and upload an SVG image -> the image is not displayed - Click on **Replace cover** - Search for the name of the previous SVG file - `TypeError: attachment.image_src.startsWith is not a function` [1]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/odoo/addons/base/models/ir_attachment.py#L378 [2]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/addons/web_editor/models/ir_attachment.py#L41 [3]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/addons/web_editor/static/src/components/media_dialog/image_selector.js#L222 [4]: https://github.com/odoo/odoo/blob/70e8ac9c48b4e90/addons/web_editor/static/src/components/media_dialog/image_selector.js#L108 opw-4701372
This update resolves an issue where private tasks could be incorrectly designated as parent tasks. This change ensures that private tasks remain truly private and prevents confusion or unintended hierarchical relationships within project management. This improves data integrity and simplifies project organization.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141
This update strengthens the website's stock notification system by preventing unauthorized subscriptions for unavailable products and blocking users from subscribing using another user's email. This enhances security and protects against potential misuse of user accounts.
Original PR description
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This…
Description of the issue/feature this PR addresses: Currently, in the website_sale_stock module, there is no backend validation when subscribing to notifications for products without stock. This allows public users to potentially use emails that belong to registered accounts. Current behavior before PR: - Users could subscribe to stock notifications for products that don’t exist or cannot be added (no stock). - Public users could use emails already associated with registered accounts, allowing them to subscribe on behalf of another user. - No validation is enforced, leading to potential security issues. Desired behavior after PR is merged: - Adding a subscription for a non-existent or unavailable product raises a ValidationError. - Public users trying to subscribe with an email that belongs to a registered user receive an AccessError prompting them to sign in first. - Backend validation prevents misuse of registered user emails and improves security. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where GSTR-1 reports for SEZ invoices in foreign currencies incorrectly displayed invoice values in USD. Now, the reports accurately reflect the invoice value in the company's reporting currency (INR), ensuring accurate tax reporting for Indian businesses using Odoo Enterprise.
Original PR description
Currently, when generatign GSTR-1 return spreadshee, SEZ invoices issued in a foreign currency are exported with their totals in the foreign currency rather than the company currency (INR) Steps to reproduce: - Create a B2B SEZ invoice in foreign currency - Go to Accounting > Reporting > [India] GST Return periods - Generate the GSTR-1 report for the period Issue: In the resulting spreadsheet, the "Invoice Value" column takes the invoice total in USD rather then INR opw-6292913
An upgrade issue in the Italian tax reporting module (l10n_it) was resolved due to changes in report expression formulas. The upgrade process triggered a database constraint violation when attempting to update expressions, which was addressed by adding a migration script to remove outdated expressions before the upgrade.
Original PR description
Steps to reproduce: - Create a database with `l10n_it_reports` on a version before PR #264294 - Switch to current `17.0` - Upgrade module `l10n_it` - An error is raised Upgrading a database with `l10n_it_reports` installed raises an error if the database was created before that PR In that PR, we modified the formulas of several report expressions to use subformulas instead of simple aggregations. During upgrade, the ORM attempts to insert the updated expressions while the old ones still exist, violating the UNIQUE constraint on `(report_line_id, label)` in `account.report.expression` Only happens on upgrade, not on a fresh install. A migration script is added to delete the outdated expressions before the upgrade runs Ticket [link](https://www.odoo.com/odoo/project.task/6299385) opw-6299385
This update optimizes the process of forecasting stock information, specifically for large inventories. By removing an inefficient loop, the system now responds much faster when accessing manufacturing orders, leading to improved overall performance. This change reduces delays and enhances the responsiveness of the stock management system.
Original PR description
Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being…
Before this commit, database with large amounts of `stock.move` records could face slow downs when trying to access Manufacturing Orders. While this is partially due to very heavy computations being done, another factor was the use of a loop in `_compute_forecast_information`. This loop would iterate over a recordset of `stock.move` records and put them into a dictionary, sorted by location. As the size of the recordset grew, this loop would take longer and longer. Here, we remove this loop and instead use a built in method to speed things up. ## Benchmarks: |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |6,262 |0.13s |68 |0.12s |68 | |68,882 |0.60s |112 |0.58s |109 | |432,317 |5.49s |398 |3.68s |309 | |757,702 |15.33s |1,141 |5.79s |599 | [opw-6310415](https://www.odoo.com/odoo/action-6450/6310415?debug=assets)