Tuesday, March 10, 2026
16 changes · saas-18.4
Resolved issues and error corrections
Timesheets now select the intended sales order line when billing rates are configured across companies. This prevents work from being linked to the wrong billable item, improving invoicing accuracy for multi-company projects.
Original PR description
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific…
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user. **Expected:** The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list. **Steps to reproduce:** - Be in a multicompany environment: company A and B - Create User with access to both but only one employee record for company A - Switch to company B - Create 2 services product, both creating a task in the same project. - Activate Billable Rate Indicators in the settings - Create a quote with both services and confirm - Go to the related project, and in the Invoicing tab, link employee from company A to SOL2 - As the user, check both companies but set company B as current active - Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured. opw-5159195 Forward-Port-Of: odoo/odoo#234200
Point of Sale event ticket registrations now reliably save all attendee answers, including free-text responses when no multiple-choice questions are used. This prevents missing registration details after payment validation and improves data completeness for event organizers.
Original PR description
## Steps to reproduce: - Configure event registration with only free-text fields (no selection field). - Open the POS, add an event ticket product, and fill in the registration form. - Click Payment…
## Steps to reproduce: - Configure event registration with only free-text fields (no selection field). - Open the POS, add an event ticket product, and fill in the registration form. - Click Payment and validate the order. ## Issue: - Registration answers were only sent to the backend when at least one selection-type question was filled. - When no selection field was present, free-text answers were not synced at all. ## Reason: - The `registration_answer_ids` and `registration_answer_choice_ids` One2many fields on EventRegistration both point to the same `registration_id` Many2one field on EventRegistrationAnswer. https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/event/models/event_registration.py#L83-L85 - This caused data loss during the POS model synchronization, as entries were overwritten in the `inverseMap`. https://github.com/odoo/odoo/blob/c738d049fe09101bd14dce0710c2659a4a6eca39/addons/point_of_sale/static/src/app/models/related_models/model_defs.js#L59-L75 ## Fix: - Send all registration answers (free-text and selection-based) exclusively via `registration_answer_choice_ids`. task-5438565 Forward-Port-Of: odoo/odoo#242465
This fix prevents Saudi POS settlement payments from being incorrectly forced through ZATCA invoicing when the original invoice was already reported. It also blocks mixed settlement-and-sale orders where partial ZATCA reporting is not supported, reducing reporting errors and compliance risk.
Original PR description
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both…
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag. From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders. # Current behavior before PR With ZATCA enabled on saas-18.2: - Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account. - Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines. - This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported. - Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported. # Desired behavior after PR is merged After this fix: - ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag. - Even if invoice is checked, the invoice is not sent to ZATCA - Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing. - Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting. This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244712
Taiwan ECPay features now activate based on a company's fiscal localization rather than its physical address. This helps businesses using Taiwan fiscal settings get the correct ECPay behavior even if their company address is outside Taiwan.
Original PR description
Previously, the module checked `company_id.country_id.code == 'TW'` to determine if Taiwan's ECPay logic should be applied. However, `country_id` only represents the physical address of the company. This commit replaces `country_id` with `account_fiscal_country_id` across the sale order model and website controllers. This ensures that the ECPay integration correctly triggers for any company using the Taiwan fiscal localization. Task-6002433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252373 Forward-Port-Of: odoo/odoo#251924
This fix prevents dashboards from failing to load when a user lacks permission to read one of the underlying data sources. Users who can access a dashboard can now open it normally, while existing access rights are still respected for readable data.
Original PR description
## Description When opening a dashboard, `_dashboard_is_empty()` may call `search_count()` on one of the dashboard's main data models to decide whether sample data should be loaded. If the current user does not have read access to one of these models, `search_count()` raises an access error and the dashboard loading can fail, even though the user has access to the dashboard itself. To avoid this, only unreadable models are checked with `sudo()`, while readable models are still evaluated with the current user rights. This prevents the access error in `_dashboard_is_empty()` and allows the dashboard to open instead of failing early. Task: [5905166](https://www.odoo.com/odoo/project/2328/tasks/5905166) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249784
Manufacturing orders created on mobile now correctly keep the work order instructions from the bill of materials. This helps shop floor teams see the guidance they need when using mobile devices, avoiding missing instructions during production.
Original PR description
# How to reproduce - Create a BOM for a product with a Work Order - Add instructions to the WO - Using mobile, create a new MO for the product # The problem The instructions are not linked to the MO. This can easily be seen via the shop floor application # Why This issue is identical to https://github.com/odoo/odoo/pull/197889. This commit https://github.com/odoo/odoo/commit/b1ceec4c616d8ad2fee5b0fa1ce76c85cacbb344 removed the operation_id field from the workorder kanban mobile view, which is used in the MO form on mobile. operation_id is then not passed to the server in vals_list when creating the MO but it is required to link the instructions from the BOM to the MO. opw-5950983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250090
Restaurant table merging now waits for the related order information to finish saving before completing the merge. This prevents server errors when staff merge a table with an order into an empty table, making point-of-sale operations smoother and more reliable.
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 during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577 Forward-Port-Of: odoo/odoo#245162
Fixes an issue where adding extra product media in the website editor could make the page appear stuck. Users can now interact with the media dialog normally, preventing interruptions while editing product pages.
Original PR description
Issue: --- Adding extra image to product using editor, blocks the page. #### Steps to reproduce: 1- On the website, navigate to a product page. 2- Click on edit. 3- Click on `Exta Media` -> `Add`. Cause: --- When performing actions in the builder that open a media dialog, the UI was blocked due to #249526. Because the media dialog requires user interaction, blocking the UI at that point caused a deadlock: the dialog opened, but the user could not interact with it, so the promise never resolved, and the action appeared to be stuck forever. Fix: --- The `env.services.ui.block()` call was placed before callApply(), which includes interactive dialogs. While the original fix correctly blocks the UI for reloadable actions, it unintentionally blocked user interactions when dialogs were opened. We can fix this issue by changing the place of block(). opw-6005701
Fixes an issue where adding extra product images in the website editor could leave the page stuck loading indefinitely. The editor now reliably unblocks after media actions, reducing disruption for users managing eCommerce product pages.
Original PR description
*: website_sale Commit [1] added a UI block when doing a reloadable operation, and unblocked it once the action finished. However, if the action didn't complete, `ui.unblock` would never be called, leaving the UI blocked indefinitely. To reproduce the issue in website_sale: - Install Website & eCommerce - Go to /shop page - Open a product page - Open the editor - Click on the main product image - In the "Images" section > Click on "Add more" in the Extra media field - Popup shows up but it loads indefinitely Fix this by always calling `ui.unblock` regardless of the reload outcome. Also move the media dialog opening to `load`, which runs before the UI is blocked, passing the selected media as `loadResult` to `apply`. [1]: https://github.com/odoo/odoo/commit/453b7eb8e038ee8e8a54de16fc1a45fb2fab573a Co-authored by: Robin Lejeune (role) <role@odoo.com> opw-6003505, opw-6006393, opw-6016898, opw-6013484, opw-6014383
The spreadsheet component was updated to the latest internal version. This helps prevent compatibility issues by rejecting spreadsheet data created with a newer unsupported library version.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/8dcb087083 [REL] 18.4.30 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2e1b4cc383 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Blog posts and events now correctly use their selected cover image when shared on social media. This prevents broken preview images and helps shared content look professional on platforms that use social preview tags.
Original PR description
Scenario:
- set cover image of a blog post
- post blog post on social media (or check og:image/twitter:image tags)
Result: the social media is a dead image like:
http://site/blog/1/"/web/image/3198-3915f222/cover%20image.webp"
Cause: the code setting social image expected it to be in the
cover_properties background-image in url('{image}') or url({image})
format, but since 1b0852948c070d4d936bd00b3dd1c0e5501a1300 the format is
url("{image}") so it was gotten incorrectly.
Fix: also strip doubles quote and have the code working with
cover_properties background image with:
- no quote: for cover_properties before 18.4
- single quote: not sure in what situation this can happen
- double quote: for cover_properties since 18.4
opw-5471804This 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 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 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