Daily updates from Odoo
Monday, June 15, 2026
15 changes · 19.0
Resolved issues and error corrections
This update resolves a technical issue that prevented users from correctly resizing task pills in the Gantt view when no dependent tasks were involved. The fix ensures the system handles empty rescheduling lists gracefully, preventing a crash and maintaining proper Gantt functionality. This improves the overall stability and usability of the project scheduling feature.
Original PR description
Steps to reproduce: - Create a project with task dependencies enabled - Create a task with planned dates and no dependent tasks - Open the Gantt view - Select Auto-Reschedule (Use Buffer or Keep Buffer) - Shrink the task pill by dragging its right edge to the left Issue: A traceback occurs: ValueError: max() iterable argument is empty Cause: when no dependent task needs to be rescheduled, the candidates is empty and max() is called on an empty list. Solution: Check that candidates exist before computing the maximum deadline from the dependent tasks. task-6268332 Related PR https://github.com/odoo/enterprise/pull/113787
This update resolves an issue where inactive and archived taxes were incorrectly displayed in the bank reconciliation widget. The fix ensures that only active taxes are available for selection, improving data accuracy and preventing users from selecting irrelevant tax codes during reconciliation processes. This enhances the reliability of financial reporting.
Original PR description
### Issue:
When editing a line within the bank reconciliation widget, inactive and archived taxes are incorrectly available for selection
### Cause:
The bank reconciliation edit line form view carried the `{'active_test': False}` context on the `tax_ids` field
This context allowed archived taxes to be loaded and selected during creation and manual edition
### Fix:
Explicitly force `active_test: True` in the view context for the tax field to ensure only active taxes can be searched and selected by the user
### Steps to reproduce:
- Install `account_accountant`
- Create a new tax and set it to inactive
- Go to the Bank Reconciliation widget
- Create a bank statement line
- Set the account to 600000 Expenses
- Edit the line by clicking on the pencil icon
- Open the Taxes selection dropdown
Before the fix, the inactive tax is visible and available for selection by default
opw-6245641This update corrects a bug in the Datev ledger export that previously miscalculated currency amounts. The fix ensures that tax and currency values align with the invoice's currency, improving the accuracy of the exported data for Datev reporting. This resolves discrepancies between the database and the Datev export.
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 wouldn't correctly update during an Odoo upgrade from 17.0 to 18.0. The fix ensures that demo data is processed correctly, validating leave allocations regardless of the installation method (fresh or upgrade).
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
A technical issue prevented users with limited time-off permissions from accessing the Attendances Gantt View when viewing leave requests. This fix ensures that the Gantt View correctly displays leave information for all users, regardless of their access rights. The change uses a security enhancement to correctly access necessary data.
Original PR description
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee…
Version: - 19.0 Steps to reproduce: - Install Attendances and Time Off - Create an internal user. - Give the user: Attendances Officer access & No Time Off Officer/Manager rights - Create an employee linked to the user. - Configure the employee with a Flexible Working Schedule. - Create and approve a Time Off request for the employee. - Open: Attendances -> Gantt View - Navigate to the month containing the employee's approved leave. Issue: - An access error is raised when opening a month that contains the employee's approved leave. Cause: - In `_handle_flexible_leave_interval`, the code accesses `leave.holiday_id` to read fields such as `request_unit_half`, `request_unit_hours`, and `request_hour_from/to` on the `hr.leave` model. - When the current user has Attendances Officer rights but no Time Off access(rare cases), the ORM access check on `hr.leave` raises an AccessError, even though this read is purely for internal calendar computation and does not expose leave data to the user interface. Fix: - Added sudo() on holiday_id to access the employee's leave details and compute the work interval as expected. Task-6264510
This update ensures that data associated with IoT boxes used in point-of-sale systems is protected when those boxes are removed from the system. Previously, deleting an IoT box could lead to data loss. Now, the system verifies that the box's fiscal data isn't currently in use before allowing deletion, safeguarding important sales information.
Original PR description
Before unlinking an iot.box from the database, we must ensure that its fiscal data module is not currently used in any pos.config. task-id: 5144489
This update corrects a calculation error in the GOSI (Saudi Government Social Insurance) payroll contributions for employees with unpaid leave. The fix prortions contributions based on worked days, accurately reflecting employee attendance and ensuring correct deductions. This improves payroll accuracy and compliance in the Saudi Arabia region.
Original PR description
Task: 6279514
This update resolves an issue in the website editor for renting products where removing the quantity field caused an error. The fix ensures the system gracefully handles scenarios where the quantity field is no longer present, preventing tracebacks and improving user experience. This change was introduced in version 19.0.
Original PR description
Before this commit, the function `setAddQtyInputMax` in `/website_sale_renting_planning/static/src/interactions/website_sale.js` assumes `this.el.querySelector("input[name='add_qty']");` will always return not null but you can remove this field through the website error and cause a traceback.
https://github.com/odoo/enterprise/blob/c1d47899c90fcfa426e1863887111d3ea9f6f15e/website_sale_renting_planning/static/src/interactions/website_sale.js#L18-L39
Steps to reproduce issue:
Runbot 19.0
Open renting -> Products
Select a product (preferably one created by default runbot setup) Click the smartbutton to go to this products web page Open the website editor
Click Edit
Under the styles tab, de-select the quantity field See error message
**Only happens in 19.0**
Introduced in https://github.com/odoo/enterprise/commit/89962571c246caf05e669bb63ad933e67e74ab61
opw-6294612This update addresses a missing rule in the calculation of employer costs within the Odoo Enterprise HR module. Following a review, a crucial rule was added to ensure accurate cost determination, building upon previous improvements. This ensures compliance and accurate reporting of employer costs.
Original PR description
In this previous PR https://github.com/odoo/enterprise/pull/106839 the computation of the employer cost was fixed and many rules were flagged as needed in that computation. After a report, we found one of the rules was missing so we add it in this PR. Task: 6088412
This 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.
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
This update fixes a security vulnerability where users without approval permissions could incorrectly interact with approval requests, leading to errors. The change restricts access to 'Accept' and 'Refuse' options within approval activities to only the designated approver, enhancing security and preventing unintended actions.
Original PR description
Currently when a user submits an approval request, an activity is created for the approver who can validate or refuse the request directly from the activity, however these options are also visible to other users who will trigger an error if interacting with the options. This commit removes these options for users who are not the approver. **Steps to reproduce:** - Log in as admin - Go to approvals - Select dropdown menu of General Approval and Edit - Change documents to optionnal - Make sure admin is in the approvers list - Log in as demo - Go to approvals -> General Approval -> New Request - Submit the request - You'll see an activity be created for admin, with Accept and Refuse options - If you select any of these options you will get an access error opw-5423528
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. This improves 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 fixes an issue where the reconciliation reporting dialog was not displaying draft journal items, leading to an inaccurate count. By removing a default filter, the dialog now shows all matching items, providing a more complete and reliable reconciliation view. This improves the accuracy of financial reporting.
Original PR description
The reconcile badge counts draft and posted journal items, but the matching dialog forces a posted filter by default, this makes the dialog show fewer lines than count as it discards the draft ones. Remove the default posted search filter so the dialog displays all matching items. task-6234801
This update resolves an issue where project names weren't correctly synchronized with their linked folder names when multiple projects were edited simultaneously. The fix ensures that folder names are updated consistently during multi-editing operations, improving data accuracy and streamlining project management workflows.
Original PR description
Currently, when user multi-edits projects names from list view the linked folder name doesnt get updated. Steps to replicate: - Install `documents_project` and open projects. - Select multiple projects and edit their names. Issue: - The project names get updated but their respective linked folder's name doesnt get updated. Cause: - During multi-edit, `self.documents_folder_id` contains the folders of all selected projects. - As a result, `len(self.documents_folder_id.project_ids) == 1` [1] is evaluated on the combined recordset instead of per project, causing the condition to always fail when multiple projects are renamed. Solution: - Avoided accessing `self.name` on a `multi-recordset` during multi-edit. - Filtered projects individually and updated their document folders using the name in vals. [1]: https://github.com/odoo/enterprise/blob/3c2985ca6011700c271ed14e40e08c89be822753/documents_project/models/project_project.py#L101 sentry-7452096418
Code cleanup and technical improvements
This update refactors the bank statement import controller to avoid conflicts with other Odoo modules. By using a more generic controller and removing unnecessary code, the import process is now more reliable and efficient. This change ensures consistent behavior and reduces potential errors.
Original PR description
account_bank_statement_import_view was using the same controller used in account.move which caused some wrong behavior when some logic isn't shared between both modules, now account_bank_statement_import uses a generic controller that doesn't add unneeded behavior. As well as removing all of the account move classes from bank statement import and using generic ones or ones specific to account bank statement import. task-5892419