Thursday, April 30, 2026
35 changes · saas-19.1
Resolved issues and error corrections
This update fixes a performance issue where updating a product's lot or serial number in a picking could trigger slow requests due to fetching all stock quantities. The change ensures that the system respects the specified limit when retrieving quantities, resulting in significantly faster update times. This improves the overall responsiveness of the barcode picking process.
Original PR description
## Problem: During an `onchange` call, if a field is defined in the `fields_spec` with a `limit` attribute, the `fetch` method doesn't respect it, and will fetch all records satisfying the domain. In certain circumstances, this leads to slow requests. ## Solution: Enforce the `limit` when fetching if it is present. ## Steps to reproduce: - Have a product with many quant records 1. Open a picking for this product in Barcode 2. Change the lot/serial The frontend will send an `onchange` request that includes `product_stock_quant_ids` in the `fields_spec` (with default `limit` 40). Odoo will fetch all quants for this product regardless of the limit, and the request will take a while to resolve. ## Benchmark: <table> <thead> <tr> <th># of quants</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>17193</td> <td>~9s</td> <td>~400ms</td> </tr> </tbody> </table> opw-6041705 Forward-Port-Of: odoo/odoo#259983
This update strengthens the security of Xendit payments by requiring a valid access token linked to the specific transaction. Previously, payments could be processed without this verification, creating a potential risk. Now, payments are restricted to the correct transaction, improving security and preventing unauthorized payments.
Original PR description
**Description of the issue/feature this PR addresses:** The `/payment/xendit/payment` endpoint did not enforce validation of an access token tied to the transaction when processing direct payment requests. **Current behavior before PR:** The endpoint accepted public requests using only the transaction reference, allowing payment execution without verifying that the request was linked to the intended transaction. **Desired behavior after PR is merged:** The endpoint now requires a valid access_token associated with the transaction (reference) before processing. This ensures that payment execution is restricted to the correct transaction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261912 Forward-Port-Of: odoo/odoo#260258
This update fixes an issue where the IRN (Invoice Reference Number) generated during E-Invoicing EDI submission wasn't correctly saved or displayed on the invoice itself. The fix ensures the IRN number is now present in both the generated PDF invoice and the invoice form view, streamlining invoice tracking for users.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the…
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#115522 Forward-Port-Of: odoo/enterprise#114350
This update resolves an error that occurred when exporting VSME reports if the base year was invalid. The fix ensures that only valid 4-digit years are used, preventing a data processing error and ensuring accurate report generation. This improves the reliability of VSME reporting.
Original PR description
Currently, an error occurs when exporting VSME reports if the base year is not a valid 4-digit year. **Steps to Reproduce:** 1. Install the `esg_csrd` module with demo data. 2. Create new "**VSME Reports**" with `Base Year = 1`. 3. Now, click on "**Print**". **Error:** `ValueError - Invalid isoformat string: '1-01-01'` **Cause:** The base year is directly used to build a date in [1], resulting in `datetime.date(1, 1, 1)`. In [2], this is formatted to **"1-01-01"** and used in a domain search, which raises a ValueError due to an invalid ISO date format. **Fix:** - Adds a **constraint on base year** to ensure only valid years (1000–9999) are allowed for new VSME Report records. - Adds a **helper validation method** to verify base year before performing computations on existing records. sentry-7419431039 Forward-Port-Of: odoo/enterprise#114453
This update corrects a technical issue preventing users from successfully booking appointments with flexible hour slots. The problem stemmed from an incorrect calculation of appointment durations, leading to a 404 error. The fix ensures accurate slot durations are used when building booking URLs, allowing for seamless appointment scheduling.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment…
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312 Forward-Port-Of: odoo/enterprise#108870
This update resolves an issue where power buttons were incorrectly displayed and overlapping other menu items within the HTML editor, particularly on smaller screens. The fix adjusts the editor's width detection to ensure buttons are hidden when they cause overlap, improving the user experience and visual consistency.
Original PR description
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global…
Problem: Power buttons are shown regardless of the editor field's actual rendered width, causing them to overlap other menus when the field is small. Solution: Instead of relying solely on the global `ui.isSmall` (mobile detection), check the editor field's own width and hide power buttons whenever it falls below the overlap threshold. Before: <img width="576" height="301" alt="image" src="https://github.com/user-attachments/assets/dcebed55-5c80-4fe5-8d33-c320549cf347" /> After: <img width="542" height="336" alt="image" src="https://github.com/user-attachments/assets/34a233bb-9958-43ac-adb9-04702a2e403d" /> Steps to reproduce: - Change languange (French to have a long placeholder). - Settings > Customer Invoices > Default Terms & Conditions. - Check "Add a Note". - Resize the screen to smaller size. - Observe the power buttons overlap with the translate button. task-6117734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261881 Forward-Port-Of: odoo/odoo#259094
This update corrects a reporting issue where the '18% IGST (IMP-Service)' tax wasn't accurately reflected in the GSTR-3B report. The fix adjusts how tax distributions are handled, ensuring the correct service tax amount is imported. This ensures accurate tax reporting for Indian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_in_reports - Switch to an Indian company (e.g. IN Company) - Create a bill with a Service product and "18% IGST (IMP-Service)" tax - Confirm the bill - Go to "Accounting / Reporting / India / GSTR-3B" **Issue:** In "4. (A) (2) Import of services" section of the report, the bill that has been created is not taken into account. **Cause:** The "18% IGST (IMP-Service)" tax has a distribution of: * 100% of the tax in "100570" account with "IGST" tax tag * -100% of the tax in same account with "IGST" tax tag Therefore, both distribution lines with the tax tag cancel themselves. opw-6116356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260631
This update resolves an issue where multi-company invoices were experiencing errors due to incorrect tax calculations. The change ensures that tax data is handled securely, preventing access errors when products from different companies are involved. This improves invoice processing reliability for businesses using Odoo's multi-company feature.
Original PR description
Description of the issue this commit addresses: In multi-company setups, invoice line tax recomputation could read product or account taxes in user context and trigger an AccessError on account.tax when products carry taxes from another company. Desired behavior after this commit is merged: This patch hardens account.move.line tax recomputation paths by reading tax M2M values in sudo and returning filtered results in normal env, so compute logic no longer crashes on cross-company tax records. Ticket [link](https://www.odoo.com/odoo/project.task/6036638) opw-6036638 Forward-Port-Of: odoo/odoo#260948
This update corrects a formatting issue in the e-waybill document date field. Previously, both date and time were displayed, which is not the required format. This change ensures consistent and accurate date reporting for e-waybills.
Original PR description
The `document_date` field in e-waybill form view previously included both date and time, which is not as per the expected format. This fix ensures that only the date is shown, hiding the time component. Forward-Port-Of: odoo/odoo#261253 Forward-Port-Of: odoo/odoo#259656
This update corrects a bug where the system was incorrectly searching for customers using phone numbers instead of email addresses. The change ensures customers can now be accurately found and retrieved using their email, improving customer data access. This resolves a previous issue preventing correct customer searches.
Original PR description
The email-based lookup was mistakenly checking the phone field (`phone = email`) instead of the email field. Because of this, customers could not be correctly found using their email address. This change fixes the domain to properly match on the email field. Forward-Port-Of: odoo/odoo#260567
This update resolves an issue where backorders created from returns weren't properly associated with the original return. The fix ensures the `return_id` is correctly set during the backorder creation process, allowing for accurate tracking and reporting of returned items. This improves the reliability of our inventory management system.
Original PR description
### Steps to reproduce: - Create, confirm and validate a delivery for 2 units of a product A - Click Return > Return All - Validate the return for 1 unit and backorder #### > The backorder does not belong to the return list of the delivery ### Cause of the issue: Backorder pickings are created by copying the picking to backorder: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1580-L1593 https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L1571-L1578 However, the `return_id` is a `copy=False` field that is not manully set during this copy process: https://github.com/odoo/odoo/blob/9ad995ff6b59a6a2fdfbbd6cf385fe27568dd3ea/addons/stock/models/stock_picking.py#L558 opw-6111544 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261831 Forward-Port-Of: odoo/odoo#259804
This update resolves an issue preventing the MPESA payment method from correctly processing transactions initiated by Safaricom. Specifically, it disables CSRF checks on callback endpoints and ensures URLs use HTTPS, addressing a common error related to invalid URLs. Additionally, the code now incorporates the till number for transactions, streamlining the process.
Original PR description
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will…
1. The `MPESA` payment method needs a callback url where it does a `POST` request with the transaction details. Since the call comes from safaricom, CSRF will block those requests. This commit will disable CSRF checks on the callback endpoints which are expected to be called from an external service 2. Sometimes the `web.base.url` parameter is automatically set to http. But safaricom expects https for all the urls. So we need to ensure that the urls we send on `lipa_na_mpesa_register_urls` use https, otherwise the registration fails with an `invalid url` error. Additionally, I added the error message in case of error 4. In addition to the business short code we also need a till number for transactions. Since this is stable, I've added the till number as an extension of the business shortcode field and then parse it before usage. On master there is a new PR which will properly separate the fields Task-[6045833](https://www.odoo.com/odoo/project/1737/tasks/6045833) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254993
This update resolves a technical issue where the payroll amount calculation wasn't consistently triggered when a default value was set for a specific field. The change ensures the calculation is always performed correctly, regardless of the initial default value selected, improving payroll accuracy.
Original PR description
The compute is not triggered when a default value is assigned to a field. So all property inputs default to 'fix' for amount_select. This removes the default parameter from the field and adds the default value to the compute method. task-6126332
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts for vendor bills with multiple tax repartition lines. The fix ensures accurate tax reporting by correctly summing the tax amounts when multiple lines are associated with a single tax, improving the reliability of financial data exports.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#115535 Forward-Port-Of: odoo/enterprise#110453
This update resolves an issue where incorrect Nemhandel identifiers were generated when Danish company VAT numbers with the 'DK' prefix were entered. The change removes the 'DK' prefix from CVR numbers, ensuring accurate identifier generation and a better experience for Danish businesses using Odoo.
Original PR description
Before this PR: - When a user enters a full VAT number with the 'DK' prefix in the company registry, the Nemhandel identifier becomes incorrect and results in a cryptic error being returned to the client. After this PR: - The prefix is removed if the CVR contains the 'DK' country code, to ensure the correctness of the Nemhandel identifier. task-5449059 Forward-Port-Of: odoo/odoo#261856 Forward-Port-Of: odoo/odoo#261719
This update fixes an issue where test tags containing brackets or backslashes weren't parsed correctly, preventing certain tests from running. The changes ensure that complex tag structures, including nested brackets and escaped characters, are now handled properly, improving test reliability. This resolves a technical detail that ensures consistent test execution.
Original PR description
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in…
When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]` This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]` The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets This commits fixes this two ways: Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]` Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example `.test_method[test, with brackets\], and backslash\` will work the same way. So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced. Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests. A followup pr will introduce the params to the canonical tag, and escape it as needed Forward-Port-Of: odoo/odoo#261896 Forward-Port-Of: odoo/odoo#261516
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting in the system's calculations that granted excessive access. The fix removes this setting and adds new tests to ensure this problem doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#261496
This update resolves an issue where certain expense accounts were incorrectly included in default reporting filters. Specifically, accounts related to exchange differences and early payment discounts are now properly categorized as 'Other Expenses'. This ensures more accurate financial reporting and analysis.
Original PR description
[FIX] account: Default account filter include Other Expense In "Defalut Accounts" setting, adding `expense_other` in the search domain for the following accounts: - Exchange difference entries > Loss - Early payment discounts > Early Discount Gain - Early payment discounts > Early Discount Loss task-6116375 Forward-Port-Of: odoo/odoo#259583
This update resolves a visual bug where the "Add to Cart" button appeared squeezed on product pages in edit mode. Specifically, when the Image Area is set to 33 and the purchase style is Large, the button's size was incorrect. The fix ensures the button displays its intended size across all product page layouts.
Original PR description
This code fixes a bug related to the size of the “Add to Cart” button. To reproduce the bug, you need to be on a product page in edit mode. In this mode, you must set the Image Area to 33 and the purchase style to Large. You will see that the “Add to Cart” button is squeezed. The bug occurs because, in edit mode, a new span container is added around the button to indicate that it can be edited. The fix simply adds CSS on top of this container. find-when-working-on-task-6147939 **Before** <img width="1918" height="552" alt="before" src="https://github.com/user-attachments/assets/f46c78ff-b095-4738-821b-ff52272f160d" /> **After** <img width="1913" height="1054" alt="after" src="https://github.com/user-attachments/assets/ef38a68f-acbb-439b-883d-8e3ee45c5d4a" />
This update corrects a layout problem in the Odoo spreadsheet component. After a recent code change, the spreadsheet was displaying with text flowing from right to left. This fix ensures the spreadsheet displays correctly for users in both left-to-right and right-to-left language environments.
Original PR description
When we switched from scss to a css file in the o_spreadsheet library, we exposed the library style to the automatic convertion of `rtlcss`. This process replaces the explicit `tlr`rules to `rtl`. rtlcss can ignore files/rules with inline instructions but since the library is external to Odoo and is not explicitely aware of `rtlcss`' existence, we add an explicit rule inside Odoo which will not be exposed to `rtlcss` conversion. Task-6170966 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 minor visual issue where icons within thumbnails in the email attachment list were not positioned correctly. The change adjusts the base layout to allow for overrides, ensuring a consistent and professional appearance for users. This improves the overall user experience when viewing attachments.
Original PR description
We modify the base layout to allow a fix of the icon position in an override. Task-5152517 Forward-Port-Of: odoo/odoo#249055
This pull request addresses several minor bugs in the Documents module, primarily related to file uploads and display. Specifically, it fixes issues with scrolling to uploaded files, incorrect icon positioning, and display problems with the 'You' badge under certain conditions. These changes improve the overall usability and reliability of the Documents application.
Original PR description
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file…
[FIX] documents: scroll to uploaded record How to reproduce: - install documents - open the "All" folder and ensure there is enough folder to not see any file - open the detail panel - drag&drop file in that folder The file is uploaded, but you have to scroll to it to see it. Moreover, despite the file being selected, it's not shown the detail panel. We solve the problem here by waiting the record to be rendered before scrolling to it and notify the detail panel. [FIX] documents: fix icon position in thumbnail How to reproduce: - install documents - open the chatter of a document - click on log a note, and upload a file The "trash" icon/button in the thumbnail is weirdly positioned (neither centered, neither on a border). We fix here the position the icon/button. [FIX] documents: fix "you" badge layout How to reproduce: - install documents - change the name of Mitchell Admin to a very long name - open the share panel owned by Mitchell Admin The "You" badge is not correctly displayed (the badge appears as "Y..." instead of "You" and the shape is not correct). We fix here the layout of the badge in such configuration. Task-5152517 Forward-Port-Of: odoo/enterprise#107686
This update fixes a technical issue where a promise created by the Odoo application could hang indefinitely if called multiple times quickly. The fix prevents the creation of new promises, ensuring that all requests are handled correctly and preventing performance problems. This improves overall application stability.
Original PR description
Whenever `isOnMainTab` is called, it creates and returns a new promise that will be resolved once the shared worker sends its response. However, if `isOnMainTab` is called twice in quick succession, before the shared worker answers, only the last promise is resolved, leaving the first one hanging forever. This commit fixes the issue by not recreating a promise if there is already one pending. Forward-Port-Of: odoo/odoo#262021
This update adjusts the checksum calculation for the IoT scale certification module within Odoo Enterprise. This change aligns with recent updates to the underlying IoT drivers, ensuring data integrity and accuracy for certified IoT devices. It’s a routine maintenance update to maintain the module’s functionality.
Original PR description
This PR adapts the expected checksum for the scale certified module corresponding change in iot_drivers module
This update resolves an issue where IoT-connected printers weren't correctly configured within Odoo's Point of Sale (PoS) system. Previously, these printers were unusable. This change ensures all printers, including those connected via IoT, are properly loaded and functional within the PoS environment.
Original PR description
preparation printers were not loaded in PoS as IoT devices making them unusable.