Daily updates from Odoo
Monday, September 8, 2025
27 changes · saas-18.3
Enhancements to existing features
The Turkish Nilvera integration now syncs statuses and PDFs for both E-Invoices and E-Archive documents, including invoices created directly in Nilvera. This makes invoice tracking more complete in Odoo, with retrieved PDFs shown in previews and attached automatically to the document history.
Original PR description
[IMP] l10n_tr_nilvera_einvoice: refactor API to include E-Invoices & E-Archive Fixed bugs in API calls triggered during fetch requests and added support for fetching the status of E-Archive files. Updated the action button label to "Sync with Nilvera", which now fetches invoice statuses, retrieves PDFs for both E-Archive and E-Invoices, and includes invoices generated directly in Nilvera, enabling support for additional invoice types currently not supported in Odoo. Invoices/Bills are marked as "Successful" once retrieved. Retrieved PDFs are displayed in the preview and automatically attached to the chatter. The original limit of fetching a maximum of 30 records (status and PDFs) is maintained. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223599
Resolved issues and error corrections
This update restores proper handling of order summary data in the Point of Sale by using the current supported method. It helps prevent errors caused by a removed internal method, improving reliability for POS users.
Original PR description
Replace usage of `serialize` (method that was previously removed) by `serializeForORM` in `OrderSummary`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes flaky automated tests around sending chat messages after entering commands in Mail, CRM Live Chat, and IM Live Chat. The change makes tests click the send button instead of relying on timing-sensitive keyboard behavior, improving confidence in release validation without changing normal user workflows.
Original PR description
\* = crm_livechat, im_livechat Back-port of 3fc3e4fbbd846dc8f65938a0bfbddbebf2abc403 Enter after typing a command will either send the message when the suggestion list is not opened yet, or select the suggestion. This can either be fixed by waiting for the suggestion list to be opened, closing it, and then pressing enter, or by simply clicking on the send button which is what is done here as the way the message is sent is irrelevant for these tests. https://runbot.odoo.com/odoo/runbot.build.error/230977 Forward-Port-Of: odoo/odoo#225874
This fixes an issue where website submenus could become invisible when using a sidebar header with a dark background. The submenu colors now adapt to the selected theme, helping site editors keep navigation readable for visitors.
Original PR description
Steps to reproduce: - Install the "Website" app. - Go to the homepage. - Click on "Site > Menu Editor" in the backend navbar. - Create a submenu. - Save the dialog. - Enter edit mode. - Click on the header. - Choose a dark background in the header options. - Choose the "Sidebar" template in the header options. - Open the submenu. - Bug: The submenu is not visible because the background and text have the same light color, so nothing can be seen. The bug was introduced by commit [1], which made visual improvements to the menu. This commit fixes it by making sure the colors of the problematic elements adapt to the theme colors. [1]: https://github.com/odoo/odoo/commit/dc1a15539227c4c21837a7bce3fc4d81858d60b9 opw-5043010 Forward-Port-Of: odoo/odoo#224610
Calendar meeting views now update correctly when developer mode is enabled, without requiring users to refresh the page twice. This prevents stale cached screens from hiding debug-only options such as the Invitations tab.
Original PR description
**Steps to reproduce:** - Go to Calendar app - Go to any meeting - Invitations tab should be hidden (no debug mode) - Trigger developer mode (`?debug=1`) - Invitations tab should be displayed - The…
**Steps to reproduce:** - Go to Calendar app - Go to any meeting - Invitations tab should be hidden (no debug mode) - Trigger developer mode (`?debug=1`) - Invitations tab should be displayed - The tab only appears after a second refresh **Issue:** The new caching process uses a key based on the RPC parameters. In the case of the 'get_views' function, it produces a different result with the same parameters depending on whether debug mode is enabled. This means that two browser refreshes are needed to have the correct view. The first refresh renders the cached view (without the invitation tab) and updates the cache with the view returned by the RPC (with the invitation tab). The new cached view with the invitation tab will be rendered on the second browser refresh. **Fix:** Add the debug option to the RPC parameters to cache the different views separately (with and without the invitation tab). opw-4986038 related: https://github.com/odoo/odoo/commit/f3d955b3235cb256bda79e834df38da0f6a4ac1a
This fixes an issue where event pages with non-Latin titles, such as Chinese, could be matched to the wrong event when editing. The update improves reliability for multilingual event websites by reading the event ID from the URL more accurately.
Original PR description
Issue: The Website Event page uses a matching regex to get the event id from the url. URLs are formatted like: '/event/[event-title]-[event-id]/register' The event-id is recovered from the url by matching on the first number that is not followed by a word character. However, for non-latin event titles (e.g. Chinese), the characters are converted using '%' characters and numbers (e.g. '%E6%88%91%E'). The regex consistently fails to get the event id in this case, and returns incorrect IDs. Steps to reproduce: 1. Install `website_event` and go to the website view of any event. 2. Edit the event, to add a Chinese title 3. Save, and try to edit again the same title. Solution: The regex is modified to look for the first number that is followed by either a "/" or the end of a String. opw-5038334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224164
The wishlist checkout test now allows more time to finish, preventing false failures when the process runs slower than expected. This helps keep automated quality checks reliable without changing the customer-facing wishlist experience.
Original PR description
Increase timeout for wishlist tour. As it was taking too long to complete. runbot-229616 Forward-Port-Of: odoo/odoo#224277 Forward-Port-Of: odoo/odoo#219653
Customers using Argentina localization can now save billing address changes during ecommerce checkout without encountering an error. The fix keeps a required tax responsibility field available in the form behind the scenes when it cannot be edited, preventing checkout interruptions.
Original PR description
Scenario: - setup company with Argentina L10N - do a sale order from partner to Argentinian company and confirm it (to make the vat not editable) - do a checkout from ecommerce from same partner to same company, and at the checkout "address" step, click to edit the billing address - click to confirm the billing address change Result: a "Cannot read properties of undefined (reading 'classList')" error happen in customerAddress._onSaveAddress because the field l10n_ar_afip_responsibility_type_id is missing from the view. Solution: similarly to c10e77ac636243025004d9ebca61af0076691f2b, add the field as hidden if it is readonly. opw-5019253 Forward-Port-Of: odoo/odoo#225579
Website livechat agents now see recent visitor page visit times in their own timezone instead of UTC. This makes the visitor activity banner easier to understand and helps agents interpret customer browsing history accurately during chats.
Original PR description
Before this PR, when browsing a website livechat in the discuss app, the banner containing the 3 last pages browsed by the user showed the utc time instead of the time in the timezone of the agent. Now, the livechat agent is seeing the visit timings in his timezone. To achieve this, we now construct the visit string in the frontend and receive the page and datetime (utc) info from the backend task-4937769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225602 Forward-Port-Of: odoo/odoo#219113
This fixes an issue where overlapping time off requests with different public holiday settings could cause an error when a public holiday was edited or created. HR teams can now manage public holidays without disrupting approved leave records for employees sharing the same calendar.
Original PR description
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to…
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to reproduce: ------------------- * Marc demo and Abigail Peterson using the same calendar * Create a "Paid time off" leave for marc demo: June 19 - June 20 * Create a "Extra time off" for abigail: same date * Update Time off type "Extra Time Off" to "Ignore Public Holidays" * Approve both leave request previously created * Create public holidays on June 19 --> traceback Observation: When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561 Why the fix: ------------ Added a new key on work_days_data to avoid the collision of two similar timeoffs. opw-4933820 Forward-Port-Of: odoo/odoo#221942
This fixes an issue in the Mail app where messages could fail when the system tried to process an empty or invalid value. The change helps keep email-related operations running reliably and avoids unnecessary interruptions for users.
Original PR description
Browse breaks when given a bool, so the solution is to filter the list from false values before browsing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where extra hours time off could be approved after refusal without reducing the available extra hours balance. This prevents employees from repeatedly using the same extra hours and keeps leave balances accurate.
Original PR description
Steps to reproduce: - On the time off dashboard, create a new leave with the type "Extra hours" - Click on the request again, refuse the request - Click on the request, and now approve the time off -If you now try to create a new time off with the type "Extra hours", you'll notice that the duration of the previously "refused then approved" time off is not taken into account Reason: The action tied to the "Approve" button was wrongly named in the inherited hr_leave model of the hr_holidays_attendance module, which prevented the computation for the approval to be taken into account. How it was fixed: Correcting the name allowed the function to be called properly and the calculation is now performed correctly. Task ID: 5051271 Forward-Port-Of: odoo/odoo#224992
This fixes analytic accounting amounts so they are rounded according to the company currency, not a foreign currency used on the journal entry. Businesses will see more accurate analytic line amounts when foreign currencies have different rounding rules.
Original PR description
Steps to reproduce: - set the rounding of a foreign currency to 1.0 - have you company currency's rounding to 0.01 - create a move with a line with an analytic distribution - post it - go to analytic line Issue: The amount will be displayed with a rounding of 1.0 and not 0.01 opw-4997047 Forward-Port-Of: odoo/odoo#225503
Spanish Veri*Factu invoices now correctly display the available regime key options in the dropdown. This prevents users from being blocked or confused when completing required invoice compliance details.
Original PR description
### Issue: The dropdown for the regime key doesn't show any value, even when it's supposed to. ### Steps to reproduce: - Install "l10n_es_edi_verifactu" and switch to a Spanish company - Create an invoice for a Spanish partner with the tax "21% G (Goods)" for example - In the page "Veri*factu" the field "Veri*Factu Regime Key" has a dropdown but no values to choose from ### Cause: This field uses the widget `dynamic_selection` which applies a filter on the possible values of the selection. This filter is simply the field `l10n_es_edi_verifactu_available_clave_regimens` which is computed from the list of possible values and the tax_ids on the invoice. As this field is computed and non stored but do not appear in the view, it is never recomputed, so the dropdown shows no values. ### Solution: Add the field in the view, and make it invisible. opw-5039271 Forward-Port-Of: odoo/odoo#225478
Inter-company sales invoices now correctly show the related lot and serial numbers when that option is enabled. This prevents missing traceability details on invoices between companies, aligning them with invoices for regular customers.
Original PR description
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2 (`partner_id`) - Validate the delivery (using SN001) - Create and confirm the invoice associated to the SO. - Print the delivery #### > The lots and serial numbers are not displayed but they would be for any other customer type. ### Cause of the issue: Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location. opw-4962700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223455 Forward-Port-Of: odoo/odoo#222492
The Time Off calendar now shows the selected employee's working schedule instead of the schedule of the person viewing it. This prevents managers and HR users from seeing incorrect days off when reviewing another employee's time off calendar.
Original PR description
Steps to reproduce: - In the Employee app, select an employee with a different working schedule than yours - Click on the "Time Off" Smartbutton - Switch from Kanban to Calendar view - The displayed working schedule is yours and not the employee's (easier to see if you and the employee have different days off) Reason: The employee_id field in the context used by the Python method was null instead of an ID, which caused the Python method to default to not use the employee's working schedule but the working schedule of the user viewing it. How it was fixed: By using a different field already present in the context, the employee's ID is correctly retrieved and used to display the calendar. Task ID: 4987732
Installing the online course sales module no longer fails if the default Services product category was previously deleted. This prevents setup interruptions and lets businesses enable course sales without manually restoring that category first.
Original PR description
Currently a `ParseError` arises when the user installs the modules after deleting the `Service` Category in Sales. **Steps to produce:-** - Install `Sales` module (without demo data). - Go to `Sales…
Currently a `ParseError` arises when the user installs the modules after deleting the `Service` Category in Sales.
**Steps to produce:-**
- Install `Sales` module (without demo data).
- Go to `Sales > Configuration > Products > Categories`.
- Delete `Services` category.
- Try to install `website_sale_slides` module.
**Error:-**
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/odoo/saas-18.4/addons/website_sale_slides/data/product_data.xml:2, somewhere inside <record id='default_product_course' model='product.product'>
<field name='name'>Course Access</field>
<field name='standard_price'>99.99</field>
<field name='list_price'>99.99</field>
<field name='type'>service</field>
<field name='service_tracking'>course</field>
<field name='invoice_policy'>order</field>
<field name='is_published' eval='True'/>
<field name='image_1920' type='base64' file='website_sale_slides/static/img/default_course_product.jpg'/>
<field name='categ_id' ref='product.product_category_services'/>
</record>
```
- The error occurs because the user deleted the category, and then installed the modules, that reference the missing product category.
- This commit resolves the error by providing a False value for the field if the product category is missing.
**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#223669This fix ensures that when a vehicle is assigned to a contact shared by employees in different companies, Odoo selects the employee from the same company as the vehicle. This prevents incorrect driver records and assignment logs in multi-company fleet setups.
Original PR description
There is a bug when multiple employees from different companies are linked to the same contact. Steps to reproduce: - Create two employees, in two different companies that relate to the same contact (partner) - In one of the two companies, create a vehicle and assign it to the partner created - The field driver_employee_id in the vehicle and assignation log will be assigned to one of the two employees, without taking care of the company of the car To fix this, the domain should also contain the company of the car, and must match the company of the employee. task-4978443 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#221154
This fixes a timing issue that could affect sending messages with Command + Enter in enterprise discussion and live chat areas. The change helps prevent inconsistent behavior during automated checks and improves reliability for users relying on keyboard shortcuts.
Original PR description
\* = test_discuss_full_enterprise, website_helpdesk_livechat Back-port of 14b31a3631a97dd61ebd662fb768485e5a509c2c Enterprise counter-part. https://runbot.odoo.com/odoo/runbot.build.error/230977 Forward-Port-Of: odoo/enterprise#94078
When users open a Bill of Materials from the Master Production Schedule edit popup, the popup now closes automatically. This prevents a confusing leftover popup and avoids an error when users cancel it after navigating away.
Original PR description
Before this commit: ------------------------- Clicking the BOM field in the edit production schedule pop-up on the MPS page redirected the user to the BOM form view, but the pop-up remained open in…
Before this commit: ------------------------- Clicking the BOM field in the edit production schedule pop-up on the MPS page redirected the user to the BOM form view, but the pop-up remained open in the background. If the user then clicked Cancel on the pop-up, it created a traceback error. Steps to reproduce: ------------------------- 1. Install 'mrp_mps' module. 2. Go to Planning → Master Production Schedule. 3. Click the pencil icon next to a product. 4. In the pop-up, click the BOM value to navigate to the BOM. 5. Notice that the pop-up stays open even after redirection, and closing the pop-up raises a traceback error. Cause of the issue ------------------------- When your onClose arrow function directly executes this.reload(productionScheduleId) without curly braces, it immediately hands over the outcome of that function call to the dialog system. Since this.reload is an asynchronous operation with multiple sequential return values, its immediate outcome may not be a final value. After this commit: ----------------------- The pop-up is automatically closed when navigating to the BOM form view from the BOM field in the Edit Production Schedule popup, ensuring a cleaner and more intuitive user experience. Task Id: 4886331
Managers can now create employee appraisals as expected. This removes a workflow blocker for performance review management and adds test coverage to help prevent the issue from returning.
Original PR description
fixed with https://github.com/odoo/enterprise/commit/d4b708d22c0c3768cbb50bd5a43e91db419ff277 added test to cover the use case opw-4794641
Point of Sale now checks connected IoT device status less often, reducing unnecessary background activity. This helps improve performance for businesses with large product databases while keeping device monitoring available.
Original PR description
We currently check the status of the connected devices every 5s. This is used in only a short selection of the devices and the delay is unnecessarily short. For databases with a lot of products this can unnecesarily slow down their PoS This PR increases the loop until 60s opw-5006302 Forward-Port-Of: odoo/enterprise#92615
Fixed a barcode transfer issue where lot-tracked kit components could be combined with the same component listed separately. This prevents unnecessary backorders when warehouse staff scan and validate the correct quantities.
Original PR description
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating **Steps to reproduce:** - create two products tracked by lot (comp A and comp B) - set an on hand quantity for both - create a storable product (final product) and create a BOM - in the BOM add comp A and comp B - create an internal transfer for 1 final product and 1 comp B - click on "mark as todo" - open this transfer in barcode, we see that the two lines from the comp B are grouped - scan the source location, click on +1 and +2 button to fulfill the quantities and validate **Current behavior:** a backorder is created **Expected behavior:** no backorder should be created as we entered the right quantities of the picking **Cause of the issue:** the lines from comp B should not have been grouped in the barcode picking. When doing the same scenario but with product not tracked those lines are not grouped opw-4998766 Forward-Port-Of: odoo/enterprise#93759 Forward-Port-Of: odoo/enterprise#93262
The update adds a log warning when automated bank statement reconciliation is started in a way that ignores its intended time limit. This helps administrators spot configuration or integration issues that could otherwise make bank statement imports run longer than expected.
Original PR description
When calling `_cron_try_auto_reconcile_statement_lines` with a `limit_time` argument but without a `batch_size`, the time limit was silently ignored. With this commit, we display a warning in the logs, because this is probably not the desired behavior. Besides that, when the amount of statement lines become large, it might hang the import of bank statements longer than the expected 3 minutes. Task-id: None
This update cleans up how automated test helpers are referenced in Odoo Studio tests. It keeps the testing tools easier to maintain while limiting the change to internal unit tests, reducing risk for customers.
Original PR description
## Pull Request HOOT (PRHOOT) 36 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/221367 Forward-Port-Of: odoo/enterprise#93950 Forward-Port-Of: odoo/enterprise#93167
This fixes an issue where UrbanPiper delivery providers that staff disabled were automatically re-enabled after returning from the backend and continuing sales. Provider status is now preserved centrally, reducing unexpected changes and avoiding unnecessary update requests when resuming a POS session.
Original PR description
Steps to reproduce: - Configure urban piper in pos.config - Open Register - You could see a notification that providers are online on your config - Disable any one provider. - Go to backend. - Click Continue Selling Issue: - Despite disabling the provider, all providers get enabled as soon as we resume the pos.config Cause: - Not updating togglestate properly while going to the backend. - Unnecessary api request when resuming session. Fix: - Not removing the toggleState from local storage as the user go to the backend - When the user resumes the session, restrict api request for location update. - Remove dependency from local storage and handling all through backend only. task- 4962969 Forward-Port-Of: odoo/enterprise#93119 Forward-Port-Of: odoo/enterprise#90987
Code cleanup and technical improvements
This update cleans up internal test code by routing shared web test helpers through a single intended access point. It does not change customer-facing features, but helps keep the codebase easier to maintain and reduces future test conflicts.
Original PR description
This commit reduces imports to the 'tests/_framework/' subfolder, which is meant to be accessed through the 'web_test_helpers' module as to reduce the amount of imports, as well as centralizing all web helpers to have a quick overview of the available helpers. Enterprise: https://github.com/odoo/enterprise/pull/94074 Originally contained within the following pull request: https://github.com/odoo/odoo/pull/225744 But has been separated for convenience sake since the original PR was involving security overrides, and would be consistently interrupted by conflicts ensuing from this specific commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr