Monday, October 6, 2025
15 changes · saas-18.2
Enhancements to existing features
Adds automated tests for the Turkish Nilvera e-invoice integration, covering API communication and invoice file handling. This helps reduce the risk of regressions and improves confidence that Turkish e-invoicing continues to work correctly in future updates.
Original PR description
There are no tests for the Turkish e-invoice module. This commit adds that. Task ID: 4655864 Forward-Port-Of: odoo/odoo#228010 Forward-Port-Of: odoo/odoo#216179
Brazilian service products now show the correct LC116 Code label instead of the product-focused Mercosul NCM Code label. This reduces confusion when configuring fiscal information for services and improves the explanatory tooltip.
Original PR description
Purpose:- - In Brazil, NCM is a code that has an acronym to specify the Mercosul Common Name for products, and for services, the right name is LC116 (Complementary Law 116), which specifies the federal code for a service. - But we have the same field `l10n_br_ncm_code_id` to configure both NCM for goods and LC116 for services and the same table can be used for both the cases. - So while configuring fiscal information for a service, user don't understand why it still shows the NCM label instead of LC116. Before this commit:- - Label `Mercosul NCM Code` was displayed for services confusing users. After this commit:- - Label `Mercosul NCM Code` is replaced with `LC116 Code` only for services. - Tooltip is also improved for better understanding. task-5096435 Forward-Port-Of: odoo/enterprise#96101 Forward-Port-Of: odoo/enterprise#95404
Resolved issues and error corrections
Users who dismiss the email validation confirmation banner will no longer see it reappear unexpectedly. This reduces confusion after email validation notifications are acknowledged.
Original PR description
### Issue Closing the banner triggered `/profile/validate_email/close` RPC, which reset `validation_email_done` to false. This mistakenly caused the “email sent” banner to reappear, confusing users. ### Solution Set `validation_email_sent = False` so the banner stays hidden after being closed. Task-5049533 Forward-Port-Of: odoo/odoo#225872
Miscellaneous changes
Steps to reproduce: - Create an invoice through Accounting app - Post the invoice - Register the payment using the "Register Payment" wizard with an electronic payment method. Description of the issue/feature this PR addresses: **The payment transaction was not being linked to the invoice for electronic payments.** To resolve this, I passed the current invoice IDs as context through action_register_payment in the account.move.line model. Then, I retrieved this context value in _prepa
Original PR description
Steps to reproduce: - Create an invoice through Accounting app - Post the invoice - Register the payment using the "Register Payment" wizard with an electronic payment method. Description of the issue/feature this PR addresses: **The payment transaction was not being linked to the invoice for electronic payments.** To resolve this, I passed the current invoice IDs as context through action_register_payment in the account.move.line model. Then, I retrieved this context value in _prepare_payment_transaction_vals of the account.payment model to set the invoice_ids Many2many field. Current behavior before PR: The payment transaction is not linked to the invoice for electronic payments. Desired behavior after PR is merged: The payment transaction will be correctly linked to the invoice for electronic payments. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197091
Event descriptions in outgoing emails now handle embedded links more safely so Gmail does not split or break the event URL. This helps recipients open event pages reliably from their email invitations and confirmations.
Original PR description
When website_event is installed an anchor tag is added inside the event description which is guaranteed to break the url in the gmail client. We now quote the description appropriately so that there's no confusion. task-5092759 Forward-Port-Of: odoo/odoo#228359
Deleting an invoice that had been queued for postal mail now also removes the related mailing record. This prevents the scheduled mail-processing job from crashing on missing invoice data, keeping postal invoice handling reliable.
Original PR description
When an account move linked to a snailmail letter is deleted, the cron ``Snailmail: process letters queue`` crashes with a traceback. Steps to reproduce the error: - Create a new invoice > Confirm > Send > Select ``By post`` > Send - Reset to Draft > Delete the invoice - Run the cron ``Snailmail: process letters queue`` Traceback: ``` MissingError Record does not exist or has been deleted. (Record: account.move(1,), User: 1) ``` Solution: Ensure that when a move is deleted, its related Snailmail letters are also deleted. sentry-6883768061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents crashes when certain waiting steps finish without returning a value. It makes website interaction behavior more reliable for developers and reduces the risk of small technical patterns causing visible issues.
Original PR description
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
Contacts in the Dominican Republic can now use valid 11-digit Cédula tax identification numbers, not only 9-digit RNC numbers. This prevents valid customers or partners from being rejected during VAT validation and improves local compliance support.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224507
The Accounting dashboard upload areas and drag-and-drop buttons now automatically match the active visual theme. This removes mismatched hardcoded colors, improving readability and consistency for users in dark mode and light mode.
Original PR description
Current behavior before PR: - Drag & drop buttons and upload drop zones of dashboard cards had hardcoded backgrounds (#F2EDF0 / grey), which did not adapt to dark mode. Desired behavior after PR is merged: - Removed hardcoded background colors from drag & drop button and upload drop zone cards on dashboard and updated their background to adapt in light & dark modes. Changes implemented: - Removed hardcoded background color (`#F2EDF0`) from `account_drag_drop_btn` & `drag_to_card` CSS classes. - Removed overriding background-color property from `o_drop_area` CSS class. - Updated background-color of `o_drop_area` in `o_account_dashboard_kanban_view` CSS class to `o-view-background-color`. task-5092460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227707
Exporting a Belgian 325 PDF no longer crashes when there are no related 281.50 forms to include. Instead, users see a clear message explaining that they need to record a transaction with a 281.50 tag before generating the PDF.
Original PR description
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment…
### Problem When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**: This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present. --- ### Steps to Reproduce 1. Go to **Accounting → Reporting → 325 Form**. 2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**. 3. Do not generate any 281.50 forms (`form_281_50_ids` is empty). 4. Click **Export PDF**. **Result before fix:** - Crash with `IndexError: list index out of range`. --- ### Solution - Added a safeguard check before accessing attachments. - If no attachments exist, raise a **UserError** instead of crashing. **New behavior:** > *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”* This gives users a instruction on how to resolve the issue. --- ### Result After Fix - **User error message** replaces traceback. - **Normal behavior preserved** when attachments exist: - One file → direct download. - Multiple files → zipped download. --- task-5090120 Forward-Port-Of: odoo/enterprise#94877
This fix prevents Odoo Studio from crashing when users remove calendar settings such as the color field. Empty values are now handled correctly instead of being mistaken for invalid field names, making view customization more reliable.
Original PR description
On a calendar with studio, try to remove the "color" attribute, or any other that should contain the name of a field. Before this commit there was a crash because the value sent to the server in this case is `undefined` (`null` in JSON or `None` in python), which was stringified and yielding an actual string that was not a field name After this commit, NULL values are not stringified, instead they should represent the emptiness of the attribute. opw-4938351 Forward-Port-Of: odoo/enterprise#95439
This update changes how encoded document data is passed when sending reports to IoT devices, avoiding a compatibility issue with customizations. It helps prevent errors in existing customer modules while preserving the same document sending behavior.
Original PR description
Following commit https://github.com/odoo/enterprise/commit/ecea27f45ab58ae6f348753d94fdf89f902a43b9, the argument `data_base64` was added to the `render_and_send` function. However, adding new arguments in stable versions is not allowed, as it may break custom modules that override this function and do not expect the additional argument. This commit ensures that `data_base64` is passed through the context instead, preventing errors while keeping compatibility with existing overrides. opw-data_base64 Forward-Port-Of: odoo/enterprise#96244
Failed attempts to send shipping labels to an unreachable IoT printer no longer show an error traceback to users. This avoids alarming employees who received a shared print request even when another user may have successfully printed the label.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. As multiple users can receive the broadcasted message at the same time, but might not be able to reach the printer, we need to avoid displaying a traceback on failure. Note that as it is broadcasted, a user could receive the traceback even if label was already printed by the user that was on the same network as the IoT Box. Also note that we don't even display a notification as it would be displayed to every user connected that couldn't reach the IoT Box. Task: 4792491 Forward-Port-Of: odoo/enterprise#96054 Forward-Port-Of: odoo/enterprise#95794
Field Service project settings now show the correct label for the timesheet product when a customer is selected. This avoids confusion caused by the sales order line label appearing in the wrong place.
Original PR description
Steps to reproduce: - Install the `industry_fsm_sale` module. - Open the FSM app. - Go to Projects. - Open a project’s settings. - Select a customer. Issue: The label for the timesheet product is not displayed. Instead, the label for the sale order line appears on FSM projects. Cause: In the PR, https://github.com/odoo/odoo/pull/128967 changed the project settings form structure by wrapping `sale_line_id` in a `div` and separating its label, breaking the xpath for `timesheet_product_id`. Fix: - Update the XPath for `timesheet_product_id` to target the correct container. - Hide the `sale_line_id` label on FSM projects. task-4581748 Forward-Port-Of: odoo/enterprise#96022
Employees with flexible working hours no longer see Saturdays and Sundays incorrectly marked as unavailable in the timesheet grid. This prevents confusion for teams whose schedules allow work on any day.
Original PR description
To reproduce: ============= 1- Update employee worktime to be flexible 2- Go to timesheets -> saturday & sunday are marked grey Problem: ======== Can't apply https://github.com/odoo/odoo/blob/ce2d134d3e8e5c0d96529c1d0490f1e0c5e28294/addons/resource/models/resource_calendar.py#L511 This logic cannot be applied when an employee's work time is flexible, since they can work whenever they want. Fix: ==== When employee work time is flexible we just return empty list for the unavailable dates. opw-5031144 Forward-Port-Of: odoo/enterprise#94346