Wednesday, November 26, 2025
15 changes · 18.0
New functionality added to Odoo
This update adds crucial financial reports – Balance Sheet and Profit & Loss – to the Odoo Enterprise system for Mauritanian businesses. This expansion supports compliance with local tax regulations and provides Mauritanian users with the necessary reporting tools.
Original PR description
Add the Balance Sheet and Profit & Loss to the Mauritanian localization. task-4236158 Forward-Port-Of: odoo/enterprise#86530
Resolved issues and error corrections
This update addresses a security vulnerability where public website visitors could create unwanted UTM tracking records when registering for events. The fix restricts record creation to non-public users, preventing potential misuse and ensuring data integrity. This improves the stability and accuracy of our event registration tracking.
Original PR description
**Steps to reproduce:** - Install Link Tracker app - Go to Link Tracker > UTMs - Check UTM existing records (campaign, source, medium) - None exist with the name "test" - Go as a visitor on the event…
**Steps to reproduce:** - Install Link Tracker app - Go to Link Tracker > UTMs - Check UTM existing records (campaign, source, medium) - None exist with the name "test" - Go as a visitor on the event website - Open a register event link on the website (e.g. `/event/live-music-festival-4/register`) - Add UTM to the URL to simulate a marketing flow (e.g. `?utm_source=test&utm_medium=test&utm_campaign=test`) - Register to the event - Open the event on backend side - Check attendees and find the new one - Check the marketing section in debug mode - New records were created and added for the UTM values **Issue:** No access rights are checked when making the registration and updating the utm values. When not found they are added to existing ones during the `default_get` with `_find_or_create_record`. `return request.env['event.registration'].sudo().create(registrations_to_create)` This means that public users (visitors of the website) can create unwanted utm records when registering via expired/malformed/altered links. **Fix:** Restrict the issue to non public users for now. Might need to apply access rules and avoid the sudo. opw-4948208
This update resolves an issue where deleting a combo product within a sales order caused errors when modifying other items. The fix ensures all nested combo items are properly fetched and processed, preventing data inconsistencies and ensuring accurate order management. This improves the reliability of sales order modifications.
Original PR description
Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted. Steps…
Currently, an error occurs when a combo product is added to a sales order, and one of its combo items is replaced with another combo product, then the original parent combo product is deleted. Steps to reproduce: - Create a sales order and add a combo product to it. - Modify one of the combo items by replacing it with another combo product. - Delete the original parent combo product from the order lines and save. (Note: Make sure to not save the sale order while doing steps 1 & 2) Error: `ValueError: Expected singleton: sale.order.line()` The error occurs because the parent combo item is deleted, which causes `line.virtual_id` to become False. As a result, the filter [1] returns no matching records, and `ensure_one()` fails by raising a singleton error due to receiving zero records. This happens because the function [2] called from onchange in `sales_order` [3] that performs all the changes only checks the first level of combo items and doesn’t handle cases where those items are also combo products with their own linked items. Solution: - This commit fixes the error by properly fetching all nested combo items in the sales order, ensuring no leftover items from nested combos remain that could cause errors. [1] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order_line.py#L1567-L1569 [2] - https://github.com/odoo/odoo/blob/57b4056798b9a380027fd3da1c4f3965249a4509/addons/sale/models/sale_order_line.py#L1572-L1591 [3] - https://github.com/odoo/odoo/blob/7bb84621b773cdd7e9984222d61d70d622f8ac43/addons/sale/models/sale_order.py#L922 sentry-6979144433,6653847384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the reliability of POS certification transactions by automatically retrying failed connections to the payment system (TSS). If the connection is unavailable, users will receive a clear message and can continue working, preventing order processing interruptions. The changes also streamline the transaction flow and remove unnecessary code.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693
This update fixes an issue where scanning a lot multiple times during a barcode picking process would incorrectly create a backorder. The fix ensures that quantity updates are applied correctly to the relevant lines, preventing unnecessary backorders and improving order fulfillment accuracy. This ensures accurate stock management when using barcode scanning for picking.
Original PR description
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm -…
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm - open the picking in barcode - scan the stock location - scan the lot - scan the lot another time - validate **Current behavior:** a backorder is created **Expected behavior:** No back order should be created **Cause of the issue:** After scanning the lot for the first time we have the following situation: two lines : - one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1 - one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1 both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2 All of this is correct. when scanning the lot for the second time: _findLine iterates through the lines to select the right line to use. _findLine calls _lineIsNotComplete on the first line to check if it's complete (this first line is complete). https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684 But _lineIsNotComplete will actually do the check on the parent line (which is not complete), so the return value will be true. https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338 As a consequence, the quantity will be added in the first line and we will have a qty_done of 2 in the first line and a qty_done of 0 in the second line. Which will lead to the creation of a back order opw
This update ensures invoices exported with foreign VAT numbers correctly reflect the customer's VAT in the PDF invoice (factur-x file). Previously, the VAT number was incorrectly defaulting to the company's VAT. This fix addresses a data accuracy issue, particularly for EU distance sales, ensuring compliance and accurate reporting.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837
This update resolves an issue where a backorder was incorrectly created after a quality control check failed during a picking process. The change ensures that only failed quality checks are accounted for when validating the picking, preventing unnecessary backorders and streamlining inventory management. This improves order fulfillment accuracy.
Original PR description
Scenario: - have 3 steps incoming shipments - create a quality control check for one product - create and confirm a PO for that product and another one - fail the quality check, then validate the picking Result: a backorder will be created for product that was not failed Expected: no backorder is created Why: when we fail a quantity, we set the move as "picked", then when validating the picking, because of this move all move will be set as picked. Fix: add a new condition so a move that is picked and has a failed quality check is not taken into account when deciding if we set all moves as picked when the picking is validated. Note: without the fix, the added test fails because we are showing a confirmation wizard when confirming in backend, or validating in barcode tour. opw-4363773
This update ensures that archived companies are correctly excluded from standard user searches within the Documents app. Previously, administrators could still access documents from these archived companies, creating a potential security and data management issue. The fix explicitly checks for archived status, ensuring normal users don't see archived content while administrators retain access for necessary oversight.
Original PR description
**Steps to reproduce:** - Install Documents app - Create a bunch of companies with their own folders - Archive the companies - Try to open Documents app with admin - Access Error is raised **Issue:** Archived companies not properly taken into account in the search permission. **Fix:** Explicitly check of archived status for the folders company. The behavior is that normal users won't see documents from archived companies but admins still can. From related PR: > Also need to ensure archived companies are not removed from the admin search > domain even if the user has `active_test=False` related: https://github.com/odoo/enterprise/commit/b7e6acba60e50c86627b177a86b357d2bb956cbc opw-5127040
This update resolves an issue where changes to SO quantities within multi-step delivery workflows weren't consistently reflected in the procurement process. Specifically, the system incorrectly only considered the initial quantity when calculating returns, leading to incorrect stock levels. This fix ensures that all quantity changes are properly accounted for, improving inventory accuracy.
Original PR description
Steps to reproduce: - Enable Multi-step routes & set warehouse to 3 steps delivery - Make a SO for 5 qty of a stored product - Validate the PICK - Set the SO line qty to 3 & save - Set the SO line qty to 5 & save Issue: While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing. When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery. Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made. Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity. opw-5028794 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where rental order quantities were incorrectly calculated after a return PICK was processed. The fix ensures accurate tracking of product quantities within rental orders, preventing discrepancies in inventory levels. This improves the reliability of rental order management.
Original PR description
Steps to reproduce: - Enable multi-step & Rental transfers - Set warehouse to 2 steps reception/delivery - Create a rental order for a product with a qty of 5 - Process the PICK - Change the quantity in the rental order to 3 and save - Change the quantity back to 5 and save again Issue: The Rental IN picking has now a `product_uom_qty` of 1. This is due to a wrong computation of incoming/outgoing moves when there are returns (e.g. here a return PICK) in the linked pickings. opw-5028794
This update corrects a reporting issue where employee leave days were incorrectly included in planned hour calculations within the Timesheets > Planning Analysis report. The fix ensures that leave and holidays are properly excluded, providing more accurate project time tracking. This improves reporting reliability and data accuracy.
Original PR description
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects. **Steps to Reproduce** 1. Create a planning slot for an employee spanning a full month 2. Add employee time-off (resource.calendar.leaves) during that period 4. Navigate to Timesheets > Timesheets / Planning Analysis report 5. Filter by the employee and date range 6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project **Root Cause** The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy. **Solution** Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates. opw-5027070 Forward-Port-Of: odoo/enterprise#97657
This update fixes an issue where a backorder was incorrectly created after a quality check failed during a picking process. The change prevents moves with failed quality checks from being incorrectly marked as 'picked' when the picking is validated, ensuring accurate inventory management. This improves order fulfillment accuracy.
Original PR description
Scenario: - have 3 steps incoming shipments - create a quality control check for one product - create and confirm a PO for that product and another one - fail the quality check, then validate the picking Result: a backorder will be created for product that was not failed Expected: no backorder is created Why: when we fail a quantity, we set the move as "picked", then when validating the picking, because of this move all move will be set as picked. Fix: add a new condition so a move that is picked and has a failed quality check is not taken into account when deciding if we set all moves as picked when the picking is validated. Note: this commit only extract code from _traverse_path in another method so it can be overrideable. opw-4363773
This update corrects a bug that prevented users from sending E-Factura (SPV) invoices when linking a bank account to an invoice in the Romanian localization (l10n_ro_edi) module. The fix ensures the correct field ('state' for banks) is used, resolving an error related to mismatched data structures. This ensures invoices with E-Factura functionality can be processed correctly.
Original PR description
Same issue already fixed for 18.4+ here: https://github.com/odoo/odoo/pull/231399 Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank. Repro Steps: 1- Create invoice for romanian localization. 2- Link payment account to invoice. 3- Add bank to payment account. 4- Confirm and send invoice with "Send E-Factura SPV" checked. Cause: The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank. Fix: The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly. opw-5362000 (cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where search results on the website were not displaying correctly when the search returned more results than a single page. The system now automatically redirects users to the last page of results, ensuring all relevant information is shown. This improves the user experience and prevents missed opportunities.
Original PR description
Scenario: - enable website_studio - go to contact -> open studio -> website - add a listing and open it on website - go to page 2 and search a specific terms with less than 20 results Result: we see "5 results" in the search bar, but no result are shown and the pager is hidden. Cause: the pager is hidden since there is only one page, and we are currently displaying the records of page 2 that do not exist. Fix: if we detect that we are on a page over the last page, redirect to the last page. Eg. if there is 2 pages and we are in page 500, redirect to page 2. opw-5008556 Forward-Port-Of: odoo/odoo#223447
This update fixes a problem that occurred during Odoo upgrades where new companies were created without a designated subcontracting location. This caused subsequent upgrade steps to fail, leading to instability. The fix ensures locations are correctly created during the upgrade process, improving overall upgrade reliability.
Original PR description
During an upgrade, it could happen that some companies are created before this module is loaded. That means the override of `_create_per_company_locations` is not called and the company is created with an empty `subcontracting_location_id`. That can lead later to issues as that value was not expected to be empty. To reproduce: - On 16, install `onboarding`[^1], `l10n_de`, `mrp_subcontracting` with demo data. - Upgrade to 17. Module `l10n_de` will have created a company with empty subcontracting location. - Upgrade to 18. The upgrade will break during a call to `_create_or_update_sequences_and_picking_types` in `stock` because of the empty value. [^1]: onboarding is necessary to ensure l10n_de is loaded before mrp_subcontracting because of the dependencies. Forward-Port-Of: odoo/odoo#236149