Daily updates from Odoo
Tuesday, September 30, 2025
31 changes · saas-18.3
New functionality added to Odoo
Adds support for legally required Turkish e-invoice scenarios including withholding VAT, tax-exempt, export, and public sector invoices. It also adds tax office information to supplier and customer e-invoice data, helping businesses meet Nilvera and Turkish regulatory requirements.
Original PR description
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension [ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices --- ### Description of the issue/feature this PR addresses: We…
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension [ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices --- ### Description of the issue/feature this PR addresses: We do not support Withholding VAT (KDV Tevkifatı), Exemption Invoices, and Export Invoices (İhracat Faturaları) with our current e-invoicing solution in Türkiye. Those invoice types are legally important and required for both domestic and international sales for businesses. In addition, the inclusion of the Tax office in our current XML we send to Nilvera, both for `<cac:AccountingSupplierParty>` and `<cac:AccountingCustomerParty>`, is required by law. This PR adds an extension module for Nilvera E-Invoicing. The purpose of this module is to extend the existing E-Invoicing functionality to support additional invoice types and scenarios to be compliant with the TR legal requirements. --- ### Invoice Scenario: **Basic** Invoice Type: - Sales - Withholding - Tax Exempt - Registered for Export **Export** Invoice Type: - Tax Exempt **Public** Invoice Type: - Sales - Withholding - Tax Exempt - Registered for Export --- ### Current behavior before PR: We don't support a scenario-based system to comply with TR legal requirements. --- ### Desired behavior after PR is merged: We support a scenario-based system to comply with TR legal requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213766
Enhancements to existing features
Email content now preserves image and element borders more reliably when formatting is converted for sending. This helps ensure emails look as intended for recipients across email clients.
Original PR description
This commit ports the following fixes to `convert_inline` of `mail`: - https://github.com/odoo/odoo/commit/8923f32426fc64e90db249fad47d7ca7e338adef [FIX] web_editor: adapt border-style value based on border widths - https://github.com/odoo/odoo/commit/7de31c6261d2fe9f58b0c6cb635977e77eecd9d6 [FIX] web_editor: ensure image border visible in emails --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228970
The self-ordering interface has been simplified by making the Get QR Code button cleaner on desktop and easier to find in the mobile menu. Settings now include a clearer option for free metal or wood stands, and menu labels better explain where users will be taken.
Original PR description
In this commit: ------------------- - Removed the QR code icon from the desktop view of the `Get QR Code` button. - Moved the QR code button from the navbar into the burger menu for mobile view. - Added a new reference option `Free Metal / Wood Stands` in settings. - Renamed the `Edit` menu item to `Settings`, to make the button functionality clear from the label as it leads the user to the settings page for the selected config. task:5003448 Forward-Port-Of: odoo/odoo#228772 Forward-Port-Of: odoo/odoo#225856
Link tracking redirects now encode URLs containing three consecutive dots so they are less likely to be blocked by certain web server configurations. This improves reliability for tracked links without changing how users create or use them.
Original PR description
Purpose ======= It has been reported that some nginx configuration detect '...' as malicious. When testing, encoding the '...' solve the issue, and so we force the encoding for the redirection URL. Task-4920533 Forward-Port-Of: odoo/odoo#229060
Resolved issues and error corrections
The CRM Periodic Digest tip now states the correct number of free credits for targeted lead generation. This avoids misleading users by changing the communicated amount from 200 credits to the actual 20 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This update corrects how the web mock server handles creating linked many-to-many records. It prevents test errors by storing the new relationship in the expected list format, improving reliability of web feature validation.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id. Forward-Port-Of: odoo/odoo#208524
The payment registration flow now checks the bank account the user actually selects, not only the account originally linked to the invoice. This prevents an incorrect warning from appearing when a trusted bank account is chosen for SEPA vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two…
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740 Forward-Port-Of: odoo/odoo#227404
SEPA payment registration now checks the bank account the user actually selects, rather than only the account originally linked to the bill. This prevents unnecessary warning banners when a trusted account is chosen, reducing confusion during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Fixes an error that could occur when users changed a website theme color from the color palette and then saved. This improves reliability of website editing and helps prevent interruptions during design updates.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
This fixes an issue that prevented website editors from modifying the cover block on the forum page. Forum page content can now be edited normally in the website builder, reducing friction for teams maintaining their community pages.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234 Forward-Port-Of: odoo/odoo#227724
This fixes a website display issue where the video size placeholder could appear even when visitors had not accepted optional cookies. The change keeps video-related elements hidden until consent is given, improving privacy compliance and avoiding confusing page content.
Original PR description
Commit [958b41c] introduced a way not to load videos if the user did not accept optional cookies. In doing so, the "video size" container was hidden. However, since [b9b3a60], the code was wrong: - Instead of a proper handler, the `optionalCookiesAccepted` listener wasn't a listener at all and immediately removed `d-none` on `media_iframe_video_size`. - It was all done in the `setup` instead of the `start` or `dynamicContent`. [958b41c]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 [b9b3a60]: https://github.com/odoo/odoo/commit/b9b3a605e0f4c5da3a258c980107d6162da7f44f Forward-Port-Of: odoo/odoo#226817
Arabic invoice reports for Saudi Arabia now display the description column with consistent alignment. This makes printed invoices easier to read and better aligned with local presentation expectations.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770** Forward-Port-Of: odoo/odoo#228118
This fixes a point-of-sale display issue where the Order button appeared highlighted after a self-order had already been sent for preparation. Staff now see a more accurate order status when opening self-orders from the ticket screen, reducing confusion during service.
Original PR description
In the POS UI, the "Order" button was wrongly highlighted when loading a self-order, even though it had already been sent Steps to reproduce: - Create an order using self-order mobile (or kiosk). - Open the related POS terminal. - Load the self-order from the ticket screen. - Notice the "Order" button remains highlighted. Fix: - Ensure the last order changes updated when loading self-order in pos Task: 5005161 Forward-Port-Of: odoo/odoo#223560
Tasks now show the allocated hours field in list view even when the value is 0. This lets users update planned time across multiple tasks without being blocked by hidden empty-hour cells.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288 Forward-Port-Of: odoo/odoo#228862 Forward-Port-Of: odoo/odoo#228188
This fix restores the correct electronic invoicing code for Dutch OIN identifiers with 20 digits. It helps ensure BIS3 and NLCIUS invoices use the expected identifier format, reducing the risk of rejected or incorrectly processed e-invoices.
Original PR description
We previously [1] fixed the EAS that was incorrectly set to 0106 instead of 0190 in case of OIN (lenght = 20). This fix was overriden in the backport of the 19.0 dict helpers [2]. [1]: https://github.com/odoo/odoo/pull/219424 [2]: https://github.com/odoo/odoo/pull/215610 opw-5107445 Forward-Port-Of: odoo/odoo#228624
Users viewing a product's inventory diagram in a newly created company without a configured warehouse will no longer hit an unexpected error. Instead, Odoo now shows a helpful warehouse setup warning, guiding users to fix the missing configuration.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178 Forward-Port-Of: odoo/odoo#227810
This update improves how Odoo communicates with Belgian POS blackbox devices, reducing delays caused by repeated failed reads from the serial port. It also improves device detection and retry handling so a newly connected blackbox is recognized more reliably and communication buffers are kept clean.
Original PR description
This commit is a backport of some parts of odoo/enterprise#93614. The goal is to ensure that we don't read too many different times from the serial port, as each read has a timeout of 3 seconds: if 2 read fail, we exceed the longpolling's timeout. We then backport the `read_until(char)` instead of `read(n)` allowing us to read not more than once (except for the lrc, which is read only if first read is successful). We also backport the supported retry, which ensures we detect a blackbox when we plug one (prevent detecting it as an Adam Scale), and correctly flush buffers after writing/reading. Task: 5116854 Forward-Port-Of: odoo/enterprise#95755 Forward-Port-Of: odoo/enterprise#95635
Helpdesk team member selection now only shows internal users when configuring automatic ticket assignment by tags. This prevents portal users from being assigned to internal helpdesk workflows by mistake, keeping team setup clearer and more reliable.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
This fix ensures the main DATEV account is only applied to companies based in Germany, preventing incorrect accounting setup for companies in other countries. It also improves how debit and credit lines are gathered, making the related reporting process more efficient.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fixes an error that could prevent users from saving certain views or Web Studio reports when an attribute entry had no name. The system now safely skips those incomplete attributes, improving reliability when editing custom views.
Original PR description
Currently, an error occurs when user tries to save a view with an attribute node without name. **Steps to replicate:** - Initialize a DB and open Views. - Create a new view and fill in random values…
Currently, an error occurs when user tries to save a view with an attribute node without name.
**Steps to replicate:**
- Initialize a DB and open Views.
- Create a new view and fill in random values for name and give a View Type.
- In the Architecture give value as `<attribute></attribute>`.
- Save and you will get the error.
(Same error can also be produced with Web Studio report editor.)
**Error:**
`AttributeError: 'NoneType' object has no attribute 'endswith'`
**Cause:**
- The error occurred because we received **key** as `None` at [1], as it was called from an attribute node with no name [2].
- In `saas-18.2`, we only checked if `node.get('name') not in TRANSLATED_ATTRS`. Since `node.get('name')` was `None` and `None` was not included in the `TRANSLATED_ATTRS` list, no error occurred.
**Solution:**
- Added a conditional check, so that attributes with no name skip the function call.
[1]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L83
[2]: https://github.com/odoo/odoo/blob/f254da2253e7ce9426e51112b513fa9e6a474ce4/odoo/tools/translate.py#L190
[3]: https://github.com/odoo/odoo/blob/0b700ec3c08ecd9c6f1597f9d10f6c1eee06bcee/odoo/tools/translate.py#L255
sentry-6877030439
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a remaining source of unpredictable behavior in an automated Web Studio rename test. It helps keep Odoo's quality checks stable so valid updates are less likely to be blocked or delayed by flaky test results.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572 Forward-Port-Of: odoo/enterprise#95447
The mobile chatter now keeps the send button visible when a user edits a message, making it possible to complete edits without confusion. The discard editing option has also been repositioned above the message composer for clearer access.
Original PR description
**Purpose of this PR:** This PR addresses UI issues in the mobile view of the chatter during message editing. - Ensures the send button is properly displayed while editing messages on mobile. - Moves the "Discard Editing" action above the composer. **Before this PR:**  **After this PR:** <img width="446" height="132" alt="image" src="https://github.com/user-attachments/assets/1842f341-268a-40e3-8915-dc08fb9162b3" /> task-[4780731](https://www.odoo.com/odoo/project/1519/tasks/4780731)
Fixed an issue where choosing a package for one selected delivery move line incorrectly assigned the same package to all move lines in the delivery. This helps warehouse staff pack the intended products accurately and avoid shipment preparation errors.
Original PR description
Steps to reproduce the bug:
- Create two storable products, e.g., “P1” and “P2”.
- Create a delivery:
- Add one unit of each product.
- Add any carrier (e.g., DHL).
- Mark the picking as "To Do".
- Set the quantity to 1.
- The move lines are created.
- Click on the Moves smart button.
- Select any move line (ML).
- Click Put in Pack.
- A wizard is triggered.
- Select any pack.
Problem:
The pack is applied to both move lines instead of only the selected one.
opw-5104034
Forward-Port-Of: odoo/odoo#228470
Forward-Port-Of: odoo/odoo#228350Fixed an error that could block users from opening the General Ledger from the Trial Balance when working with multiple selected companies in Developer Mode. The report now handles missing hidden account-code search text safely, preventing an unexpected traceback and keeping accounting navigation reliable.
Original PR description
**Issue** When multiple companies are selected and Developer Mode is enabled, clicking "View General Ledger" for an account in the Trial Balance leads to a traceback. This affects accounts whose code is hidden. **Steps to Reproduce** 1. Go to Accounting > Reporting > Trial Balance. 2. Select multiple companies. 3. Click on an account where the account code is not visible. 4. From the three-dot menu, select "View General Ledger". 5. Observe the traceback error. **Root Cause** The error occurs because the `AccountReportSearchBar` component expects a string `initialQuery` prop, but in the multi-company scenario with developer mode enabled, the value passed can be `undefined` or non-string. Owl's strict prop validation then throws an `OwlError`, leading to the traceback. **Fix** Ensure that `initialQuery` is always a string when passed to `AccountReportSearchBar`. Opw-5050843 Forward-Port-Of: odoo/enterprise#94104
Internal agents who are viewing a WhatsApp conversation without being added as members can now translate messages. This removes an unnecessary limitation and helps support teams understand customer messages while monitoring conversations.
Original PR description
Before this commit, when an agent that is not member of whatsapp but is peeking the conversation, the agent could not translate the message. This happens because the translation feature is limited to internal users, but this was determined based on the self member relational field. This works when the agent is a member but when not a member this was arbitrarily disabling the feature. This commit fixes the issue by looking at whether the user is internal or not, based on self persona independently on whether the agent is member or not of the conversation. Task-5111383 Forward-Port-Of: odoo/enterprise#95474
This fixes a test setup issue so the intended price list is always used during website sales testing, even when other price lists already exist. It helps prevent false test failures and improves confidence in pricing-related changes.
Original PR description
The `group_product_pricelist` group needs to be explicitly applied, otherwise the test fails when ran without demo data. See https://runbot.odoo.com/odoo/error/161606
Creating a salesperson from a converted lead no longer copies unrelated lead contact details by mistake. This prevents incorrect phone or mobile numbers from appearing on salesperson records, improving data accuracy in CRM workflows.
Original PR description
To reproduce: ============= 1- add a lead 2- add a phone and a mobile number 3- convert it to opportunity 4- create salesperson from that view 5- salesperson contains lead number Problem: ========= Before this fix, creating a Salesperson inherited the global context, which included unrelated values as active_model was set to crm.lead. This led to incorrect default values being applied. https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/web/models/models.py#L872C13-L872C21 The default values contained the lead phone and lead number and was applied in the creation of salesperson. Solution: ========== Since we have some synchronization of some fields (email, phone) that is automatically done normally, it's reasonable to remove the code and see what it gives. opw-4871069 Forward-Port-Of: odoo/odoo#228814 Forward-Port-Of: odoo/odoo#217545
Live chat agents who monitor a conversation without joining it can now use message translation when they are internal users. This removes an unnecessary limitation and helps agents understand and support visitors more effectively.
Original PR description
Before this commit, when an agent that is not member of livechat but is peeking the conversation, the agent could not translate the message. This happens because the translation feature is limited to internal users, but this was determined based on the self member relational field. This works when the agent is a member but when not a member this was arbitrarily disabling the feature. This commit fixes the issue by looking at whether the user is internal or not, based on self persona independently on whether the agent is member or not of the conversation. Task-5111383 Forward-Port-Of: odoo/odoo#228449
OSS tax reports can now open correctly when a fiscal position uses a country group, such as Mainland Spain, instead of a single country. This helps businesses report EU OSS taxes for regions like Spain and the Canary Islands without report access errors.
Original PR description
To be able to deal with Spain with Canary Islands and mainland, we have a country group that is Mainland Spain VAT, with Spain minus several states (Canary basically). People want to be able to use it for OSS. But currently, if you have an entry with a tax with a fp with this country group (and no country), you can't open your OSS Report. So take the countries of the country group if there is none in the fiscal position.
This update prevents errors when multiple employees are clocked in on the same Belgian POS. Sales and session closing can now continue normally in this scenario, reducing disruption for store staff.
Original PR description
- Fix traceback when trying to sell a product with multiple employees clocked in on the same POS. - Fix traceback when trying to close a session with multiple employees clocked in. task-id: 4902090 Forward-Port-Of: odoo/enterprise#93273
Features or functions removed from Odoo
An obsolete internal component in Sales External Tax was removed because invoicing now uses Odoo's standard process. This reduces maintenance overhead without changing the expected user experience.
Original PR description
The `wizard/` folder contained only `sale_make_invoice_advance.py`, which overrode `_prepare_down_payment_lines_values` but is no longer used. All functionality now relies on Odoo's standard implementation.