Daily updates from Odoo
Wednesday, June 24, 2026
42 changes · saas-19.1
New functionality added to Odoo
This update introduces on-demand printing of kitchen order tickets directly from the kitchen station. When an order moves to a defined stage, the system automatically generates and prints a KOT. The tickets now include barcodes for efficient scanning and streamlined order processing.
Original PR description
*: pos_restaurant_preparation_display, pos_urban_piper In this commit: ------------------- - Introduced functionality to print KOTs on demand from the kitchen. - Added support for automatic printing when an order is moved to a configured stage. - Added barcodes to KOTs printed from the kitchen, allowing kitchen staff to scan them and directly move the order to the next stage. task: 6131467 Community PR: https://github.com/odoo/odoo/pull/266273
This update enables automatic receipt of vendor bills from the Hungarian tax authority (NAV) via their API. A new 'Sync with NAV' button allows users to schedule bill retrieval based on a date range, and supports both API integration and direct XML uploads for seamless invoice processing. This improves efficiency and accuracy for Hungarian businesses.
Original PR description
In Hungary, we are already sending invoices to NAV(hungarian tax authority). Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor bills through its API and also adds XML…
In Hungary, we are already sending invoices to NAV(hungarian tax authority). Now this module `l10n_hu_edi_receive` provides functionality of receiving vendor bills through its API and also adds XML importer for Hungarian localization. A button `Sync with NAV` is added in vendor bills list view, which opens a wizard where you can select time period and all bills uploaded between that time are fetched from NAV's API. Also directly uploading XML is also supported in the format NAV supports. Flow:- - After selection of time range, we call `queryInvoiceDigest` endpoint with that range and it returns a list of digests(consider each digest as separate invoice) but this digests contains only meta data not all details. - Now for each digest we call `queryInvoiceData` endpoint which returns xml response with `QueryInvoiceDataResponse` as root node. This xml contains some meta data and `InvoiceData` node which has a base64 string, when we decode that string we get an xml with `InvoiceData` as root node and this xml contains all details of the invoice, we parse both these details and create bills and refunds. Also xml importer supports any of the `InvoiceData` or `QueryInvoiceDataResponse` xml. NAV Documentation: https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf task-5237910 Forward-Port-Of: odoo/odoo#240919
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 streamlines the process of printing preparation tickets from the kitchen within the Point of Sale system. By consolidating common code, the system avoids duplication and ensures a more efficient workflow. This change enhances the speed and reliability of order fulfillment.
Original PR description
In this commit: ------------------- - Moved common internally used methods to shared logic to avoid duplicating the same code multiple times task: 6131467 Enterprise PR: https://github.com/odoo/enterprise/pull/118286
This update changes the unit of measure for the 'Flour' product in the Point of Sale module to kilograms. This adjustment is necessary to properly configure product weighing, particularly for compliance with the l10n_eu_iot_scale certification, ensuring accurate product tracking and reporting.
Original PR description
This small PR sets the "Flour" product's units of measure to kilograms. This helps to configure the weighing of the product, especially for the l10n_eu_iot_scale cert Forward-Port-Of: odoo/odoo#270508
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 fixes an error that prevented users from correctly processing credit notes with the 'P10' business process type in the Croatian e-invoicing module. The fix ensures compliance with Croatian tax authority regulations, allowing for accurate reporting of credit note corrections. This update resolves a restriction that was preventing the correct generation of e-invoices.
Original PR description
**Steps to reproduce:** * Install the Croatian e-invoicing module (**l10n_hr_edi**). * Set up a Croatian company and a Croatian customer partner (with OIB and VAT configured). * Create a customer…
**Steps to reproduce:** * Install the Croatian e-invoicing module (**l10n_hr_edi**). * Set up a Croatian company and a Croatian customer partner (with OIB and VAT configured). * Create a customer invoice and post it. * Create a credit note from that invoice via **Credit Note** button. * On the credit note, change **Business Process Type** from `P9` to `P10: Issuing a corrective invoice`. * Save the credit note. **Observed behavior:** * Saving fails with: "Business Process Type P9 can only be used with credit notes and vice versa." * The error occurs even though P10 is a valid process type for credit notes according to the Croatian tax authority specification. **Cause:** * The `_check_l10n_hr_process_type` constraint used an XOR-style boolean check: `(process_type == 'P9') == (move_type != 'out_refund')`. * This enforced an exclusive P9 ↔ out_refund mapping, making P9 the **only** allowed process type for credit notes and blocking P10 entirely. * Per the Croatian tax authority specification, P10 (corrective invoice) is explicitly valid for credit notes: full cancellations report negative quantities/amounts, and partial corrections may report either positive or negative values. **Fix:** * Replace the XOR constraint with two independent, clearly-scoped rules: - P9 may only be used on credit notes (`out_refund`). - Credit notes must use either P9 or P10. * Add P10 UBL type code mapping in `_ubl_add_credit_note_type_code_node()`: P10 credit notes now emit `CreditNoteTypeCode 384` (Corrected Invoice, UNTDID 1001) instead of falling through to the default 381. opw-6128955 - Official Croatian Information Intermediary: https://portal.moj-eracun.hr/blog/kako-stornirati-eracun/ - Croatian Tax Authority (FAQ on fiscalization and e-invoicing): https://porezna-uprava.gov.hr/UserDocsImages/Fiskalizacija/Fiskalizacija_eRacun/Pitanja%20i%20odgovori%20vezani%20uz%20Zakon%20o%20fiskalizaciji.pdf Forward-Port-Of: odoo/odoo#266288
This update significantly speeds up the calculation of future timesheets based on public holidays. The previous process was slow and inefficient, especially with many holidays set for the future. This change optimizes the calculation process, resulting in faster timesheet generation and improved system performance.
Original PR description
**Problem:** When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several…
**Problem:** When creating a new employee, the future timesheets due to public holidays are computed. If the number of public holidays is large (i.e. if the user creates them for each year, several years in the future), then it takes excessively long and the action may not complete. **Cause:** The pytz method `localize` and comparing times with non-static timezones is done repeatedly and unnecessarily which becomes costly with more records. **Solution:** Only localize the time when absolutely necessary (determining the date of the leave in the calendar timezone). **Performance Stats:** |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |100 |3.1s |393 |0.8s |117 | |1,000 |22.3s |2,090 |1.5s |183 | |10,000 |Timeout |N/A |6.7s |541 | opw-6087422 Forward-Port-Of: odoo/odoo#269876 Forward-Port-Of: odoo/odoo#263953
This update fixes an issue where scanning an unknown barcode in the POS system didn't automatically open the product creation form. The fix removes a redundant check for API keys, ensuring the form opens correctly regardless of whether a barcode lookup key is configured. This improves the user experience by streamlining product creation through barcode scanning.
Original PR description
When scanning an unknown barcode in POS, the product creation form was never opened because `barcode_lookup()` was called with no barcode as an implicit API key check. Commit 0c8019a4aa7 ([FIX] product_barcodelookup: avoid crash on invalid image URLs) standardized `barcode_lookup_request()` to always
return a `requests.Response` object, removing the `{'authenticated': True}` dict it previously returned for HTTP 404 responses. As a result the JS check `response?.authenticated` was always falsy and the form never opened.
Fix: remove the API key check entirely. `allowProductCreation()` already gates on the user having product create rights, which is the only condition that matters. If a Barcode Lookup API key is configured the `_onchange_barcode` on the form will auto-fill product data; if not, the user can fill it in manually. Either way the form is always usable.
opw-6295221
Forward-Port-Of: odoo/enterprise#120256This update corrects an error in the generation of E-Way Bills when prices include tax. Previously, the system incorrectly calculated tax amounts, leading to inaccurate E-Way Bill documents. The fix ensures that tax is properly accounted for, producing correct amounts for tax-included sales.
Original PR description
`*` = `ewaybill_Stock, sale_stock, purchase_stock` **Steps to reproduce:** * Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`. * Set the Default Tax Price Setting to "Tax Included". * Create…
`*` = `ewaybill_Stock, sale_stock, purchase_stock` **Steps to reproduce:** * Install `l10n_in_ewabill_stock` and `l10n_in_sale_Stock`. * Set the Default Tax Price Setting to "Tax Included". * Create a Sales Order (e.g. unit price 300, qty 600, 18% GST) and confirm the Delivery Challan/Delivery Order. * Generate an E-Way Bill from the Delivery Challan. **Observed behavior:** * The Taxable Amount and Total Invoice Amount are displayed incorrectly in the generated E-Way Bill, including both the printed document and the JSON. * The `ewaybill_price_unit` shows the tax-excluded price (e.g. 254.24) instead of the original tax-included price (300), leading to a double tax exclusion when `compute_all` processes it. **Cause:** * `_l10n_in_get_product_price_unit` in both `l10n_in_sale_stock` and `l10n_in_purchase_stock` unconditionally used `price_subtotal / qty` to compute the E-Way Bill price unit. `price_subtotal` is always tax-excluded, so for tax-included prices, the tax was already stripped. * `_l10n_in_tax_details_by_stock_move` then passed this already tax-excluded price to `compute_all` with taxes that have `price_include=True`, causing `compute_all` to strip the tax a second time (e.g. 254.24 / 1.18 = 215.46 instead of the correct 254.24). **Fix:** * Check whether any of the line's taxes have `price_include` set. If so, use `price_total / qty` (which preserves the tax-included price) so that `compute_all` can correctly extract the tax. Otherwise, continue using `price_subtotal / qty` as before. opw-6273101 Forward-Port-Of: odoo/odoo#271492 Forward-Port-Of: odoo/odoo#268504
This update resolves a problem where Point of Sale order sequences with dynamic prefixes (like years) weren't generating correctly. The fix ensures that sequence numbers are properly formatted as integers, preventing errors during order processing. This improves the reliability of POS order creation.
Original PR description
**Steps to reproduce:** - Create a database in version 19.0 and install Point of Sale. - Create a sequence with a prefix or suffix using placeholders like %(year)s. - Assign this sequence to a POS…
**Steps to reproduce:** - Create a database in version 19.0 and install Point of Sale. - Create a sequence with a prefix or suffix using placeholders like %(year)s. - Assign this sequence to a POS configuration. - Create a new POS order and confirm payment. **Issue:** - POS order `sequence_number` must be an integer, but when using dynamic prefixes/suffixes (e.g., %(year)s), `_next()` returns values like `POS/2026/` while the configured prefix remains `%(year)s`. - Due to this mismatch, [`_update_sequence_number`](https://github.com/odoo/odoo/blob/ab6cfabf0086afced2d035eb2207a0acab655540/addons/point_of_sale/models/pos_order.py#L561) fails to correctly remove the prefix/suffix. - The root cause is that placeholders such as `%(year)s` are not interpolated before applying prefix/suffix removal logic, causing string mismatch and failure in extracting the numeric part.<img width="1920" height="959" alt="image" src="https://github.com/user-attachments/assets/d331fb7a-3c0f-4e34-a33e-6ec906be77bb" /> **Solution:** - Interpolate prefix and suffix before removing them from the generated sequence. - Convert placeholders like %(year)s into actual values (e.g., 2026). - Then apply prefix/suffix removal logic. opw-6150204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262427
This update corrects a rounding error in how overtime durations are calculated, which previously caused overlapping time entries. The fix ensures accurate back-projection of work entries, preventing overlaps and guaranteeing correct overtime tracking. This improves the reliability of time and attendance data.
Original PR description
__Issue:__ `duration` is rounded to 3 decimals (~1.8s drift) while `time_stop` is exact, so the back-projected start could land before midnight on overnight overtime or middle of the day causing overlaps with the previous line Example: - time_start = 03/05 00:00:00 - time_stop = 03/05 07:07:14 actual duration 7h07m14s gets stored as `duration = 7.121` (= 7h07m15.6s) after `round(_, 3)`. Back-projection yields `datetime_start = 07:07:14 - 7.121h = 02/05 23:59:58`, overlapping by ~2s with the prior line ending at `02/05 23:59:59.999`. __Fix:__ Sort lines by `time_stop` within each date and clamp `datetime_start` to the previously emitted interval's stop when the two intervals genuinely intersect. opw-6170828 Forward-Port-Of: odoo/enterprise#116565
This update fixes an issue where clicking the 'Documents' button on an employee form would open a new browser tab. The change adds a setting to the button's action, ensuring it opens directly within the existing employee form, improving user experience and workflow efficiency.
Original PR description
Issue: ---------------------------------------- When on an employee form, clicking the "Documents" button opens a new page instead of staying on the same. Steps to reproduce: ---------------------------------------- - Install `documents_hr` - Go on an employee form - Click the "Documents" button - It opens a new page Cause: ---------------------------------------- The `'ir.actions.act_url'` opens a new page by default. Solution: ---------------------------------------- Add `'target': 'self',` to make it open the URL in the same page. opw-6284677 Forward-Port-Of: odoo/enterprise#120285
This update ensures that partner data created in the POS system is automatically synchronized with the latest information from the DIAN government service after a refresh. Previously, changes weren't reflected immediately, but this fix corrects this issue by updating the POS data during the refresh process. This improves data accuracy and compliance.
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 resolves a problem in the SendCloud test suite caused by recent changes to the SendCloud integration. The tests were failing because they continued to use an outdated method for accessing the SendCloud API. This change ensures the tests accurately reflect the current SendCloud implementation.
Original PR description
Issue Before This Commit: ---------------------------- The delivery_sendcloud test suite relied on `delivery.carrier._get_sendcloud()` to access the SendCloud API helper. After recent changes in the SendCloud integration, this method is no longer available, causing multiple tests to fail when invoking SendCloud services during setup and execution. Cause of the issue: ------------------- After PR odoo/enterprise#96749, the SendCloud integration was refactored to require usage through a context manager. As part of this change, _get_sendcloud() was removed, but the existing test cases were still relying on it, causing failures. After this commit: ------------------ All SendCloud-related test cases are updated to explicitly instantiate the SendCloud client and use it within a context manager, mirroring the new lifecycle requirements introduced by the refactor. This aligns the test suite with the current SendCloud implementation and fixes the failing tests.
This update removes an outdated method for retrieving system parameters in the l10n_fr_pdp module. The change utilizes a more reliable approach (get_str) for parameter retrieval, enhancing the module's stability and performance. This is a routine maintenance fix.
Original PR description
This commit will remove the use of the get_param for system parameter and instead use get_str no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where self-invoicing URLs on receipts were incorrectly formatted. Now, the correct URLs are generated and displayed, ensuring accurate invoicing data is sent to the appropriate systems. This improves the reliability of self-ordering transactions.
Original PR description
Before this commit: ------------------------- - The self-invoicing URL on the receipt was displayed as `undefined/pos/ticket`. After this commit: ------------------------- - The self-invoicing URL is now generated correctly and displayed properly on the receipt. Task-6271261 Forward-Port-Of: odoo/odoo#270052
This update fixes a display issue where rental prices weren't correctly formatted with a slash separating the price and duration. The fix ensures rental prices are shown clearly on the website, improving the user experience for customers renting products. This change was triggered by a bug in how the rental duration label was generated.
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#120223
This update simplifies the process of updating the Account EDI UBL Cii reporting module. Previously, a fragile inheritance method caused potential conflicts with other Odoo templates. This change creates a more robust system for identifying the necessary updates, reducing the risk of issues and making future improvements smoother.
Original PR description
**Description of the issue/feature this PR addresses:** As the new `xpath` is expecting a very specific type of `t-if` which is possibly changed in other templates of third parties or even Odoo itself which do not depend on this module, we take a more robust approach to identify the block **Current behavior before PR:** Issues with inherited views outside the dependency tree (because of primary=True) **Desired behavior after PR is merged:** Less friction and smoother identifier of the needed diff Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270605
This update resolves a stability issue in the point-of-sale tour. Previously, the tour could fail due to asynchronous order processing, leading to duplicate requests. By adding a delay to ensure requests are fully completed, this fix prevents race conditions and improves the reliability of the tour.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#121237 Forward-Port-Of: odoo/enterprise#110909
This update addresses a test failure related to database constraints in the email functionality. A recent database upgrade triggered a different error (RESTRICT_VIOLATION) instead of the previous FOREIGN_KEY_VIOLATION. The test has been updated to handle this new error type, ensuring continued stability.
Original PR description
This commit is kind of a follow up of
odoo/odoo@39cd4ea856fe00f5674f8c44b2b66cbf2705426d (in 18.0).
In a nutshell, following a standard-compliance fix (postgres/postgres@086c84b) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_alias_domain_setup`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "mail_alias_domain" violates RESTRICT setting of foreign key constraint "mail_alias_alias_domain_id_fkey" on table "mail_alias"
DETAIL: Key (id)=(191) is referenced from table "mail_alias".
This commit updates the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes.
Forward-Port-Of: odoo/odoo#271403
Forward-Port-Of: odoo/odoo#271302This 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
This update resolves an issue where switching between models within the website studio's 'More models' feature caused a crash. The fix ensures both the current and newly selected models are retained in the system's memory, preventing errors and improving the overall stability of form switching. This enhances the user experience for managing multiple forms.
Original PR description
Selecting a second model through the Action option's "More models" crashed because the current form model was dropped from the models cache while the new model was being applied. This commit keeps both the current form model and the model being applied in the cache. Steps to reproduce: - Add a form snippet - Click on the form - In the `Action` option, select `More models` - Select one model - Open `More models` again and select another model - Traceback appears: `TypeError: Cannot read properties of undefined (reading 'website_form_key')` task-6321878 Forward-Port-Of: odoo/enterprise#121492
This update resolves an issue where the due date calculation for French payroll was inaccurate, particularly in November. It also corrects a technical error that prevented the system from properly processing certain records. These changes ensure accurate reporting and data processing for French businesses using this module.
Original PR description
- Fix due date calculation (returned month 0 if move date was in November) - Fix ensure_one error, avoid calling _deduce_country_code() on an empty recordset opw-6293701 Forward-Port-Of: odoo/odoo#270148 Forward-Port-Of: odoo/odoo#270003