Monday, March 30, 2026
16 changes · saas-18.2
Enhancements to existing features
This update reorganizes how repair orders create related sales order lines, making it easier for custom modules to adapt that behavior. It should not change day-to-day user workflows, but helps partners and implementers maintain tailored repair processes more cleanly.
Original PR description
* This change moves the logic of generating sale.order.line values into a new method _prepare_repair_so_line_vals(), allowing easier extension and override in custom modules. 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-pr Forward-Port-Of: odoo/odoo#216294 Forward-Port-Of: odoo/odoo#213506
Resolved issues and error corrections
Creating a scrap order no longer crashes if the default scrap location has been deleted. This helps inventory users continue working smoothly and avoids an unexpected error screen in an uncommon configuration scenario.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252192
Documentation and clarification updates
This update adds a contributor to Aerospacelab's corporate contributor agreement record. It helps keep Odoo's legal contribution records accurate and up to date, with no impact on product functionality.
Original PR description
https://github.com/odoo/enterprise/pull/105990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246481
Creating a new analytic item from an analytic account's gross margin button now automatically fills in the related analytic account. This prevents new margin lines from being created without the correct account link, improving data accuracy with no extra user step.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256091 Forward-Port-Of: odoo/odoo#255726
The self-ordering QR code PDF now generates the correct pickup ordering links without adding table information. This prevents customers from scanning misleading QR codes and helps restaurants using pickup zones avoid ordering confusion.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right…
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251759 Forward-Port-Of: odoo/odoo#247184
This fixes the Swedish localization setup so sales of services outside the EU use the correct 0% outside-EU VAT label and reporting grid. It helps ensure Swedish VAT reporting classifies these transactions in the appropriate declaration field.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251750
This fix improves how automated browser test logs are captured by saving them after the browser has fully stopped. It helps teams diagnose failed tests more accurately and reduces cleanup problems when the browser does not shut down cleanly.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256306 Forward-Port-Of: odoo/odoo#256061
This update fixes a leak in automated web testing where audio-related listeners were not being cleared properly after tests. It helps keep test runs reliable and prevents leftover data from affecting later tests, without changing normal user-facing behavior.
Original PR description
Forward-Port-Of: odoo/odoo#256376
This fixes a rare issue where confirming a purchase order could fail because the system was still using an old product unit field name. The change keeps purchase order confirmation working correctly after a recent unit-of-measure update.
Original PR description
A big refactor of UOM in saas-18.1 (https://github.com/odoo/odoo/pull/184131) accidentally left a reference to the `product_uom` field on `purchase.order.line`. But that field was renamed to `product_uom_id` in https://github.com/odoo/odoo/pull/186250. In rare edge-cases, if we it `supplierinfo['product_uom_id'] = line.product_uom.id` while confirming a purchase order, it will block it because of a traceback: ``` supplierinfo['product_uom_id'] = line.product_uom.id ^^^^^^^^^^^^^^^^ AttributeError: 'purchase.order.line' object has no attribute 'product_uom'. Did you mean: 'product_id'? ``` This PR fixes the issues by accounting for the field rename. OPW-6068125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a typo in an internal test related to view filtering rules. It helps keep automated checks accurate so future changes are less likely to introduce regressions.
Original PR description
A typo was introduced in #163714 Forward-Port-Of: odoo/odoo#228977
This fix ensures that when users turn on formatting like bold, italic, underline, or strikethrough before typing, Safari on iOS correctly applies that formatting to the new text. It prevents newly typed content from unexpectedly appearing unformatted, improving editing reliability on mobile Apple devices.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249253
A recent update caused partner names in the approval request report to overflow and display incorrectly when names exceeded a certain length. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing visual errors. This improves the report's readability and accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update resolves a test failure related to the calculation of AVS deductions in the Swiss payroll module. The issue stemmed from a date calculation within the test environment that incorrectly compared dates, causing the test to fail. The fix uses a specific test time setting to ensure consistent date comparisons during testing.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update resolves an issue where Field Service users with restricted access couldn't add customers to tasks, resulting in an access error. The fix involved a secure update to customer phone numbers and added restrictions to control who can modify them, ensuring all users can correctly manage tasks.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/enterprise#93969
This update resolves an issue that prevented contract creation when a working schedule had zero hours. The fix prevents a division-by-zero error during hourly wage computation, ensuring contracts can be created correctly. This improves the reliability of the Australian payroll module for My Australian Company users.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It's a simple fix to improve the user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757