Daily updates from Odoo
Monday, June 15, 2026
7 changes · saas-18.4
Resolved issues and error corrections
This update resolves two issues related to attaching documents to employee records. Previously, attachments were created in the root employee folder, which was inconvenient. Now, attachments are correctly created, including those for sick leave, ensuring proper document management for employee records. This improves the user experience and data integrity.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811 Forward-Port-Of: odoo/enterprise#112993
This update corrects an issue in the Datev ledger export, ensuring accurate currency calculations. Previously, the system incorrectly used the company currency instead of the invoice's currency, leading to discrepancies in reported values. This fix ensures Datev exports reflect the correct financial data.
Original PR description
There is an issue in the Datev export functionality. In the current functionality, the code calculates a delta between the taxes in the `tax_totals` and the ones on the journal items. Issue is, the tax amounts from tax_totals were always in company currency, while the entry itself can use a foreign one. This replaces the use of company currency with the use of the invoice's currency and appropriately adjusts the test featuring foreign currency. Steps: Create a foreign currency. Create an invoice with a taxed product using the currency. Export the ledger to Datev. Inspect the resulting csv. Note that neither the final listed price, nor the rate listed for the currency align with the ones in the db. opw-6275889 Forward-Port-Of: odoo/enterprise#120293
This update resolves an issue where demo leave allocations weren't correctly processed during an upgrade from Odoo 17 to 18.4. The fix ensures that leave allocations are properly validated and updated, preventing data inconsistencies and ensuring the Indian Payroll demo data functions correctly in both new installations and upgrades.
Original PR description
Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them…
Steps: - Install an Odoo 17.0 database with the Indian Payroll module and demo data. - Upgrade the database to 18.0. Issue: - The Indian payroll demo data creates leave allocations and approves them through an XML function call. - During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'. - However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function: - This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'. - When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition. - As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading. Fix: - Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'. - As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios. runbot error-https://runbot.odoo.com/odoo/error/230430 task-6268381 Forward-Port-Of: odoo/enterprise#119217
This update fixes a bug that prevented proper error messages from appearing when new IoT Boxes encountered scaling problems. Previously, the system didn't correctly display error information, making it difficult to diagnose and resolve issues. This ensures users receive clear notifications about scale errors, improving troubleshooting and operational efficiency.
Original PR description
This completes odoo/enterprise#11196, which missed error message handling for new IoT Boxes errors. `message_body` was undefined on `data.status` when `data.status === "error"`. <img width="1871" height="942" alt="image" src="https://github.com/user-attachments/assets/30b54c5b-da0d-497d-8d9e-912f7139140b" /> Forward-Port-Of: odoo/enterprise#119425 Forward-Port-Of: odoo/enterprise#119228
This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds on payslips. Swiss payroll regulations limit payments to one per month, so the system now guides users to cancel and re-create a payslip for any necessary adjustments. This ensures compliance with Swiss tax laws.
Original PR description
Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943
This update resolves an issue where expense descriptions weren't automatically translated when using different database languages (like French). The fix ensures that OCR-extracted descriptions are correctly applied, preventing the expense title from remaining stuck on a placeholder and improving the accuracy of expense data across all Odoo environments.
Original PR description
### Issue On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language When an expense is first generated up to 19.0, it…
### Issue
On Runbot, trial, and client databases, the automatic extraction of the description does not work when a user changes the database language
When an expense is first generated up to 19.0, it requires a name and is temporarily given a localized placeholder like "Dépense sans titre..." in French
When the OCR results arrive, the system is supposed to detect this generic fallback string and overwrite it with the real extracted description
However, because of a language mismatch, the system fails to recognize its own placeholder. It incorrectly assumes the user manually entered that text and, to prevent losing user data, refuses to replace it
Before the fix, the title remains stuck on the placeholder
In very rare cases, the translation applies correctly, but it fails most of the time
### Cause
The OCR successfully finds the correct description, but in `_fill_document_with_results`, the expense name is not replaced
This seems to happen because `self` in `self._get_untitled_expense_name("")` carries a residual context that could override the correct language to use during the automated extraction process
Even though the user record and the detected language are correctly set to the alternative language, `default_receipt_name` appears to be generated in English ("Untitled Expense")
This would cause the subsequent string comparison with the actual translated name stored in the database to fail, blocking the update
### Fix
I made some tests in some generated RunBot and the user is correct and also the associated lang
I supposed self was containing lang details overriding the correct language to use
`self.env['hr.expense'].with_context(lang=user_id.lang)` seems to be working
### Steps to reproduce
The issue cannot be reproduced locally, follow these steps on a Runbot instance:
- Retrieve IAP OCR credentials from a trial database
- Enable Developer Mode in Settings
- Go to Settings -> Technical -> IAP -> IAP Accounts
- Add the credentials for the Document Digitization service
- Go to the Expenses app
- Change the user's language to French
- Import the expense image from the ticket
- Open the newly created Expense and click Refresh
Before the fix, the title should stay `Dépense sans titre...` If it's not the case, try a second import, it works times to times
opw-6103935
Forward-Port-Of: odoo/enterprise#118661This update resolves a technical issue where the Urbanpiper order information screen incorrectly displayed customer details even after the customer was removed. The fix ensures that customer information is only shown when a valid customer is associated with the order, improving the user experience and preventing unexpected errors.
Original PR description
Steps to reproduce: ==== - Place an order through Urbanpiper. - Edit the order and remove the customer. - Open the ticket screen and click the info button. - A traceback occurs. Cause: ==== - Customer details were rendered even when no customer was linked to the order. Fix: ==== - Display customer details only when a customer is present on the order. task-6233812 Forward-Port-Of: odoo/enterprise#120290 Forward-Port-Of: odoo/enterprise#118147