Tuesday, September 23, 2025
19 changes · saas-18.3
Resolved issues and error corrections
Odoo now protects the default barcode setup record from being deleted. This prevents crashes when users disable and re-enable the Barcode Scanner setting, keeping inventory barcode configuration reliable.
Original PR description
The system will crash with error when user tries to enable barcode scanner in settings. **Steps to produce: -** - Install `Inventory` module. - `Inventory > configuration > products > Barcode…
The system will crash with error when user tries to enable barcode scanner in settings.
**Steps to produce: -**
- Install `Inventory` module.
- `Inventory > configuration > products > Barcode Nomenclatures`.
- Delete the `Default Nomenclature` record.
- Go to settings uncheck `Barcode Scanner` and save settings.
- Now, again `enable` that and save.
Error: -
```py
ValueError: External ID not found in the system: barcodes.default_barcode_nomenclature
ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/stock_barcode/data/data.xml:40, somewhere inside <record id='scale_up_alias_1' model='barcode.rule'>
<field name='name'>Scale Up Receipt</field>
<field name='type'>alias</field>
<field name='pattern'>WH-RECEIPTS</field>
<field name='alias'>WHIN</field>
<field name='barcode_nomenclature_id' ref='barcodes.default_barcode_nomenclature'/>
<field name='sequence'>0</field>
</record>
```
**Root cause: -**
- At [1], the records use the ref of `default_barcode_nomenclature` which is defined in barcode module. So, when the ref is deleted and we are trying to use it then it gives error.
**Solution: -**
- This commit resolves the error by prevent the deletion of `default nomenclature`.
[1]: https://github.com/odoo/enterprise/blob/400171c9cebc46ecdd907ada210c65f3bbd2dd66/stock_barcode/data/data.xml#L40-L71
**sentry-6823596992**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226594Timesheet users can now edit the Time Spent value in list view and move focus away without the field reverting to the previous value. This prevents confusion and helps ensure newly entered or adjusted time remains visible before saving.
Original PR description
Steps to reproduce: ----------------- 1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time. 2. Change time in the Time Spent field. 3. Press Shift + Tab. Observation:…
Steps to reproduce: ----------------- 1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time. 2. Change time in the Time Spent field. 3. Press Shift + Tab. Observation: ----------------- The focus changes, but the Time Spent field reverts to its old value instead of keeping the newly entered one. Issue: ----------------- - For new records, the component retrieves the value only from the state, which is updated in the `onWillUpdateProps` lifecycle. This lifecycle triggers only on saving or editing, not when simply changing focus. https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L123-L128 - The same behavior occurs when editing existing records, leading to incorrect value display. https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L31-L33 Solution: ----------------- - For new records, since the default value is 0, the fix makes the component fall back to the updated record value if the state value is not yet available. - For existing records, if the timer is running, the timer’s value is displayed. otherwise, the component falls back to the updated record value. opw-4922847 Forward-Port-Of: odoo/enterprise#95141 Forward-Port-Of: odoo/enterprise#94729
Credit notes for Mexico’s general public tax regime now keep the selected “Returns, discounts or bonuses” usage when allowed by current SAT rules. This prevents XML documents from being generated with the wrong usage value, helping businesses issue compliant credit notes without manual correction.
Original PR description
**Steps to reproduce:** 1. Install `l10n_mx` and `l10n_mx_edi`. 2. Create an invoice with: * Enable *CFDI to Public*. * Confirm, then send to SAT. 3. Create a credit note with: * *Usage* = `Returns,…
**Steps to reproduce:** 1. Install `l10n_mx` and `l10n_mx_edi`. 2. Create an invoice with: * Enable *CFDI to Public*. * Confirm, then send to SAT. 3. Create a credit note with: * *Usage* = `Returns, discounts or bonuses` (G02). 4. Download the generated XML for the credit note. **Observed behavior:** - The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects). **Expected behavior:** - The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected. **Root cause:** - For regime 616 (`Público en general`), the code always defaults to `S01`. - The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes. **Solution:** - Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616. **ref:** http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls opw-5012917 Forward-Port-Of: odoo/enterprise#93071
Field service sales orders with zero-priced service lines now correctly show as invoiced after the related invoice is created and posted. This prevents orders from remaining incorrectly marked as needing invoicing, reducing confusion during billing follow-up.
Original PR description
Steps: - Install sale and fsm module. - Enable anglo-saxon from the setting. - Create a service type product with fsm project as template. - Select that product on SO and set unit price to 0 on SOL. - Confirm that order and create and post invoice. Issue: - Sale order status still shows `To invoice` even though we create SOL related invoice. Cause: - In [PR] we made invoice status for anglo-saxon line `To Invoice` so it always say `To Invoice` even user create related invoice. Fix: - Make those lines `Invoiced` if there is related invoice by checking qty_invoiced is greater or equal to qty. [PR]: https://github.com/odoo/enterprise/pull/70132 opw-5055540 Forward-Port-Of: odoo/enterprise#94723
This change fixes an access problem in the self-ordering feature that could block public users from completing expected actions. It helps keep the customer ordering flow reliable without requiring unnecessary sign-in or extra permissions.
Original PR description
bypass Public user ACLs. build_error-231606
Sendcloud shipments can now include longer customs classification codes, matching the carrier API limit. This helps avoid customs delays for affected international parcels, especially shipments to the US.
Original PR description
**PROBLEM** We limit the `hs_code` length to 8 characters, but if we refer to the [sendcloud v2 api doc](https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/schemas/parcel-item), we see that `hs_code` length can be up to 12 characters. Some clients have issue with parcels being held longer in custom when sending them to the US. [opw-5051585](https://www.odoo.com/odoo/project/49/tasks/5051585) Forward-Port-Of: odoo/enterprise#94894
Field service tasks now create sales orders using the product's currency when calculating line prices. This ensures prices are converted correctly when the product and sales order use different currencies, preventing incorrect billing amounts.
Original PR description
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any…
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any employee and any service. - Return to the task and in the Timesheets tab, add a new timesheet. - Click the Mark as done button. - Click the Sales order button. ### Cause: When creating the sale order out of the fsm task we use _get_tax_included_unit_price to get the price of the SO line but we are passing the order currency twice to this method so it doesn't convert the price as when it checks the currency and the product_currency it found they are the same so no need to convert https://github.com/odoo/odoo/blob/6653355b8bc063ceadf08af17fbf2c4a250553e6/addons/account/models/product.py#L239-L240 ### Fix: We pass the product currency instead of the order currency in order to be able to convert the price according to the currencies opw-5045071 Forward-Port-Of: odoo/enterprise#95134 Forward-Port-Of: odoo/enterprise#94947
This fixes missing timesheet entries when public holidays are deleted or their work calendar changes after employee leave has already been approved. Businesses get more reliable time tracking and fewer manual corrections around holiday and leave overlaps.
Original PR description
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating…
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating Timesheets. Validate it. - Expected: on the day of the public holiday, no timesheet is generated for the `hr.leave` to avoid duplication. - Either delete the public holiday, or set a calendar on it different than the one defined on the employee. - Issue: the public holiday timesheet has been deleted, but its deletion should've lead to the creation of the `hr.leave` timesheet that we didn't create at the time the public holiday existed. - Second issue: after that, change the calendar of the public holiday to the same as the employee's. Still a missing timesheet. **Solution** We can use `_reevaluate_leaves` to find the leaves affected by changes in public holidays. `_generate_timesheets` then re-generates the timesheets as if the leave was just validated (the call to `list_work_time_per_day` ignores the already present resource.calendar.leave). We also check missing public holidays timesheets to fix the second issue. opw-4819697 Forward-Port-Of: odoo/odoo#225066 Forward-Port-Of: odoo/odoo#216901
This fix stops users from editing the amount in currency on posted journal items where it could leave invoices with inconsistent totals and related analytic data. The field is now only editable for tax lines while the entry is still in draft, helping preserve accurate accounting records.
Original PR description
- Create an invoice with some products and post it - Go to Accounting > Journal items and ser for the ones belonging to the invoice. - Set the checkbox for the product sales one and set whatever tax…
- Create an invoice with some products and post it - Go to Accounting > Journal items and ser for the ones belonging to the invoice. - Set the checkbox for the product sales one and set whatever tax grid (you'll have to reveal that column). - Accept the changes. - Now go back to the invoice. - You'll see a new tracking message. Something like Journal Item #1093 updated - It contains a link and from that link you can go to the journal item form. - In that form you can edit the *amount in currency* field. Issue: - If a user do so, it leaves inconsistent invoice amounts: totals aren't recomputed, analytic lines aren't recomputed either. How it should behave: - Amount in currency shouldn't be editable here. Mainly when the journal entry is already posted! opw-4951629 A vídeo showing the issue: 📹️ https://www.loom.com/share/f7cd1d8f4138458f9b6c190233b0b9df?sid=eec77c17-a4a6-4698-8604-10aaa7e33f47 MT-10887 cc @moduon --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225346 Forward-Port-Of: odoo/odoo#223187
Invoice imports now avoid linking lines to unrelated products when the item name is very short, such as “-” or “a”. This reduces incorrect product assignments on imported accounting documents and improves data accuracy.
Original PR description
hen resolving a product in _retrieve_product, the code searched by barcode, default_code, and then by name using both exact and ilike domains. For very short item names coming from imports (e.g., “-”, “A-1”, “0001”), the ilike fallback could match unrelated products whose names merely contain that short string. this led to incorrect product linkage on created documents (e.g., EDI-imported invoices). discussed with: Christophe (chkl) Steps to reproudce: Accounting -> Invoices upload an XML with a product name liek `-` or `a` See the product attched to the invoice line. opw-5003482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225143
Odoo now avoids crashing when printing PDF quotations for multiple sales orders if one of the selected orders cannot generate a valid PDF. Incomplete or problematic orders are skipped so users can continue producing quotations for the rest of the selection.
Original PR description
Description of the issue/feature this PR addresses: This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises…
Description of the issue/feature this PR addresses: This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail. Current behavior before PR: Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data. Desired behavior after PR is merged: After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227517 Forward-Port-Of: odoo/odoo#227347
This change prevents public website visitors using older Safari versions from seeing a crash when pages load. It adds browser compatibility support needed for translation caching, improving reliability for affected users without changing normal functionality.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). 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
The point of sale payment screen now correctly keeps the Validate button disabled on mobile when no payment method has been selected. This prevents cashiers from accidentally proceeding with incomplete payments and improves checkout reliability on mobile devices.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#94132 Forward-Port-Of: odoo/enterprise#94100
Brazilian service invoices using AvaTax now send installment amounts without tax values, preventing mismatches that could cause invoice rejection. This improves reliability when processing service invoices with installment payments.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95244 Forward-Port-Of: odoo/enterprise#85108
Large online stores can now generate product sitemaps without exhausting server memory. This helps prevent crashes caused by search engine crawlers repeatedly requesting sitemaps for very large catalogs.
Original PR description
### Issue Server crashes with MemoryErrors when a database has a large product catalogs. ### Solution This commit disables the prefetcher to avoid MemoryErrors when generating the sitemap for large product catalogs as web crawlers would continously crash the server when requesting the sitemap. ### References opw-5001680 opw-4955333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223054
Appointments linked to resources now appear in the calendar views where users expect to find them. This restores visibility after the removal of the previous “Everybody’s Calendar” option, helping teams manage resource bookings without missing scheduled appointments.
Original PR description
**Steps to reproduce:** - Install Appointment app - Create a new resource - Create an appointment type with the new resource - Create an appointment for this type - Go to the Calendar app or to Appointments > Schedule > Resources Bookings - Click on the calendar view - The new appointment can't be found **Issue:** As "Everybody's Calendar" option was removed, there is currently no way to display the appointments on resources in the calendar view. **Fix:** Added a `calendar.resource.filters` model and its flow to the calendar view. It was also necessary to revert the parallel fetching of filters in https://github.com/odoo/odoo/commit/aa5f2d5dc3b7c64217cea57535b04261e801c4d2 to ensure the order of filters remains constant. related: https://github.com/odoo/odoo/commit/08ceb41a47de5ee1a0758eb0ebba3a3c6964a2f9 opw-4964405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointments linked to resources can now be found and displayed in the calendar view again. This restores visibility for resource bookings after the previous shared calendar option was removed, helping teams manage appointments without missing bookings.
Original PR description
**Steps to reproduce:** - Install Appointment app - Create a new resource - Create an appointment type with the new resource - Create an appointment for this type - Go to the Calendar app or to Appointments > Schedule > Resources Bookings - Click on the calendar view - The new appointment can't be found **Issue:** As "Everybody's Calendar" option was removed, there is currently no way to display the appointments on resources in the calendar view. **Fix:** Added a `calendar.resource.filters` model and its flow to the calendar view. related: https://github.com/odoo/odoo/commit/08ceb41a47de5ee1a0758eb0ebba3a3c6964a2f9 opw-4964405
Cancelling a sales order after creating multiple nested returns no longer triggers a system crash. This improves reliability for teams handling returned deliveries and prevents disruption during order cancellation.
Original PR description
The system crashes with a `RecursionError` during the `Sale Order` cancellation with nested `returns`. **Steps to produce:-** - Install the `Purchase Stock` and `Sales` modules. - Create a new `Sales Order` (SO) with `Product A`. - Confirm the `Sales Order` and click on the `Delivery` button. - Click on `Return > Return all`. - In the new window, also click on `Return > Return all`. - Return to the `Sales Order` and attempt to `Cancel` it. **Error:-** `RecursionError: maximum recursion depth exceeded` **Solution:-** - Added a check for the self not already visited in the method `_get_upstream_documents_and_responsibles` to prevent revisiting the same move multiple times and `avoid infinite recursion`. **Sentry - 6693197358** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227992 Forward-Port-Of: odoo/odoo#217113
The Mexican e-invoicing flow now handles customer names entered with accents in the self-invoicing portal. This prevents valid invoice requests from failing when government records store the same legal names without accents.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207