Daily updates from Odoo
Monday, February 9, 2026
8 changes · 17.0
Resolved issues and error corrections
This update resolves a bug where importing journal entries in foreign currencies could fail due to rounding discrepancies. The issue stemmed from individual line rounding, leading to an imbalance between debit and credit. This fix ensures journal entries with foreign currency transactions can be reliably imported and balanced.
Original PR description
**PROBLEM** If you create/import a journal entry using a foreign currency, it can happen that the journal entry is balanced in said foreign currency but isn't balanced in the company currency,…
**PROBLEM** If you create/import a journal entry using a foreign currency, it can happen that the journal entry is balanced in said foreign currency but isn't balanced in the company currency, preventing you from creating/importing the journal entry. When creating the journal entry, you could add a line to balance this, but if you import it, you can't. **STEP TO REPRODUCE** 1. Set the exchange rate: 1€ = 0.134068$ 2. Import the journal entry named issue.csv (can be found in the ticket page or the PR). **CAUSE** Because we round each line individually, we may end up with a rounding issue that leads to debit/credit not being equal. opw-4668369 | Reference | account_move_journal.id | Date | Journal Items / Account | Journal Items / Currency | Journal Items / Amount in Currency | |-----------|--------------------------|---------|-------------------------|--------------------------|------------------------------------| | Bunq | Miscellaneous Operations | 8/15/25 | 1010 | EUR | -34.9 | | | | | 1050 | EUR | 34.9 | | | | | 1100 | EUR | 2.69 | | | | | 1200 | EUR | 32.21 | | | | | 1300 | EUR | -34.9 |€
This update fixes a discrepancy where quote PDFs were incorrectly displaying customer addresses even when the 'Customer Addresses' setting was disabled. The fix mirrors the behavior of invoices, ensuring that quotes consistently show only one address when this setting is active. This improves data accuracy and a better user experience.
Original PR description
## Versions 17.0+ 16.0 too but template change is not worth risking stable policy. ## Issue There is a behavior mismatch between invoices and quotes/orders addresses display. Disabling "Customer…
## Versions
17.0+
16.0 too but template change is not worth risking stable policy.
## Issue
There is a behavior mismatch between invoices and quotes/orders addresses display. Disabling "Customer Addresses" setting should only display one address on generated documents. Yet, it has no effect on quotes and orders while it has on invoices.
## Steps to reproduce
- Go to Settings:
- Look for "Customer Addresses";
- Ensure the box is checked (and save).
- Go to Sales / Orders / Customers:
- Create a new customer and add addresses under the "Contacts & Addresses" tab:
- Add one "Delivery Address";
- Add one "Invoice Address" (with different values).
- Click the "Sales" smart button to create a new quote for that customer:
- Add any product;
- From the cog, click Print > PDF Quote.
- Confirm the order (deliver if needed);
- Create regular invoice;
- Confirm the invoice;
- From the cog, click Print > Invoices.
- Both documents display a shipping address.
Start again with "Customer Addresses" setting disabled and watch the shipping address disappear from the invoice while still present on the quote document.
*N.B.: Same behavior with the preview*
## Fix
Mimic invoices' behavior in https://github.com/odoo/odoo/blob/1bd2d63eb80020e6e213c889e83cca2950d4dcd4/addons/account/views/report_invoice.xml#L12
opw-5400368This update fixes a potential issue where external users could be assigned activities within Odoo. A new filter has been added to the system to ensure activities are only assigned to internal employees, improving data accuracy and security.
Original PR description
Description: Added an domain on the 'activity_user_id' field in the mail_activity_schedule_views xml file. The domain blocks the assignment of activities to users who are not internal. task-5424577
This update corrects a reporting issue where unreserved stock was incorrectly included in the stock in transit forecast. The fix ensures that only non-available quantities are considered, providing a more accurate view of inventory movement for sales forecasting. This improves the reliability of sales order predictions.
Original PR description
**Issue** It is possible to have unreserved quantity, outside the stock location, considered as 'stock in transit' in the forecast report. This is an issue because that means some quantities, that…
**Issue** It is possible to have unreserved quantity, outside the stock location, considered as 'stock in transit' in the forecast report. This is an issue because that means some quantities, that are not meant to be moved to the stock location, are linked to a delivery. **Steps to reproduce** - Activate 3 step receipt on your warehouse - Create a new product 'Test' and adds 1 Unit in WH/Input and 1 Unit in WH/Quality - Create a sales order for 2 Units and check the forecast report of Test -> 2 units are recorded as 'stock in transit' links to the so delivery while they should not. **Cause** The forecast report is computed here: https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L17-L24 The lines are computed here: https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L125 Currently, stock in transit is calculated by: Aggregating quantities per product and location (including unreserved quantities): https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L327-L328 Removing the reserved stock, then summing per product: https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L353-L354 Assigning the result as 'stock in transit' (since free_stock is 0 here): https://github.com/odoo/odoo/blob/f0196258ed41f56790db94747192545ae56c78b5/addons/stock/report/stock_forecasted.py#L361 This method incorrectly includes unreserved quantities from intermediate locations. **Solution** Since we only want non-available quantity to be considered as stock in transit, we use the reserved quantity instead. No need to substract the free quantity anymore since free quantity are no reserved by definition. opw-5865378
This update resolves a problem where project breadcrumbs disappeared after migrating databases from older versions to the latest. The change ensures correct breadcrumb functionality when opening projects from sale orders, particularly after upgrading from version 16. This improves the user experience and data visibility.
Original PR description
Steps to reproduce: 1. Create a db with having 'sale' & 'project' installed in version 16. 2. Create a sale order having linkage to more than single project. 3. Migrate the db to version 19. 4. When…
Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.
Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)
When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17
This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.
OPW-5448916
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-prThis update simplifies the initial setup for new employees in the payroll module. The system now automatically generates a unique employee ID and sets the marital status to the employee's birthday by default for single individuals. This streamlines the onboarding process and reduces manual data entry for HR staff.
Original PR description
For quality of life improvement, the unique employee identification is now automatically generated and initial marital status date is set to the birthday by default if the person is single
This update standardizes the way time off and absences are recorded and transmitted for payroll reporting in Switzerland (CH). It backports a fix from the main Odoo repository, ensuring accurate and compliant reporting by aligning views and data structures related to leave management.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/f238e04f3f6c39b61d0449a0766809df06eb6980 task-5384297
This update enhances the stability of our payroll accounting tests by ensuring all server-side processes are fully completed before tests conclude. This prevents inaccurate database state assertions and improves the reliability of test results, leading to more confident releases.
Original PR description
Wait for signature completion in tours to ensure server-side side-effects are finished before the test ends and asserts the database state. runbot-224112