Daily updates from Odoo
Tuesday, March 10, 2026
11 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where users without project access rights would encounter errors when modifying MOs associated with private projects. The fix ensures that workers can successfully update these MOs by granting necessary read permissions to project data, preventing access errors and improving workflow efficiency.
Original PR description
When working on a MO that is linked to a project in private, it will trigger a access error if the worker is does not have project access right Steps to reproduce: ------------------- * Install Project, MRP, Accouting * Create a private project * Create a MO and link it to this project * confirm this MO with a user that has no project access right Observation: ------------- When modifying the MO, we will pass through the write that has been overwritten: https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/project_mrp_workorder_account/models/mrp_production.py#L6-L10 we will call _get_analytic_distribution on project.project and since _get_analytic_distribution will [read fields from self](https://github.com/odoo/odoo/blob/436921c24a531eba6bf57ffe3f7c3b4978139d83/addons/analytic/models/analytic_line.py#L59-L64) we need project.project read rights. opw-4919576 Forward-Port-Of: odoo/enterprise#108148
This update resolves an issue that prevented basic receipts from printing correctly when the point-of-sale (POS) name exceeded a certain length. The fix ensures that receipts are generated accurately, regardless of the POS name's length, preventing printing errors. This improves the user experience for Italian POS operations.
Original PR description
When printing a basic receipt, if the pos name is too long a traceback will occurs when printing the basic receipt. Steps to reproduce: * Create a pos with a name of 46 character or more * Setup the italian fiscal printer * Enable Basic Receipt printing * Open point of sale * Create an order and validate it * Try "Print Basic receipt" Traceback: RangeError: Invalid count value: -15 at String.repeat () If the data being printed is longer than the maximum number of character in a line (MAX_CHARS = 46), paddingLeft becomes negative which cause an error in repeat(). [Similar solution](https://github.com/odoo/enterprise/blob/18.0/l10n_it_pos/static/src/app/fiscal_printer/commands/print_rec_message/print_rec_message.js#L35) [opw-5270697](https://www.odoo.com/odoo/project/49/tasks/5270697) Forward-Port-Of: odoo/enterprise#109527
This update corrects a technical issue where German addresses submitted to Amazon were being formatted incorrectly, leading to delivery validation failures. The system now swaps the street and building/company name fields to ensure Amazon's validation process correctly recognizes German addresses. This ensures smoother order fulfillment for German customers.
Original PR description
When filling in a German address on Amazon, customers are presented with two fields: - Street, and - Building or company name. The street is sent as AddressLine2, while the building/company name is sent as AddressLine1. However, delivery providers validate address existence, which fails when address line 1 is not a street name. To resolve this, we swap these two fields for German addresses. opw-4668178 Forward-Port-Of: odoo/enterprise#109215
This update resolves an issue preventing users from setting up Amazon accounts in environments with multiple companies. The fix allows access to all company data during the onboarding process, ensuring compatibility with connected Amazon accounts. This improves the user experience and avoids errors related to company mismatches.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078 Forward-Port-Of: odoo/enterprise#109740 Forward-Port-Of: odoo/enterprise#109590
This update ensures taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, the system uses standard product tax rules for these lines, ensuring accurate tax calculations across all regions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#108821 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue where the 'Submit' button for Dutch account returns didn't actually trigger the necessary XBRL export to the tax authorities. Now, when an account return is submitted, the correct XBRL data is generated and transmitted, ensuring accurate reporting and compliance with Dutch regulations.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#109691
This update fixes a server error that occurred when merging tables in the Point of Sale (POS) system, specifically when a table was empty. The fix ensures the system waits for order synchronization before merging, preventing errors and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#104577
This update fixes an issue where the 'Today' button in the Gantt view didn't function properly when navigating from yesterday. The fix ensures the view correctly returns to the current date, improving usability and preventing users from being stuck on incorrect dates.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
This update resolves a bug where renewing a subscription while another process was closing it would incorrectly mark the subscription as churned. The fix ensures the renewal process doesn't interfere with the subscription expiration process, preventing data inconsistencies and ensuring accurate subscription status.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update corrects a bug where archived employee versions were incorrectly included in payroll pay runs. The fix ensures that only currently active employees are processed, preventing inaccurate payroll calculations and reporting. This improves data accuracy and compliance.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437
This update resolves an issue where payments with outstanding receipts accounts weren't automatically matched in the bank statement reconciliation process. The fix allows for amount matching, ensuring payments are correctly linked to invoices and bank transactions when the outstanding receipts account is active. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#108564