Daily updates from Odoo
Wednesday, June 24, 2026
238 changes
13 changes
Resolved issues and error corrections
This update resolves an issue where the 'select all' (Ctrl+A) function in the website builder incorrectly included non-editable text. The fix ensures that the selection is limited to editable content, specifically elements with the `contenteditable` attribute, improving the user experience and preventing unwanted text inclusion.
Original PR description
*: website Commit d09c8fd428315b8c3bf08c43d55da50fcd77f2ae added a handler for `ctrl+a` to restrict the selection inside the closest `div`. But if the `div` element is outside `contenteditable=true`, it would select non-editable nodes. This commit sets the selection on the closest `[contenteditable=true]` instead of the closest `div` if the latter is not editable. Steps to reproduce: - Open website builder on a product page - Place the cursor in the price of the product - Press `ctrl+a` - Bug: the selection contains the `$` which is not editable task-6324409
This update fixes a minor accessibility issue by adding an aria-label to the quantity input field on the cart page. This ensures that users with screen readers can correctly identify and interact with the field, improving the overall user experience and compliance with accessibility standards. It's a simple change that enhances usability for all users.
Original PR description
In [1], the `aria-label` was not added to the quantity input field. This commit adds an `aria-label` to the quantity input field on the cart page to improve accessibility. [1]:https://github.com/odoo/odoo/commit/8f6c27b9b2d553a0b539ecd382bed80973621b6d | wih aria-label | without aria-label | | ------------- | ------------- | | <img width="674" height="432" alt="image" src="https://github.com/user-attachments/assets/962057fd-7272-4242-8a5d-dd1d66bc1096" /> | <img width="1293" height="229" alt="image" src="https://github.com/user-attachments/assets/836e272e-f505-4284-9a5c-02ab662f6061" /> | | <img width="1181" height="86" alt="image" src="https://github.com/user-attachments/assets/0e64d231-0c88-4cca-b333-7e602aedff18" /> |<img width="976" height="114" alt="image" src="https://github.com/user-attachments/assets/ae403367-cd3b-4c81-afe9-9eb452f66073" />| --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where product searches weren't working correctly when using the autocomplete feature. The fix bypasses a search optimization that prevented finding products based on barcode when the name search failed. This ensures users can consistently find products using either name or barcode.
Original PR description
Steps: - Create a product with a barcode "12345" - Create a sale order - Add a product - search product with name "12345" without copy/pasting - no result - try with copy/pasting - 1 result The problem is due to the fact that there is an optimization in Many2XAutocomplete.search which means that if no results are found for “1234,” it will not search for “12345.” However, product override name_search to returns a product only when the name is exactly equal to its barcode (`=` and not `ilike`), which does not work at all with search optimization. Since: https://github.com/odoo/odoo/pull/228035 opw-5908011 Forward-Port-Of: odoo/odoo#248583 Forward-Port-Of: odoo/odoo#247978
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
16 changes
Enhancements to existing features
This update enhances the accuracy of timesheet suggestions generated by the Timesheet Assistant Manager. The changes address minor issues with the assistant's recommendations, ensuring more reliable time tracking for project teams. This improves efficiency and data integrity within the Odoo Enterprise system.
Original PR description
This commit's purpose is to add a few bugprovement to the timesheet assistant manager. Those imp concerns mostly the timesheets suggested by the assistant manager. task-6179842
This update enhances the Odoo system's ability to handle new analytic plans. By mirroring a similar process used for companies, the system now automatically refreshes the web client when a new analytic plan is created, ensuring data accuracy and a smoother user experience. This change improves the overall efficiency of managing analytic data.
Original PR description
The views need to include the newly created field on `account.analytic.line` and other models inheriting `analytic.plan.fields.mixin`. This is based on the same service for `res.company`: `reloadCompany` Forward-Port-Of: odoo/odoo#270789
Resolved issues and error corrections
This change resolves an issue where the 'Add Property' button disappeared after navigating between worksheet templates. The fix ensures the button remains visible and functional after using the navigation controls, improving usability for users working with complex data structures. The underlying problem was a misconfiguration of edit mode state during record navigation.
Original PR description
Steps to reproduce: ------------------------------------------------- 1. Install `planning_field_service_worksheet` module with demo data 2. Go to Worksheet Templates 3. Open First Worksheet >…
Steps to reproduce:
-------------------------------------------------
1. Install `planning_field_service_worksheet` module with demo data
2. Go to Worksheet Templates
3. Open First Worksheet > Observe `+ Add Property` button at bottom
4. From the Navigation button, move to the next Worksheet Template
5. Come back to First Template using the same navigation button
Observation:
-------------------------------------------------
The '+ Add Property' button and property edit buttons disappear after navigating away from and back to the first worksheet template.
Issue:
-------------------------------------------------
`PropertiesDefinitionField.setup()` sets
`this.state.isInEditMode = this.definitionRecordId` only once during component initialization.
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_definition_field.js#L9-L12
When the user navigates via the pager, `FormController.onWillLoadRoot` resets `propertiesState.editable` to `false` and fires a `PROPERTY_FIELD:EDIT` bus event with `{ editable: false }`, which calls `setEditMode(false)` https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/form/form_controller.js#L407
After the new record loads, the parent's `useEffect` (which watches the definition record field) should restore edit mode, but it short-circuits when both `isInEditMode` and `editMode` are `false`
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_field.js#L115-L117
Since `setup()` doesn't re-run on record navigation and nothing else restores `isInEditMode`, it stays `false` permanently. This hides the parent template's 'Add Property' button
https://github.com/odoo/odoo/blob/8cf75467969eb423b8e50e8be45ebf5f60f1cc43/addons/web/static/src/views/fields/properties/properties_field.xml#L86-L90
Solution:
-------------------------------------------------
* Replace the one-time assignment in `setup()` with a `useRecordObserver` that sets `this.state.isInEditMode` whenever the record changes. This hook fires both on initial setup (via `onWillStart`) and on every record change (via `onWillUpdateProps`) ensuring `isInEditMode` is correctly restored after pager navigation
* Using `record.data.id` rather than `true` preserves the existing behavior of disabling edit mode for unsaved records (where `id` is `false/falsy`)
opw-6264361This 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
21 changes
New functionality added to Odoo
This update adds the ability to generate invoice PDF reports in multiple formats (Original, Duplicate, Triplicate) to comply with government regulations regarding GST documentation. Users can now print two or three copies of invoices with distinct titles, catering to different recipient types like transporters and suppliers. This ensures accurate record-keeping and adherence to tax requirements.
Original PR description
The Goverment specifies that invoice should be printed in different formats as per the different parties the invoice is been given to. Invoice should be marked as "Original" for receiver's copy. Invoice should be marked as "Duplicate" for transporter's (incase of goods supply) or supplier's copy. Invoice should be marked as "Triplicate" for supplier's (incase of goods supply) copy. This commit adds two new report actions, for Duplicate and Triplicate on invoice, visible in the Print section under the gear icon. When user prints Duplicate, 2 copies will be printed and for Triplicate, 3 copies will be printed at once, with different titles set on each copy of invoice. task-5899610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270813
Enhancements to existing features
This update ensures that new analytic plans are correctly reflected in the Odoo system after creation. It mirrors a recent change for companies, streamlining the process and preventing data inconsistencies. The change updates views to include new analytic plan fields, enhancing usability.
Original PR description
The views need to include the newly created field on `account.analytic.line` and other models inheriting `analytic.plan.fields.mixin`. This is based on the same service for `res.company`: `reloadCompany` Forward-Port-Of: odoo/odoo#270789
Resolved issues and error corrections
This update resolves an issue where Italian POS systems using specific characters in product or payment names would cause printing errors. The fix replaces unsupported characters with spaces, aligning with EPSON fiscal printer documentation to ensure proper printing functionality. This prevents incomplete order prints and improves the Italian POS experience.
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 clarifies Redsys payment errors by mapping their technical codes to understandable messages. Previously, errors were difficult to diagnose, making it hard to resolve payment issues and provide accurate information to customers. This change improves the reliability and transparency of Redsys payments within Odoo.
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 resolves an issue where delivery dates set on sales orders weren't consistently reflected in manufacturing orders, leading to incorrect deadlines. The fix ensures that delivery dates are properly propagated to finished moves during quantity changes, allowing for accurate scheduling and merging of production steps. This improves order fulfillment accuracy.
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 fixes an issue where emojis, particularly complex ones like family emojis, were being displayed incorrectly due to how they were encoded. The fix backports a previous solution from version 19.4 to ensure all emojis are correctly rendered, improving the overall email experience for users. This resolves a visual inconsistency.
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 improves the speed and efficiency of automatically creating reconciliation rules for bank statements. The previous method consumed excessive memory and time when processing long payment references, leading to errors. This change uses a more efficient algorithm to find common substrings, significantly reducing processing time and memory usage, particularly for large transactions.
Original PR description
When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5…
When setting an account to an account.bank.statement there is a step to automatically create a reconciliation rule/model if one does not exist already. To do so, we retrieve 5 account.bank.statement.lines and use them to define the reconciliation model config. A matching is done on the payment_ref of the account.bank.statement.lines by finding the longest common substring in the reference. ### Current Implementation The current algorithm does so by first generating all the possible substrings for all the payment_ref before doing the intersection between these sets and returning the max if `len(substring) >=10`. This is reasonable when the payment_ref follows either a SEPA communication national standard like the Belgian one or the Creditor Reference standard (ISO 11649). For transactions with large, unstructured communication with more than 100 chars, the method `_get_common_substrings` quickly overfill the memory, sometimes raising a MemoryErorr, and takes a significant amount of time. That's because the nested function `_generate_all_substrings` generates n*(n+1)/2 substrings, with n being the lenght of a payment_ref, called `label` in `generate_all_substrings`. ### Proposed Fix This commit introduces another algorithm to find the largest common substring. It starts by taking the two smallest labels to find their substrings intersection. We know that for an arbitrary collection of labels, the intersection of their substrings sets A ∩ B ∩...∩ Z is included in the intersection of any two substrings sets. The underlying assumption of the first step is that for an arbitrary collection of labels the intersection of the substrings sets of the two smallest labels will be the smallest intersection of any given pair of substrings sets. This won't hold true everytime and using a metric such as label similarity instead of shortest string might be better. But on average this should be good enough and it's easier to implement + it removes the need of preprocessing the labels to compute the similarity. The point of the new nested function `common_substrings` is to discard common substrings as we build them. Using the current `generate_all_substsrings` on either the smallest label or both smallest labels would still generate and store a lot of substrings, especially for large labels. By yielding the common substrings as we find them, the memory footprint is vastly reduced. Lastly, the next substring in the common_substrings iterable is only checked against the remaining labels if it's longer than the current match. This speeds up the whole process ### speedup In a customer database with some account.bank.statement.line with payment_ref > 500 chars, setting a specific account (code 4970) on transactions goes from MemoryError to < 1Mb memory consumption. Because of the memory consumption it was not possible to gather timing value on the current version. Testing the new algorithm in a shell and using as labels the 5 longest payment_ref in the customer database (831, 831, 1117, 1178, 1300 chars), averaging to 2000 chars once normalised, the average time to execute `_get_common_substrings` is 900 ms ± 10.3 ms. Forward-Port-Of: odoo/enterprise#118824
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 removes an unnecessary 'external' tag from a test class within the SendCloud delivery module. Previously, errors were only detected during nightly builds, not by the standard Continuous Integration (CI) process. Fixing this tag requires updating some tests to ensure accurate and consistent error detection.
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#120902 Forward-Port-Of: odoo/enterprise#111660
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
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
3 changes
New functionality added to Odoo
This update adds missing translations for various user-facing messages within the Odoo POS modules. This ensures that the POS system is correctly localized for users in different languages, improving the overall user experience and supporting international expansion. The changes cover UI elements, error messages, and internal Python messages.
Original PR description
pos* = All POS module In this commit: -------------------------------- Add missing translations for user-visible strings across POS modules. - Translated dialogs, errors, alerts, and other UI-visible messages - Updated Python-side UserError, ValidationError, and warning messages Task-5406947 Related PR-https://github.com/odoo/odoo/pull/239972 Forward-Port-Of: odoo/enterprise#102094
Resolved issues and error corrections
This update ensures that partner data on the POS system is automatically updated after a DIAN refresh, using government credentials. Previously, the system only updated the partner name initially, but not subsequent legal information. This fix guarantees accurate partner details are reflected on the POS.
Original PR description
Step to reproduce: - install l10n_co_dian and pos - open pos and click on create a new partner from partner list - enter name ex. "temp", identification number, click on form - notice a `refresh…
Step to reproduce: - install l10n_co_dian and pos - open pos and click on create a new partner from partner list - enter name ex. "temp", identification number, click on form - notice a `refresh icon` is visible: click on it. Observation: - the dialog is closed and partner is selected with "temp" name Expected: - with valid government credentials and a valid identification number, the refresh action should also update the partner data on the POS side Cause: - the refresh button triggers the `button_l10n_co_dian_refresh_data` action, which fetches the legal name and email from the government service - although the backend record is correctly updated, the new values are not immediately synchronized with the POS - when the refresh button is clicked, editPartner() first triggers `web_save` using the temporary "temp" name and immediately reads the partner data afterward - the refresh action executes later and updates the contact with the fetched legal information, but the POS is not aware of these subsequent changes Fix: - read the data again if there is any update caused by this action. - this is done by overriding `afterExecuteActionButton` of FormController class opw-6198035 Forward-Port-Of: odoo/enterprise#117527
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
7 changes
New functionality added to Odoo
This update introduces a streamlined process for requesting and managing DMFA reports, allowing for corrections and consultations on employee payroll data. The system now automatically detects changes in payslips and triggers a consultation request, ensuring accurate reporting for tax compliance in Belgium. This improves data integrity and simplifies the reporting process.
Original PR description
- Introduce the ability to create a DMFA consultation and modification reports for all employees or a selected subset - Can be done independently or through a changes detection flow (warning if payslips changes detected -> send a consultation request -> sync data -> send mofication request) - Add NaturalPersonState model to store the latest changes for an employee coming from changes in payslips or consultations - Dynamic fetching of the latest DMFA XSD schema validator instead of being store in the codebase - Dashboard warning in case of payslips changing for a submitted report - Rename declaration_type to declaration_method for better naming of the new variable defining the different types of declarations - Sync DMPI files and Consultation files task-5404502
Enhancements to existing features
This update simplifies the payroll offboarding process by hiding irrelevant fees and preventing duplicate payslip generation. The system now intelligently handles holiday attest requests, avoiding errors caused by recent hires and ensuring a smoother workflow for HR staff.
Original PR description
First, the "Termination Fees" generation button is now hidden if the employee fully works their notice period. Since these fees are not legally applicable in this scenario, hiding the button removes…
First, the "Termination Fees" generation button is now hidden if the employee fully works their notice period. Since these fees are not legally applicable in this scenario, hiding the button removes visual clutter and prevents HR officers from generating invalid payslips by mistake. Action names have also been refined to provide clearer terminology. Secondly, the generation logic for both termination fees and holiday attests has been updated to be idempotent. Previously, clicking the buttons multiple times would spam the system with duplicate draft payslips. The logic now intercepts the creation process: if a non-cancelled payslip already exists for the target structure and period, the system acts as a smart redirect and simply reopens the existing record(s). Finally, the system now validates the employee's first contract date before attempting to generate an N-1 holiday attest. If the employee was hired in the current year (Year N), the N-1 attest generation is entirely skipped, preventing the creation of empty, nonsensical documents that would otherwise require manual deletion. task-6296066
This update enhances the initial setup of the Point of Sale (POS) system by incorporating configuration and session IDs. These IDs allow the system to correctly identify and operate within specific store environments, improving accuracy and functionality. This change primarily impacts the enterprise and IoT POS modules.
Original PR description
*: l10n_it_pos In this commit: - Add `pos_config_id` and `pos_session_id` to the global `odoo` variables initialized in `setupPosPrepDisplayEnv`. - Use `self_ordering_mode` from the global `odoo` variables to determine whether the config is a kiosk configuration. Task-6190644
This update enhances data security by preventing sensitive payroll information (like wages and costs) from being visible to unauthorized users. A recent change in how tracking messages are generated made previous security controls ineffective. This fix ensures only payroll team members can access these critical details.
Original PR description
When a new version is created from the salary configurator, a tracking message summarizing field changes is posted on the employee chatter. This message may contain sensitive payroll information such…
When a new version is created from the salary configurator, a tracking message summarizing field changes is posted on the employee chatter. This message may contain sensitive payroll information such as wage and yearly cost, which should not be visible to users outside the payroll group. Previously, all tracking messages on hr.employee were visible to any user with access to the employee record. After the mail tracking refactor introduced in task (3645865) (https://www.odoo.com/odoo/project/1251/tasks/3645865), tracking values are now rendered directly into the message body, making the old field-level filtering mechanism no longer applicable. To restore payroll visibility restrictions: * Tracking values linked to payroll-restricted fields are separated from regular tracking values during `_track_log`. * Payroll-sensitive tracking values are posted in a dedicated tracking message using the subtype `mt_hr_payroll_sensitive`. * Regular tracking values continue to use the standard tracking flow and remain visible to all users with access to the employee chatter. * Employee chatter message fetching is overridden to hide payroll-sensitive messages from users outside `group_hr_payroll_user`. A test was also added to ensure payroll-sensitive tracking messages remain hidden from non-payroll users. Task: 4985543
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)
Features or functions removed from Odoo
This update simplifies the Frontdesk module by removing the 'cancel' visitor state, which was no longer used. This streamlines the visitor tracking process and reduces unnecessary complexity within the system. This change improves the overall user experience and maintenance of the Frontdesk feature.
Original PR description
This commit removes the cancel state from the frontdesk visitor states, as it is no longer relevant. Task-6312796
5 changes
Resolved issues and error corrections
This update resolves a bug where the 'Suggest Forecasted Demand' button disappeared in the Master Production Schedule when the 'Forecasted Stock' row was hidden. Previously, the button's visibility was dependent on the 'Forecasted Stock' row being enabled, causing confusion for users. Now, the button remains visible regardless of the 'Forecasted Stock' row's status.
Original PR description
Steps to reproduce:
1. Install Manufacturing.
2. Enable 'Master Production Schedule' in the Settings.
3. Go to [Manufacturing -> Planning -> Master Production Schedule].
4. Ensure 'Demand Forecast' and 'Forecasted Stock' rows are enabled from the dropdown.
5. Observe the edit pencil button next to 'Forecasted Demand' is visible.
6. Hide 'Forecasted Stock' using the rows filter dropdown.
Issue:
The edit pencil button ("Suggest Forecasted Demand") next to the 'Forecasted Demand' row disappears when the 'Forecasted Stock' row is hidden.
Expected behavior:
The edit pencil visibility should not be affected by the 'Forecasted Stock' row.
opw-6240596This update resolves several errors in the Blackbox test suite for the Belgian POS system, ensuring accurate order processing and synchronization. Specifically, the tests were failing due to incorrect data setup, mismatched expectations regarding printer types, and issues with cost center assignments. These fixes improve the reliability of the testing process and the overall functionality of the system.
Original PR description
1. The `m160` and `m161` mutations for `sign_copy_sale` test didn't set the `l10n_be_short_signature` field on the order, so the `TicketScreen.print` override would fail the check and the…
1. The `m160` and `m161` mutations for `sign_copy_sale` test didn't set the `l10n_be_short_signature` field on the order, so the `TicketScreen.print` override would fail the check and the `blackbox.signCopy` would not be called, causing the test to fail. 2. The `l10n_be_pos_blackbox_urban_piper` tests would crash on `undefined id` on the prep display path of `pos_enterprise`, where the data service will try to load up the prep display data, but it's not loaded in the test bundle. So I created a special setupEnv method for blackbox with urban piper which unpatches the prep display (same mechanism as pos_enterprise) 3. After removing the path for the tests, they would fail for the `expectGeneralProperties` step. By default it expects the `ticketMedium` to be `PAPER`, but there is no printer configured on the tests, so the actual medium is `DIGITAL`. 4. The tests expect the cost center to be `PLATFORM`. There was a patch on `InputGenerator`, which would return platform if the order has a `delivery_provider_id` set. But the patch never fired. I moved the patch directly on the order model, which is where the cost center value is computed. 5. The `test_l10n_be_pos_blackbox_sign_sale_backend_offline` test would endTour prematurely before the orders finished syncing, then check that all the orders are synced. I added an extra isSynced() step to ensure the orders are synced before ending the tour Task-[6320705](https://www.odoo.com/odoo/1737/tasks/6320705)
This update fixes an issue where insurance information wasn't correctly transmitted to Envia, preventing insurance PDFs from being generated. The change updates how insurance details are sent to the Envia API, aligning with Envia's requirements for additional services. This ensures accurate insurance coverage is reflected in shipments.
Original PR description
Issue ----- Insurance set on the delivery method is not correctly being communicated to Envia. Steps to reproduce ----- - Create a MX company - Set up Envia - Fedex Nacional Economico (ground) - 10% insurance - Create a MX client - Create a product (with some weight) - Create a SO using the delivery method & confirm - Validate the picking > No insurance pdf is being printed Cause ----- We are passing the insurance value as a `insurance` field on the shipment, which is not what the API expects. We should instead pass it in `additionalServices` as shown in the example of https://docs.envia.com/docs/additional-services#how-to-add-services-to-a-shipment ----- Ticket: opw-5254952
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
15 changes
Resolved issues and error corrections
This update corrects a bug in the Italian e-invoice system (l10n_it_edi) that was causing invoices to be rejected by the SDI due to lowercase 'Codice Fiscale' entries. The fix ensures the field always accepts uppercase input and improves the user experience by automatically capitalizing the text entered.
Original PR description
### Steps to reproduce: - Install "l10n_it_edi_website_sale" and switch to Italian company - Configure the website for this company - Open the website as customer - Add something to the cart, go up to delivery - There the field "Codice Fiscale" can be lowercase - When entering something lowercase here, the invoice is then rejected by SDI. - Same for "Destination Code (SDI)" ### Cause: The SDI requires the field to be uppercase. ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to return the uppercase value. (Already the case for "Destination Code (SDI)") Add `text-uppercase` on the input so the text entered there is always capital (better for the user). opw-4655364
This update fixes an issue where Danish expense reports were incorrectly calculating taxes. Specifically, when using the 'K-EU-V-DelvisFradrag' tax, the journal entries were showing an incorrect tax amount. The change ensures that taxes with negative repartition values are handled correctly, aligning with previous Odoo versions.
Original PR description
### Steps to reproduce: - Install "l10n_dk" and switch to Danish company - Create an empty sale order - Create a new expense - Category "Communication" for example - Total of 100 for example - Select…
### Steps to reproduce: - Install "l10n_dk" and switch to Danish company - Create an empty sale order - Create a new expense - Category "Communication" for example - Total of 100 for example - Select "K-EU-V-DelvisFradrag" as a tax - Paid by company - Select the customer to reinvoice - Click "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" - Go to the Journal Entry and see the Journal Items - The tax is a 25% tax but the value in the journal entries is 20 (so 20%) ### Cause: When called from the Expense app `_get_tax_details` is called with `special_mode == total_included` ([see](https://github.com/odoo/odoo/blob/467ab37703a44ca6cf57552715b75b087dc77d0d/addons/hr_expense/models/hr_expense.py#L549)). The special mode makes all taxes computed as if they were included taxes. But taxes with negative lines should not be computed as included (as in 17.0). The code already handles that the base amount is not changed for these taxes ([see](https://github.com/odoo/odoo/blob/467ab37703a44ca6cf57552715b75b087dc77d0d/addons/account/models/account_tax.py#L1088-L1092)). But not the amount of the tax in question. ### Solution: In `_eval_tax_amount_price_included`, if the tax has `has_negative_factor` to `True` then compute the tax as excluded. opw-4532391
This pull request contains a simple test change to ensure the runbot is functioning correctly. The change involves a basic 'test' commit to verify the automated testing process. This is a low-risk update to maintain the stability of the Odoo build environment.
Original PR description
Just to test the runbot
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
6 changes
Resolved issues and error corrections
This update ensures that partner bank accounts are usable within all child companies, even if the partner is associated with a parent company. Previously, this functionality was limited, causing potential disruptions for users managing multiple company branches. This change improves efficiency and simplifies bank account management across the Odoo system.
Original PR description
Even when a partner has the 'company_id' filled with the parent company, his bank account should be usable in the child companies. This was done in odoo/odoo#262173 from 19.2 but we need to backport it in stable task-6309694
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