Daily updates from Odoo
Navigate
Branch
Saturday, December 6, 2025
13 changes
3 changes
Resolved issues and error corrections
This update resolves an issue where the automatic generation of PEPPOL endpoints for Belgian companies was failing due to invalid characters in the company registry. The fix adds specific validation rules to ensure only valid Belgian VAT identifier characters are used, improving the accuracy of PEPPOL endpoint creation.
Original PR description
When company registry contains characters such as dots (.), automatic fill-up of peppol_endpoint field fails because dots are valid peppol identifier characters, but are clearly not part of belgian VAT identifier. The solution is therefore to add an EAS-specific set of valid characters to prevent this situation no-task Forward-Port-Of: odoo/odoo#238356
This update resolves an issue where the server logger was experiencing excessive logging activity, leading to potential performance slowdowns. The change reverts a recent update that increased the logging frequency, restoring a more stable and efficient logging process. This ensures data is recorded reliably without impacting system performance.
Original PR description
Based on this review of https://github.com/odoo/odoo/pull/238740 this pr reverts the flush interval to 0.5s introduced in https://github.com/odoo/odoo/pull/238648 to avoid queue saturation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238912
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time zones differed from UTC. The change ensures that calendar event times are correctly aligned with the employee's time zone, improving the accuracy of time off scheduling.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375 Forward-Port-Of: odoo/odoo#237818
2 changes
Resolved issues and error corrections
This update resolves an issue where the server logging system was experiencing excessive queue buildup. The change reverts a recent update that increased the logging frequency, restoring a more stable and efficient logging process. This ensures data is recorded reliably without performance bottlenecks.
Original PR description
Based on this review of https://github.com/odoo/odoo/pull/238740 this pr reverts the flush interval to 0.5s introduced in https://github.com/odoo/odoo/pull/238648 to avoid queue saturation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238912
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time off was scheduled in a timezone different from UTC. The change ensures that calendar events correctly display the actual start and end times of time off requests, improving accuracy and usability.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375 Forward-Port-Of: odoo/odoo#237818
4 changes
Enhancements to existing features
This update strengthens our testing process for access controls within the VoIP module. Previously, tests relied on manual data manipulation, which was prone to errors and difficult to maintain. Now, tests utilize a more reliable method – 'has_access' – ensuring consistent and accurate verification of access rights.
Original PR description
In our tests for access rights, we manually do CRUD operations to check them. However, this approach is difficult to maintain and highly susceptible to changes in model fields. Therefore, we are switching to using has_access function for more robust verification. Forward-Port-Of: odoo/enterprise#101456
Resolved issues and error corrections
This update resolves a bug that prevented users from correctly navigating tax returns on mobile devices. The fix ensures the correct class is applied, allowing users to seamlessly return to the tax returns view after viewing a specific return. This improves the user experience for mobile users.
Original PR description
To reproduce the error : Occurring in 19.0 and maybe before Open the tax returns view on mobile view Click on a return Click on the arrow to go back to the returns view Fix : The class was not there so the props was getting a null. Solution : Added the class to be selected correctly task: 5334639 Forward-Port-Of: odoo/enterprise#101079
This update resolves a crash that occurred when users attempted to add bank statement lines to journals other than the default. The fix ensures the correct journal is selected during transaction creation, preventing data inconsistencies and improving stability.
Original PR description
The system will crash when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the…
The system will crash when user tries to create new bank statement line. **Steps to produce:** - Install `Invoicing` module without demo data. - Go to `Configuration > Journals` and duplicate the default Bank journal to create `Bank (Copy)`. - Dashboard and `Click on 3 dots` of Bank(Copy) and click on Transactions. - Create a new transaction and set the Statement also(Create new and assign it). - Go to that statements and Add a line and set the `foreign currency` as USD. **Error:** `ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)` **Cause:** - When we try to create a transaction in a statement of a non-default journal, its journal is not set by default, resulting in two records being fetched. At line [1], our code attempts to read `statement_id.journal_id` , but encounters multiple records, causing the issue. **Solution:** - Here I added context to pass `journal_id` as default and made `payment_ref` required(because at [2], also we do the same). - Also added hidden `journal_id` field in the list view. [1]: https://github.com/odoo/odoo/blob/ec2d8d026d9f13c8fb869ad1f7b8026a144e85ec/addons/account/models/account_move.py#L887 [2]: https://github.com/odoo/enterprise/blob/bff451101bb23b4f9acc7982ed1138d7cefa13b9/account_accountant/views/bank_rec_widget_views.xml#L220 **sentry-6928858335** **opw-5256565** Forward-Port-Of: odoo/enterprise#98995
This update significantly speeds up VAT report generation by removing a slow check and cleaning up outdated data. It also corrects a critical issue where users lacked access to returns, preventing accurate reporting across all company branches. This ensures data integrity and a smoother user experience for financial reporting.
Original PR description
The "No negative amount in VAT report" return check was too slow, we removed it and clean the database. On the other hand, refreshing checks had issues with the access rights when there was company branches. task-id: 5145537 Forward-Port-Of: odoo/enterprise#98633 Forward-Port-Of: odoo/enterprise#97125
3 changes
Resolved issues and error corrections
This update resolves an issue where the automatic PEPPOL endpoint field in Belgian company registrations (containing characters like dots) was incorrectly filling in. The fix adds specific valid characters for EAS, ensuring accurate PEPPOL endpoint generation and preventing errors related to Belgian VAT identifiers.
Original PR description
When company registry contains characters such as dots (.), automatic fill-up of peppol_endpoint field fails because dots are valid peppol identifier characters, but are clearly not part of belgian VAT identifier. The solution is therefore to add an EAS-specific set of valid characters to prevent this situation no-task Forward-Port-Of: odoo/odoo#238356
This update ensures that the delivery address is now correctly included in requests for tax calculations and EDI documents (NF-e invoices). Previously, this information was missing, which could lead to tax discrepancies. This change is crucial for accurate tax reporting and seamless EDI processing.
Original PR description
Purpose: For invoice goods(NF-e), the delivery address can differ from the invoice address. It is necessary for both fiscal and logistical reasons to provide the delivery address in the tax calculation and EDI requests. Failure to do so may result in tax issues for the issuer. Expected Behavior: Users will be able to set a delivery address on the sales order and invoice and the delivery address will be sent in the requests for tax calculation and EDI. The returned EDI document will display the delivery address information. Current Behavior: The delivery address is not sent in the requests. task-5171186
This update ensures that when stock is spread across multiple locations for a Lot/Serial Number, the correct location is always displayed in the system. Previously, the location was incorrectly set to 'False', preventing users from seeing where the stock was actually stored. This improvement enhances inventory tracking and accuracy.
Original PR description
Fixed (Issue #237701 ) Description of the issue/feature this PR addresses: When a Lot/Serial Number has positive stock spread across multiple locations, the field lot.location_id is currently set to False Current behavior before PR: The Lot/Serial form shows no location Users cannot see where the stock actually exists If stock exists in multiple locations → the location is cleared (False) Desired behavior after PR is merged: Users always see a stock location when stock exists A valid stock location will still be shown instead of None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update fixes an issue where time off calendar events weren't accurately reflecting the start and end times, particularly when time off was scheduled in a timezone different from UTC. The change ensures that calendar events now correctly display the actual start and end times of time off requests, improving accuracy and usability.
Original PR description
**Steps to reproduce** - Have all timezones (browser, employee, working schedule...) aligned on an diffrent timezone than UTC (normal flow). - Take a time off for a half day, or in custom hours and validate it. Issue: the associated calendar event created doesn't match the time off start/end. **Cause** Commit 8c8c38b1d57971aa5ef220f720d4aeea86b6de98 converts the times from the time off (in UTC) to the leave's timezone, this is an issue because `start` and `stop` of `calendar.event` should be in UTC. **Change** The conversion makes sense for allday events, as the `start`/`stop` are not in UTC (see `_inverse_dates` in `calendar_event.py`, they represent a date used for the display of the event, but for non-allday events we have to make sure the `start`/`stop` are the actual times of the leave. opw-5225375 Forward-Port-Of: odoo/odoo#237818