Friday, August 29, 2025
9 changes · 18.0
New functionality added to Odoo
A new Indian localization module adds support for managing port codes used when e-Way Bills involve air or sea transport. This helps businesses create compliant e-Way Bill data for shipments that pass through Indian ports.
Original PR description
Introduced a new module to manage Indian port codes, specifically for transport modes classified as Air or Sea in the e-Way Bill system. see - https://github.com/odoo/upgrade/pull/8170 Task-3638761 Forward-Port-Of: odoo/odoo#221503
Adds a new Poland localization feature to record and display the taxable supply date on invoices. This helps Polish businesses meet local tax reporting requirements more accurately when invoice date and supply date differ.
Original PR description
This new module aims at adding support for taxable supply date in Poland. task-4829233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The Turkish Nilvera integration now syncs more invoice types, including E-Archive documents and invoices created directly in Nilvera. Users can retrieve statuses and PDFs from one renamed "Sync with Nilvera" action, with documents shown in previews and attached to the invoice chatter.
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
Resolved issues and error corrections
This fix ensures mail records that are already marked for deletion are no longer treated as active records by internal business logic. This reduces the risk of crashes and incorrect data handling during record deletion and recomputation.
Original PR description
Before this commit, business code could leak records that are soft deleted, i.e. the representation of the record is still in the store but conceptually this record is deleted. These soft-deleted…
Before this commit, business code could leak records that are soft deleted, i.e. the representation of the record is still in the store but conceptually this record is deleted. These soft-deleted records are present in the code for a very short time, just enough time to warn business code in the onDelete() hooks. The problem for Model.records and Model.get() to return these records, is that the business code thinks these records are not deleted, which can lead to misuses and crashes. For example: if a computed field returns this soft-deleted record, then the field value has this soft-deleted record. When the record is hard-deleted, this field will be recomputed, but when diffing with its old this will crash because it will still have a trace of the record in the internal code. This commit fixes the issue by removing the record from Model.records when soft-deleted, so that Model.records and Model.get() doesn't return this record. The onDelete() hooks will returned the soft-deleted like before because the deleted records are stored in the data queue of the hooks. This solution also solves another problem: if a record is deleted and there's an immediate side-effect computed field to insert this record, the previous implementation would hard-delete the record at the end which is wrong: the record should be deleted but the insert part should apply, thus the resulting record is a fresh one with same identity but only partial data from the insert. All other field values must be lost from the deletion. The changes in this commit also fixes this issue. Commit also fixes issue for `.exists()` that should be `false` for soft-deleted records. Task-4860196
Fixed an issue where public holidays spanning multiple days could appear as only one blocked day in calendar views for employees or companies using flexible working schedules. This makes holiday calendars clearer and consistent with the existing time-off validation that already prevented requests across the full holiday period.
Original PR description
**Issue**: Multi-day public holidays only display as single days in calendar views when using flexible working schedules. A 3-day holiday appears as only 1 day blocked, though time-off requests are still correctly prevented for all 3 days. **Cause:** In `_get_unusual_days()`, the implementation for flexible schedules only captures the start date of each leave interval https://github.com/odoo/odoo/blob/132938929d46c8248a9e3a7e2972174ae38eacfa/addons/resource/models/resource_calendar.py#L683-L685 **Steps to reproduce:** 1. Configure a flexible working schedule for an employee or company 2. Go to Time Off > Public Holidays 3. Create a 3 day public holiday 4. Check Time Off calendar view Only 1 day appears blocked instead of all 3 days opw-4997757
When the same POS order is open on multiple devices, other devices now detect when it has already been finalized. This prevents staff from trying to edit a completed order and redirects them to the appropriate next screen or a new draft order.
Original PR description
Before this commit, if two devices were working on the same order and one of them finalized the order, the other device would not be aware of this change. This was leading to error, since a finalized order is not editable anymore. This commit adds a hook to track the finalized order on the product, payment and split bill screens. When the finalized order is detected, the user is redirected to another screen or a new draft order is created, depending on the screen. taskId: 4788430
Installing the Manufacturing app on very large databases is now less likely to run out of memory or time out. The change improves how existing stock movement records are prepared during installation, reducing disruption for customers with high data volumes.
Original PR description
Description ----------- On large databases with millions of already existing `stock.move`, the post-install computation of compute stored fields can be time-consuming and memory intensive. This commit extends the pre_init_hook that was done in `mrp` to: - Speed up computation of `stock.move.is_done` - Implement SQL query to initialize `stock.move.manual_consumption`. Reference --------- opw-4980036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes kiosk online payments so paid orders are properly sent onward for preparation instead of only showing a confirmation screen. It also limits kiosk payment choices to the online methods configured for that kiosk and makes single online-payment setups show the QR payment flow correctly.
Original PR description
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are…
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend. Steps to reproduce: ------------------- * Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup * Create an online payment method (use demo for example) * Change the kiosk settings to use those two payment methods * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The fix to send the order to the backend is in the other part of this fix. Here we decide to only allow to use the online payment methods that have been set on the config. Previously if two were existing but only one setup you were able to select any of them. We also make a change to the `filterPaymentMethods` method. This method is called when pressing the pay button and is indirectly responsible for the fact that if there's only one payment method then we directly start the payment process. Prior to this fix if we only had a terminal method setup and clicked to pay an order we directly had the screen telling us to follow the instructions on the terminal. However if we only had a online payment method, when clicking on pay, we would directly have the screen prompting us to pay at the register, we could never select the payment method. With the fix, when there's only one payment method and it's online, clicking on pay will show the qr code. opw-5001998 Enterprise: https://github.com/odoo/enterprise/pull/92825
Kiosk orders paid with an online payment method are now correctly sent to the preparation display after payment. This prevents staff from missing paid self-order kiosk orders that customers already see as being prepared.
Original PR description
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are…
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend. Steps to reproduce: ------------------- * Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup * Create an online payment method (use demo for example) * Change the kiosk settings to use those two payment methods * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ We bring back the code from the previous version which allowed orders to be sent to the preparation display: https://github.com/odoo/enterprise/blob/c4da0b5136f44a1437300844f6a06f44c5d79631/pos_self_order_preparation_display/models/pos_order.py#L12-L19 We also precise the sending condition in order to avoid to recompute the function which is already called in other setup. opw-5001998 Community: https://github.com/odoo/odoo/pull/223689