Monday, September 8, 2025
12 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 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
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
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
This 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
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
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