Daily updates from Odoo
Wednesday, March 4, 2026
67 changes · saas-19.1
Enhancements to existing features
This update ensures Odoo Enterprise complies with recent changes mandated by the Uruguayan tax authority (DGI) regarding Electronic Fiscal Documents (CFE). Specifically, a new selection option is added for export documentation and required data fields are updated to match the latest CFE version 25 requirements, maintaining legal compliance.
Original PR description
Purpose: The DGI introduced changes in CFE version 25. The following changes below needs to be implemented for legal compliance.
Required Changes:
- Introduce a new selection value,("91", "Export under Mandate")for field, l10n_uy_edi_cfe_sale_mode. This option is required when documenting export operation performed as a mandating entity, where the definitive export will be carried out by a third party.
- The reference document(credit note or debit note) of an existing account move will need to send:
- Amount (MntCFEref)
- Currency (TpoMonedaRef)
- Exchange Rate (TpoCambioRef) if the currency is not Uruguayan Pesos
task-5419331
task-5419331
Forward-Port-Of: odoo/enterprise#108430
Forward-Port-Of: odoo/enterprise#103881This update allows accountants to group invoice lines by tax, reducing clutter in journal entries and simplifying invoice review. The system automatically ungroups the lines when needed, streamlining the process and improving data clarity. This improves efficiency for accountants working with vendor bills.
Original PR description
[IMP] account_edi_ubl_cii: (un)group lines by tax
Once an invoice is imported, a server action allows the user to group
lines by tax, and then if the same action is triggered again it will
ungroup all lines from the origin file
This feature is useful because accountants don't always need the
detail of the vendor bills, and also all the lines clutter up the
journal items
task-5047859
Forward-Port-Of: odoo/odoo#251520
Forward-Port-Of: odoo/odoo#245234This update enhances the poll experience by displaying the poll's end time when you hover over the 'Remaining Time' text. This allows users to set reminders and proactively manage participation, ensuring timely responses and maximizing poll engagement. It's a small improvement that increases the effectiveness of polls.
Original PR description
This commit adds showing of datetime when the poll will end when mouse-hovering on the Remaining time text of the poll. This is useful to put a reminder for later just before the poll ends, let's say to see if involvement is fine or we need to push pressure for people to vote. <img width="555" height="255" alt="Screenshot 2026-03-04 at 12 55 44" src="https://github.com/user-attachments/assets/19ef91a1-ea52-475a-86e1-acc16e18fe98" />
This update enables Point of Sale systems to communicate with devices running on your local computer (localhost). This allows for easier testing and development of POS integrations, particularly with devices like printers, without needing a live connection to a remote system. The change was driven by an internal task to improve development workflows.
Original PR description
This commit allows communication with devices running on localhost (127.0.0.1) through LNA task.5936854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250972
This update simplifies the process for Italian businesses filing withholding tax returns. The default periodicity has been changed to monthly, addressing a previous difficulty in configuring this setting. This ensures compliance with Italian regulations and improves the user experience.
Original PR description
In Italy, withholding tax return periodicity is monthly. but it's hard to discover/configure. Default periodicity should be monthly. task-5985704 Forward-Port-Of: odoo/enterprise#109420 Forward-Port-Of: odoo/enterprise#109185
This update modernizes invoice formats for our French and German customers, aligning with new regulatory standards for Factur-X and ZUGFeRD. It also adapts invoice generation for B2B and B2G transactions, ensuring compliance with German regulations and PDF/A-3 standards for international invoices. This improves clarity and accuracy for our customers.
Original PR description
Updating the FacturX format (France)/ ZUGFeRD format (Germany) to respect the new norms: Factur-X 1.07.3 EXTENDED and ZUGFeRD 2.3.3 EXTENDED. Add the differentiation between these two formats in the customer interface, even if they point to the same value in the code. It clarifies things for the customer, things are called by their name. Also, in Germany, for B2B invoices (peppol EAS = 9930), use ZUGFeRD, but for B2G invoices (peppol EAS = 0204), use XRechnung. Adaptation of the default values in the partner form according to this statement. For French and German companies that are sending invoices to French, German or Belgian customers, changed the default format of invoice sent to be compliant to PDF/A-3 norms. task-5266286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251594 Forward-Port-Of: odoo/odoo#237091
Resolved issues and error corrections
This update resolves an issue where incorrect partner IDs were being assigned to stock dropshipping orders due to a validation error in the Odoo code. The fix automatically filters out invalid 'False' values, ensuring accurate partner assignments and preventing the system from crashing.
Original PR description
**Issue:** The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion…
**Issue:**
The error is produced due the changes introduced in this https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f commit. Particularly because of this assertion checking :
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/odoo/orm/models.py#L5207
This assertion is failing because of the condition related to `is_dropship`. When `is_dropship` is `True`, the `partner_id` is expected to be `p.sale_id.partner_shipping_id.id`
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95
However, for the specific picking record in some cases, `sale_id` is not set
https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/sale_stock/models/stock.py#L190
As a result of the current implementation, the [expression](https://github.com/odoo/odoo/blob/b5d3970e6b05e2c35ce16e972e659d152c4de70e/addons/stock_dropshipping/models/stock.py#L95) evaluates to **False**. That False value is then included in the generated list.
**For example** : lot.partner_ids = [2, False, 5, 6]
With the recent changes, when this assignment happens, it **no longer ignores False values**. Instead, during the write process, the ORM internally calls **browse()** on the provided IDs. Since False is not a valid ID, the assertion inside browse() **fails**, this can be seen in the **traceback**.
This shows that when the field is being written, the ORM validates the IDs by calling browse(), and since False is included in the list, the assertion fails.
**Solution:**
To resolve this issue, I have use `mapped. As 'mapped()' will filter out all the empty(False) values from the recordset.
By switching to **mapped()** and returning a recordset instead of a list of IDs, False values are automatically excluded. As a result, no invalid IDs are passed to browse(), and the assertion error is avoided.
I have also added the if `p.is_dropship and p.sale_id.partner_shipping_id` condition because it fallback to the picking partner if there is no sale order partner to use
**Other Optimization:**
I have used `with_prefetch` to fetching `picking_ids`, it is just the purely ORM friendly optimization.
It ensures that all related records are prefetched efficiently across lots. It is not related to the bug above mentioned.
**Traceback:**
```python
File "/home/odoo/src/odoo/saas-19.1/addons/stock_dropshipping/models/stock.py", line 95, in _compute_partner_ids
lot.partner_ids = list(p.sale_id.partner_shipping_id.id if p.is_dropship else p.partner_id.id for p in picking_ids)
^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1866, in __set__
self.write(protected_records, value)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 765, in write
self.write_batch([(records, value)])
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 786, in write_batch
self.write_real(records_commands_list, create)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 1553, in write_real
comodel.browse(
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5202, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), "Invalid falsy real id"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
opw: 5922525
upg: 3889582
tgb: 2449
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an error that occurred when generating Argentinian tax reports (specifically ARBA profits reports) by ensuring the report filter correctly handles cases where no tax type is selected. This prevents a JavaScript error and ensures accurate report generation for these reports.
Original PR description
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report.…
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view The error was this one: Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Forward-Port-Of: odoo/enterprise#100457
A slow process for adding attribute values to products was identified due to inefficient database queries. This change replaces iterative database searches with faster filtering methods, significantly reducing the loading time from 8 minutes to 2-3 minutes. This improves the user experience for customers with many product attribute values.
Original PR description
opw-4876370 Issue: A customer who uses many attribute values complained that the "add to products" button on product attribute values in their database was really slow (8 minutes or so). Upon investigation I found parts of the involved functions used iteration over a set of records, which proved notably slower to psql searches. Fix: Replacing the code with what I believe is equivalent operations making use of the `search` method to filter through the sets much quicker. Behaviour after fix: The process takes 2-3 minutes when running this commit on the aforementioned database, but it's still a major improvement compared to the previous time. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251021 Forward-Port-Of: odoo/odoo#232149
This update fixes inconsistencies in how rental dates and planning slots are synchronized, ensuring accurate scheduling and order management. Previously, changes to either rental orders or planning slots could lead to mismatched dates. Now, all dates are automatically updated, improving data reliability and reducing potential scheduling errors. This also corrects issues with quantity syncing and resource allocation, preventing conflicts and ensuring accurate planning.
Original PR description
## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates Before this commit, it was possible to have `Planning Slots` with `Sync Shifts and Rental Orders` whose dates…
## [FIX] sale_renting_planning: fix sync between rental dates and planning slots dates Before this commit, it was possible to have `Planning Slots` with `Sync Shifts and Rental Orders` whose dates were different from the `Rental order`. This commit makes sure that all dates are always synced: - If the `Rental Order` dates are changed then all `Planning Slots`' dates changed to the new dates. - If a `Planning Slot` dates have changed then all other `Planning Slots` and the `Rental Order` Dates are changed to the new dates. ## [FIX] sale_renting_planning: fix sync between order line quantity and planning slots Before this commit, adding/removing a `Planning Slot` would not change the `SOL quantity` and changing the `SOL quantity` would not add/remove `Planning Slots` unless all slots are being deleted. This commit makes sure that when the `SOL quantity` is changed, the number of `Planning Slots` is changed accordingly, and if a Planning Slot` was added/removed, the `SOL quantity` would update accordingly. Note: The new sync behaviour from `SOL quantity` is ignored for `Products` with `hour UOM` because it is not clear yet how to update the `Planning Slots` if the new quantity of hours doesn't span a full rental interval. ## [FIX] sale_renting_planning: fix set multiple slots to resources Before this commit, adding multiple `Planning Slots` at the same time with the same `Role` can assign them to the same `Resource` even if they conflict with each other. This commit makes sure that when adding multiple `Planning Slots` none of them would conflict with each other after being added. task-5187356 Forward-Port-Of: odoo/enterprise#104771
This update corrects a minor issue in the Documents app where the action title wasn't consistently accurate for different types of account moves. Now, when creating account moves from the Documents app, the action name (like 'Vendor Bills') correctly reflects the move type, improving clarity and usability for users.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109307 Forward-Port-Of: odoo/enterprise#109180
This update allows managers to automatically launch appraisal campaigns for all their team members, even if they don't select individuals from a list. This simplifies the process for managers and ensures all employees are included in the appraisal cycle. The change includes new tests to verify the functionality.
Original PR description
. Allow the Leader to launch an appraisal campaign for all their employees by default when no specific employees are selected in the list. task-5347755 Forward-Port-Of: odoo/enterprise#100214
This update fixes a critical issue in the invoice processing cron job for Brazil's electronic invoicing system. Previously, a single error would halt the entire process, wasting IAP credits. Now, the cron job processes invoices in smaller batches, committing changes after each, ensuring progress is preserved and preventing disruptions.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211 Forward-Port-Of: odoo/enterprise#108468 Forward-Port-Of: odoo/enterprise#108191
This update fixes an issue where flexible resources were incorrectly displaying a total of 40 hours per week. The fix ensures that the system now accurately reflects the employee's scheduled hours (38 hours) when calculating available time. This improves the accuracy of scheduling and resource allocation.
Original PR description
### Steps to reproduce: - Download Planning app - From the employees app, create an employee - Assign that employee a new schedule that is 'Flexible', has 07:36 hours/day 'Avg', and has 'Total' 38 hours/week - Search for that employee in the planning app and hover over their name ### Cause of Issue: The total available hours for that employee show as 40h. This is because when calculating the hours per week for the resource, the resource's schedule is not taken into account but the company's. ### Fix: Add the hours per week for the resource's calendar (if available) in the calculation opw-5954982 Forward-Port-Of: odoo/odoo#250185
This update fixes an issue where resource scheduling wasn't accurately calculating working hours when using full-day periods. The system now calculates the midpoint between start and end times, ensuring correct representation of half-day schedules. This improves the accuracy of resource availability and time tracking.
Original PR description
### Steps to reproduce: - Go to any working schedule of an employee. - Add a working hour line for any day and choose day period as full day. - Change work from 10:00, and work to 18:00. ### Issue: - Resource was explicitly setting 12 if any hour_from/hour_to was missing. - Resource always consider that the working time is 8AM-5PM. ### Fix: - We will calculate the avg of working hours( hour_from + hour_to)/2 - Doing this we will always get the middle of day. task: 5912748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247756
This update resolves a crash issue that occurred when viewing pay runs on mobile devices. The fix ensures the system correctly identifies and interacts with the Kanban view, preventing unexpected errors and maintaining a stable user experience. This improves the reliability of the payroll module for all users.
Original PR description
**Steps to Reproduce:** 1. Open Payroll->Payslips->Pay Runs 2. Click on a Pay Run in Mobile View (Width < 600px). 3. Return to the previous view using the breadcrumb. 4. The system crashes with…
**Steps to Reproduce:** 1. Open Payroll->Payslips->Pay Runs 2. Click on a Pay Run in Mobile View (Width < 600px). 3. Return to the previous view using the breadcrumb. 4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft') **Bug Cause:** The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback. **Solution:** Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout. Task: 5971861 Forward-Port-Of: odoo/enterprise#108847
This update fixes a hidden error in the Point of Sale system that prevented invoice generation when an untrusted bank account was used. Now, users will receive a clear notification explaining the issue, ensuring invoices can be created correctly. This improves the user experience and prevents potential invoicing problems.
Original PR description
Steps to reproduce: - Add untrusted bank account to the database's selected company's contact - Finalize an order in point of sale through register - While in register, go to orders and click on the invoice button for the finalized order Current behavior: - There is no indication of why you can't generate an invoice Expected behavior: - There should be a popup to the user identifying the error (e.g. untrusted bank account) This addresses a side effect of: https://github.com/odoo/odoo/pull/248108 opw-5946239 Forward-Port-Of: odoo/odoo#251197 Forward-Port-Of: odoo/odoo#249558
This update corrects an issue where the standard price of dropshipped products wasn't updated when the bill price differed from the original purchase order price. The fix ensures that the product's standard price accurately reflects the final billed amount, improving inventory accuracy for dropshipping transactions.
Original PR description
**Problem:** When Billing a dropshipped PO, if the price of the bill is changed from the price of the Purchase Order, the standard price of the product is not updated **Steps to reproduce:** - enable…
**Problem:** When Billing a dropshipped PO, if the price of the bill is changed from the price of the Purchase Order, the standard price of the product is not updated **Steps to reproduce:** - enable the dropshipping settings - create a storable product with avco perpetual category - in the inventory tab, select the dropship route - in the purchase tab, set a vendor - create and a confirm a quotation for this product - on the linked purchase order, set a unit price of 100$ and confirm - validate the dropship move (- you can check on the product form that the standard price is now 100$) - create a bill for the purchase order - set the price to 90$ and confirm - navigate to the product form **Current behavior:** The standard price is still 100$ **Expected behavior:** It should be 90$ **Cause of the issue:** When we validate the picking, action_done() is called on the moves . Inside the action_done() override of stock_account, after the call to super, set_value is called on is_in and is_dropship moves https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L168-L169 Inside _set_value(), because the move is dropship, it's going to be added to products_to_recompute https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L277-L278 and then we're going to exit this iteration of the for loop. https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L285-L286 so basically we simply call the _update_standard_price() on the product. https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/stock_move.py#L310 Because the product is avco, _update_standard_price is going to call _run_average_batch https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/product.py#L541 The value is not set on the dropship move but it's still used in the computation because for dropship move, we use _get_value() https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/product.py#L382-L383 which will take into account the bills and POs if there are some. But the problem is that, when we post the invoice we only call set_value on is_in moves https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/account_move.py#L42 So the standard price of our dropshipped product is not updated. opw-5498878 Forward-Port-Of: odoo/odoo#250067
This update fixes a data issue in the Danish (DK) demo company data within Odoo. Specifically, the street number was missing, which was required for proper integration with Nemhandel (the Danish e-commerce platform). This ensures accurate reporting and functionality for users working with the DK demo environment.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes inaccuracies in the Bulgarian tax settings within the Odoo accounting system. Specifically, it corrects incorrect tax names and changes the default purchase tax rate to 20% FTC, aligning with current Bulgarian regulations. This ensures accurate tax calculations and compliance for Bulgarian businesses using Odoo.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#251593 Forward-Port-Of: odoo/odoo#249269
This update corrects a bug where related fields within many2one chains were displaying the wrong model data. Specifically, when creating a chain with duplicate field names, the popover would incorrectly show fields from a different model. This issue was caused by a recent update to support properties in field definitions.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if…
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944 Forward-Port-Of: odoo/odoo#249185
This update resolves a minor visual issue with the select menu in Odoo, specifically addressing styling inconsistencies when scrolling. The fix ensures a consistent and polished appearance for the select menu across the base and base_import modules. This improves the overall user experience.
Original PR description
Before this commit, the select menu with its dropdown opened had a little style issue when scrolling base_import's select menu had also a style which was a bit off. After this commit, those are fixed part-of-task-5935511 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
This update resolves an issue where certain custom reports, built using specialized models, were causing errors within Odoo Studio. By preventing Studio from directly accessing these reports, the system is now more stable and reliable for users creating reports.
Original PR description
…eport Some report build their data via a report model. Those are often tailor made to their business use cases and may crash when entering studio. This commit prevents this
This update resolves a minor display issue in the accounting dashboard where the 'Reconnect Bank' button incorrectly appeared for accounts without an expiration date. The fix ensures the button only shows when a valid numerical expiration date is present, improving the user experience.
Original PR description
The aim of this commit is fixing the behavior of Reconnect bank button in accounting dashboard. Before this commit, a synchronization without any expiring date will always show the Reconnect bank button in the accounting dashboard because the expiring due days (in the JS widget) is null and not undefined. This condition led to check the second part of the condition where null <= 0. Which is true in javascript. Now, we are checking the type of expiring due days as first condition, if it's not a number, we don't check the second part of the condition, and then we don't display the Reconnect Bank button. no task id
This update resolves an issue where product variant pricelist rules were not correctly updating when a product was removed from the pricelist. Specifically, the data associated with the variant was incorrectly retaining a product template ID. The fix ensures that when a product is removed, the data resets to the correct state, preventing data inconsistencies and ensuring accurate pricing calculations for product variants.
Original PR description
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to…
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to pricelist listing, select the pricelist - Edit price list rule - Remove the product - Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id) Related ticket: opw-5411034 (Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view) Description of the issue/feature this PR addresses: Fix corrupted data <img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" /> Current behavior before PR: product_tmpl_id set to None product_id / applied_on data stays the same Desired behavior after PR is merged: When product_tmpl_id is removed, reset the applied_on type back to 3_global --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250531 Forward-Port-Of: odoo/odoo#249417
This update resolves an issue where salespersons couldn't change or reset their payment tokens due to an access error. The fix ensures system administrators have the necessary permissions to retrieve payment token information, preventing disruptions to subscription management.
Original PR description
Use case: A salesman go to a subscription and want to change/reset the payment token a subscription, when trying to get the values of the `payment_token_id` fields [`name_search()` call] an `AccessError` is raised. Since odoo/odoo#239177, fetch() do compute fields, so for payment token this means that `display_name` will be computed without su=True flag, thus raising an `AccessError`. This commit force getting the provider `custom_mode` as sudo, as only system administrator have access to that model. Note: from feedback-pad
This update fixes an issue where modifying production quantities after switching BoMs would create duplicate work orders. The fix ensures that work orders are correctly updated instead of duplicated, improving the accuracy of manufacturing orders. It addresses a technical detail related to how Odoo handles virtual records during data changes.
Original PR description
Steps to reproduce: 1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty). 2. Create a Manufacturing Order (MO) for the product selecting BoM A. 3. Switch BoM A to BoM B, then…
Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.
The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.
Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.
TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855
opw-5489862
Forward-Port-Of: odoo/odoo#246995This update corrects a bug where manually created stock transfers without references were incorrectly merged into existing transfers. The change ensures each manual transfer creates its own distinct operation, preventing confusion and errors in multi-step warehouse workflows. This improves data accuracy and simplifies inventory management.
Original PR description
*: purchase_stock Issue Before This Commit: ====================== In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock)…
*: purchase_stock
Issue Before This Commit:
======================
In a `multi-step` configuration, while validating a transfer that has no `stock reference`, its next operation (Input → QC → Stock) is merged into an existing transfer that also lacks a stock reference, even when the transfers are manually
created and not generated from a Sales or Purchase Order. This results in unrelated transfers being grouped together.
Steps to Reproduce:
======================
- Install the `stock` module.
- Configure the warehouse to use `three-step reception`.
- Create and validate two receipts for Product A (qty 10) with Vendor A.
- `Observation`: the next transfers for both receipts are merged into a single transfer, even though both receipts were
created manually and not generated from any same source document like PO/SO.
Cause of the Issue:
======================
In the `_search_picking_for_assignation()` method, when no `stock.reference`is defined on a move, the system still attempts to find an existing picking using the `partner_id`. Additionally, in the `_key_assign_picking()` method, moves
without a `reference_ids` are grouped based on their `partner_id`. As a result, validating multiple manually created receipts sharing the `same vendor` causes them to be incorrectly merged into the `same next transfer`, since they do not share a common stock reference.
After this Commit:
======================
The `_search_picking_for_assignation()` method now skips searching for existing pickings when moves lack a `stock.reference`. The `_key_assign_picking()` method groups moves by their `originating picking` instead of the partner, preventing merges between unrelated transfers without a stock reference. This ensures each manual transfer creates its `own next operation` in multi-step routes.
Task-ID: 5242340
Forward-Port-Of: odoo/odoo#250385
Forward-Port-Of: odoo/odoo#235423This update corrects a test case in the quality control module to reflect a recent change in how Odoo handles merging stock transfers. Specifically, transfers now only merge into existing ones when a 'stock reference' is defined. This ensures the test case accurately reflects the current system behavior and avoids potential issues.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a stock reference is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#108520 Forward-Port-Of: odoo/enterprise#99342
This update corrects a bug that prevented drag-and-drop functionality when using Arabic or other RTL languages. The fix adjusts the detection logic to properly identify drops outside of the sidebar, ensuring a consistent user experience regardless of language settings. This improves usability for a wider range of users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#251041 Forward-Port-Of: odoo/odoo#247759
This update resolves an issue where US-specific reports were incorrectly appearing in Odoo databases configured for India. The fix ensures that the necessary US Payroll module is automatically installed when the l10n_in_hr_payroll module is installed, preventing this unintended report visibility.
Original PR description
**Version:** saas-19.1 **Steps to reproduce:** - Create a new database with India as country. - Install l10n_in_hr_payroll. - US company based reports are visible. **Issue:** Reports specific to us payroll localisation are visible for base hr_payroll module **Cause:** The l10n_us module was missing as the auto_install dependency. **Solution:** Added l10n_us as the auto_install dependency in the manifest file. **task-5948747**
This update resolves a technical error that prevented users from hearing incoming ringtones during VoIP calls. The fix ensures the necessary service is correctly initialized, allowing ringtones to play as expected. This improves the user experience for VoIP calls.
Original PR description
requestIncomingRingtone() was calling this.ringtoneService.incoming.play(), but ringtoneService is not defined on UserAgent, leading to: ``` TypeError: Cannot read properties of undefined (reading 'incoming') when handling VOIP:PLAY_INCOMING. ```
This update resolves a bug that caused the mail composer to crash when generating invoices for sale orders without an associated invoice. The fix ensures that the intracom delivery date logic only applies when an invoice exists, preventing errors and maintaining normal report generation. This improves the reliability of our invoicing and shipping processes.
Original PR description
### Description of the issue/feature this PR addresses: A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery…
### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).
### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:
AttributeError: 'NoneType' object has no attribute 'invoice_date'
This raises an RPC_ERROR and breaks the mail composer / send flow
### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250167This update resolves an issue preventing multiple tax lines on Italian invoices processed through the l10n_it_edi_doi module. Previously, only the DOI tax could be applied. Now, other taxes like Enasarco and RIT can be added to the same line, aligning with Italian tax regulations. This ensures accurate invoice processing for Italian businesses.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
This update resolves a technical issue within the Odoo Enterprise HR payroll module that prevented users from editing date inputs in a specific form view. The fix ensures the popover is displayed before the input is cleared, restoring full editability. This improves the user experience for payroll processing.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440 Forward-Port-Of: odoo/enterprise#109346
This update corrects an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). By disabling a specific function, we now ensure that only payments meeting the required 30-day term are processed, aligning with Mexican regulations and improving data accuracy.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#109306 Forward-Port-Of: odoo/enterprise#104628
This update corrects a redirect issue where internal users receiving ‘Signed Document’ emails were incorrectly directed to the public portal. Now, internal users automatically receive a preview of the document, while the existing portal redirection for public users remains unchanged. This ensures a consistent and accurate experience for all users.
Original PR description
Internal users opening the “Signed Document” email link were redirected to the portal instead of the document preview. Now they are redirected to the internal preview, while public users remain unchanged. task-5486043 Forward-Port-Of: odoo/enterprise#107079
This update resolves a bug where the selected time slot for self-order orders was incorrect due to timing issues. The fix ensures a specific time slot is consistently chosen and verified to remain available after the order is placed, improving order accuracy and reliability.
Original PR description
The selected time slot was not the right one as the time of the execution influed on the first choice available. We now specify which time slot to take, and check that this specific timeslot is not available anymore afterwards. runbot-233381 Forward-Port-Of: odoo/odoo#233469
This update resolves an issue preventing the export of Eco-Voucher data to Excel after a recent system update. The change addresses a discrepancy in data tracking between the old 'contracts' system and the new 'versions' system, specifically related to the 'Status' field. This ensures accurate reporting for Belgian companies.
Original PR description
Since the switch from contracts to versions, exporting Eco-Vouchers to excel has not been functional, this commit fixes this. **Steps to reproduce:** - Open Payroll App as a Belgian company - Under Reporting Menu, select Eco-Vouchers - Try exporting with XLSX **Issue:** Since introduction of versions, version module does not contain state field anymore which was present in contracts **Fix:** Removed the state field and replaced it with the corresponding field in version. task:5163668 Forward-Port-Of: odoo/enterprise#109396 Forward-Port-Of: odoo/enterprise#97375
This update fixes an issue where taxes weren't correctly applied when the tax's fiscal position was set to 'all'. The change ensures that taxes with this setting are now applied with the appropriate fiscal position, resolving a discrepancy between tax settings and sales order calculations. This improves tax accuracy and consistency.
Original PR description
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case…
### Issue: No tax will be applied if in taxes, fiscal position is set to all. #### Steps to reproduce: 1- Create a tax, and in the tax form, leave `Fiscal Position` field blank, which in this case `all` will be shown in placeholder. 2- Set Domestic FP to be applied automatically, and set the country to `US`. 3- Create a Partner with `US` country_id. 4- Create a product, and apply the created tax to sale taxes. 5- Create a SO with created partner and the created product. 6- As you see, the tax is not applied to the line, while if you check SO's fiscal position, it is set to Domestic. Expected: As tax's fp is set to all, we expect this tax being applied with Domestic fp. ### Cause: In this line, if no `tax_ids` is set, it means fp has not tax_ids: https://github.com/odoo/odoo/blob/0c3ae7f78d313885984c99a4e57485d9660dd974/addons/account/models/partner.py#L154-L158 However, this might also mean the tax has no fp because `fp.tax_ids` is a Many2Many relation. In the forms, `tax.fiscal_position_ids` being empty is shown as `all` in the placeholder, which means when no tax applied to fp, we expect all taxes to be mapped. ### Fix: This can be fixed by making sure the fp.tax_ids is not empty because there is no `tax.fiscal_position_ids` set. opw-5463245 Forward-Port-Of: odoo/odoo#244155
This update fixes an issue where the price per unit was incorrectly displayed in the shopping cart when products were purchased with packaging. The fix ensures that the price per unit accurately reflects the cost of the packaging, resulting in correct pricing calculations for customers. This improves the shopping experience and prevents pricing discrepancies.
Original PR description
Issue: --- Due to this issue, price per unit is not shown correctly in case of packaging. Steps to reproduce: --- 1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1. 2- Create a…
Issue: --- Due to this issue, price per unit is not shown correctly in case of packaging. Steps to reproduce: --- 1- Create a product. Set price: 2.6 per kg. Set `Base Unit Count` to 1. 2- Create a packaging of 0.5 kg, and add it to product in Sale tab. 3- Navigate to the shop and add 0.5 kg of the product to cart. 4- Navigate to the cart. Expected: The line price/unit should be 2.60/kg. Current outcome: It's shown 1.30/kg. Cause: --- Currently `_get_base_unit_price(product_price/line.product_uom_qty)` is shown to user as price/unit. `product_price` is calculated using `_get_cart_display_price()` which returns each line's `subtotal` or `total`. In our case, it will be `_get_base_unit_price(1.30/1)`, having base_unit_count set to 1, we will have 1.30 which is wrong. Fix: --- We would need to divide the line price by `product_qty` instead of `product_uom_qty`. Then in our example we would have: `_get_base_unit_price(1.30/0.5) = 2.60`. opw-5973097 Forward-Port-Of: odoo/odoo#251501
This update resolves an issue where vendor bills from foreign VAT companies were not correctly identifying their country of origin. The fix adds the necessary country code to the beginning of the invoice data, ensuring accurate reporting for JPK (Polish VAT reporting).
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
This update resolves an issue where updating a Bill of Materials (BoM) in a draft manufacturing order incorrectly deleted and attempted to delete associated work orders. The fix ensures that work orders are only removed when they are truly outdated, preventing data loss and improving order processing stability. This change impacts the MRP module.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#251352
Forward-Port-Of: odoo/odoo#249336This update fixes an issue where analytic asset depreciation reports were incorrectly calculating amounts when the analytic filter was enabled. The change ensures that depreciation amounts are accurately distributed across the correct analytic accounts, improving the accuracy of financial reporting.
Original PR description
Previously, when the analytic filter is enabled in the depreciation schedule, the total depreciation amount was shown in each respective depreciation column, and the analytic distribution was not taken into account. This commit fixes the depreciation amount for assets with analytic distribution in the depreciation schedule report. When the analytic filter is enabled, the amounts are computed correctly under each analytic's depreciation column. task-5959962
This update focuses on improving Odoo's performance by preventing the generation of slow SQL queries, particularly when accessing related fields like email content. A new system is in place to intelligently manage SQL generation, optimizing resource usage and speeding up data access. This change specifically targets models with complex access checks.
Original PR description
## [FIX] orm: stop generating slow SQL Update the context variable to cover the case where we have a related field such as "mail_message_id.body" which is not ran un sudo. In that case, we don't want to generate the SQL. ## [FIX] orm: _access_domain_heavy Mark some models that have heavy access checks so that they can be handled in a special way for performance reasons. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where employee names weren't consistently displayed across related fields in the HR module. By standardizing the formatting of these names, the system now presents a cleaner and more accurate view of employee information. This improves the user experience and data consistency.
Original PR description
Copy string and help field attributes for virually related employee fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug preventing warnings on the EC Sales List report when dealing with customers outside of Europe. Specifically, it ensures that warnings appear when a customer with an 'Intra-Community' fiscal position is used in a country not part of the EC Sales List, and when delivery addresses outside of Europe are used. This ensures accurate reporting and compliance.
Original PR description
The warnings partner_same_country and partner_no_ec_country on the EC Sales List are never showed. To Reproduce (for partner_same_country warning): - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer - Go to the EC Sales List - The customer doesn't appear in it, so the warning is not present. For the partner_no_ec_country, do the same but with the country of the customer being one outside of Europe.
This update ensures that disabled user accounts are no longer incorrectly flagged as blacklisted when checking email communication. This prevents unnecessary restrictions and improves the overall user experience. The change was made to align with previous work and includes new tests for verification.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
This update resolves a test failure within the Belgian payroll module (l10n_be_hr_payroll_fix) by adding a temporary freeze to time calculations. This ensures the holiday attest test now passes, maintaining the correct payroll processing for employees in Belgium. The fix was implemented to address a technical issue identified during automated testing.
Original PR description
Addind freeze_time to Fix holiday attest test that failed on the runbot Forward-Port-Of: odoo/enterprise#107490
This update corrects a display issue where upsell sales orders created from subscriptions incorrectly showed as "Quotation" instead of a standard sales order. The fix ensures that upsell orders now display their correct type, aligning with how initial subscriptions are presented, improving clarity for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767This update corrects a technical issue preventing stock users with 'Own Documents Only' sales access from successfully opening delivery orders. The fix avoids unnecessary security restrictions by computing the delivery description directly, rather than relying on complex rule overrides. This ensures smooth operation for all users.
Original PR description
### Steps to reproduce: - Create a Stock User with access rights: - Sales: User: Own Documents Only - Inventory: User - With your admin: Create and confirm a sale order for 1 x a consumable. - With…
### Steps to reproduce:
- Create a Stock User with access rights:
- Sales: User: Own Documents Only
- Inventory: User
- With your admin: Create and confirm a sale order for 1 x a consumable.
- With the Stock User open try to open the delivery
#### > Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.
### Cause of the issue:
Sale users `Own Documents Only` are granted read access to the `sale.order` model which is restricted to the `sale.order`'s to which they are the designated sale person or no-one is due to this `ir.rule`: https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale/security/ir_rules.xml#L44-L49 However, the read access of the sale order related to a stock move is required in order to compute its desciption:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/models/stock.py#L26-L31 While this access is suppose to be provided:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/security/ir.model.access.csv#L5 It is overriden by the `ir.rule`.
### Fix:
Since the `_compute_description` overrides rely on numerous independant models such as the `sale.order`, `purchase.order.line`, `product.supplierinfo`, `mrp.bom`, since the `picking_description` does not really carries sensitive informations and since parts of the computes already required to be put in `sudo` for similar reasons see 80c80505fabc4544e41f270169737218e47cad5a, it is preferable to compute the field in sudo rather than adding an `ir.rule` with true leaf on the `sale.order` model for the `stock.group_stock_user`.
opw-5929485
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251471This update fixes a minor issue where installing a new language in Odoo didn't immediately show the language option in the user preference settings. The fix clears all caches after language installation, ensuring the new language appears promptly and avoids confusing the user. This improves the overall usability of the language selection process.
Original PR description
Before this commit, after installing a new language, that language wasn't directly available in the selection field of the user preference form view. An extra reload was necessary to see the new language, which could confuse the user. This was due to the cache. As installing a language isn't a frequent operation, we simply clear all caches when this happens. task~5895416 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#251729
This update fixes an issue where long email addresses in the Point of Sale partner list were difficult to read due to awkward wrapping and inconsistent spacing. The changes now automatically truncate long emails and ensure all text and buttons are vertically aligned for a cleaner, more user-friendly experience.
Original PR description
Before this commit, long email addresses in the POS partner list would wrap awkwardly or expand the row height excessively, making the list difficult to read. Additionally, the vertical alignment between the text and the action buttons was inconsistent. This commit improves the Partner List UI by: - Truncating long email addresses - Adding a `title` attribute so the full email is visible on hover - Vertically centering all cell content to match the buttons. opw-5919153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247964
This update corrects inaccuracies in the XML files used for Swedish payments (SEPA). Specifically, it ensures the correct BIC number is used, removes a misleading placeholder value, and allows users to select the appropriate payment version, even without using the standard SEPA method. This improves the accuracy and reliability of payment processing for Swedish customers.
Original PR description
We currently have customizations for the iso20022 xml file for payments in Sweden. But those customizations aren't correct. This commit fix multiples issues: 1) In DbtrAgt, we sometimes have bankgiro information. But this node should always contain the BIC number for Swedish payments. 2) The _get_cleaned_bic_code method was replacing the real bic code with a fake value like 'SE:Bankgiro', but this seems to be wrong. None of the SE banks ask for this BIC, so we remove it. 3) The sepa_pain_version field is supposed to tell Odoo which pain version to use. But the problem is this field is computed, and only editable once the user set the SEPA payment method, but for iso_se, we want to let the user choose as well, even if he didn't add SEPA as payment method. This commit change the invisible on the field, so it can be edited as soon as iso_se is in the journal payment methods. task-5427570 Forward-Port-Of: odoo/enterprise#105536
This update corrects an issue where the display of shift durations in the Planning app was inaccurate when shifts spanned across multiple days. The fix removes outdated logic that truncated shift names, ensuring correct hour representation regardless of the shift's length. This improves the accuracy of shift scheduling and reporting.
Original PR description
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an…
### Issue: The pill name contains the hours when it spans over the next day for less than 3 hours but not if more than 3 hours. ### Steps to reproduce: - Go to Planning app - Create a shift for an employee from 3pm to 2am (over two days) - The hours of the shift are displayed - Modify the shift end to 3am - The hours of the shift aren't displayed ### Cause: Before the refactor adapting the gantt view to OWL, when a shift spanned over two days less than three hours, then the gantt view truncated the pill to display it in only one day. (see [`_snapToGrid()`](https://github.com/odoo/enterprise/blame/a16b2ef569903c0ae5803c169dbd68acd0141fe1/web_gantt/static/src/js/gantt_row.js#L1044-L1072)) The same logic was done for the computation of the pill's name in [this commit](https://github.com/odoo/enterprise/commit/98a86cbacf484646f486e4648788cfa53cc9648c). But as the pills are no longer truncated since 17.0, the computation of pill names is faulty. ### Solution: We remove the checks of the 3-hour margin. This also makes the variable `spanMoreThanOneDay` useless, so we delete it. opw-5881532 Forward-Port-Of: odoo/enterprise#109397 Forward-Port-Of: odoo/enterprise#107233
This update resolves an issue where approval rules for account moves incorrectly activated list view actions. The fix ensures that when an approval rule action is set up, the associated list view action is automatically deactivated, preventing unintended actions. This improves the reliability and accuracy of the approval process.
Original PR description
Following commit odoo/odoo@c442f72479b50855f40ba079800ee9e5a5690753 When putting an approval rule action_post (account.move) the action bound to the list view must be deactivated. opw-5921128 Forward-Port-Of: odoo/enterprise#106853
This update resolves an issue where the Sendcloud shipping API required a minimum product weight of 0.00099. This commit ensures that product weights are always at least 0.001, preventing errors and ensuring accurate shipping calculations through the Sendcloud integration. This improves the reliability of shipments processed through Sendcloud.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
This update fixes a bug where clicking the 'More Options' button in the HTML editor caused the editor to lose focus. The fix ensures the editor remains focused after the powerbox opens, improving the user experience. Additionally, the powerbox now correctly filters commands, preventing a display of all commands.
Original PR description
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: -…
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: - After clicking the power button, the button becomes focused and the editor loses focus. Solution - When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused. **Issue 2:** Steps to reproduce - Click More options in the Power Buttons to open the powerbox. - Start typing `heading`. Description of the issue: - The powerbox does not filter commands and continues to show all commands. Cause: - In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true. - `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`. - Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered. Solution: - Introduced `openSearchPowerbox` in `searchPowerboxPlugin`. - Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`. - Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress. task-5485088 Forward-Port-Of: odoo/odoo#249844 Forward-Port-Of: odoo/odoo#244454
This update resolves a problem where sales staff couldn't correctly update or reset payment tokens within subscriptions. A technical change in Odoo's data processing now required elevated permissions to calculate the token's display name, leading to an error. This fix ensures the display name is correctly generated, allowing users to manage payment tokens as intended.
Original PR description
Use case: - install `payment_sepa_direct_debit` module. - As salesman go to a subscription and try to change/reset the payment token field. When trying to get the values of the `payment_token_id` fields [`name_search()` call] an `AccessError` is raised saying that we don't have access to `payment.provider` model. Since odoo/odoo@a3eef91230e0, fetch() do compute fields, so for payment token this means that `display_name` will be computed without su=True flag, thus it may raise an `AccessError` if accessing some payment provider fields. So this commit force building token display name as sudo, to ensure it can be correctly computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an aesthetic issue with the display of poll results in message lists. Previously, there was an unnecessary gap above the poll result box, which has now been removed. This ensures a cleaner and more professional look for users interacting with polls.
Original PR description
Before this commit, Poll Result in message list had some unwanted spacing between the message header and the poll result box. The bottom spacing is fine but not the top. Before / After <img width="263" height="161" alt="Screenshot 2026-03-04 at 16 44 12" src="https://github.com/user-attachments/assets/b827bc1e-ee67-4f73-bea5-3bfc3ed7ed2d" /> <img width="271" height="150" alt="Screenshot 2026-03-04 at 16 43 57" src="https://github.com/user-attachments/assets/fc816b40-f375-48f3-a283-ea064d2b4cfb" />
This update fixes an issue where the cursor wasn't correctly navigating within long text blocks inside Odoo tables. Previously, users couldn't move up and down within multi-line text cells. This change ensures accurate cursor movement within table cells with long text, improving the user experience.
Original PR description
When navigating inside a table cell, if a single text node is rendered over several lines, the cursor up and down key go directly to the next cell instead of navigating to the (visually) previous or next line of text. This commit determines if the cursor position is within such positions inside a multi-line text node and prevents the table navigation if needed. Steps to reproduce: - Add a table with `/table` - Put a very long text (without paragraph splits) in the center cell, so that the text spans over several lines - Navigate with the up and down arrows => The cursor could not reach distinct lines within the text task-5417834 Forward-Port-Of: odoo/odoo#240764
This update resolves an issue where the website editor wouldn't allow users to change rounded corner values when using themes with unitless '0' values for border-radius. The fix ensures that users can now modify rounded corners without errors, regardless of the theme's styling.
Original PR description
**Problem:** When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the…
**Problem:**
When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the following error occurs: "Cannot convert 'px' units into '' units !"
**Steps to reproduce:**
1. Install and activate the Anelusia theme (or any theme with unitless border-radius: 0)
2. Open the website editor
3. Select any element (e.g., a table in the footer)
4. Try to change the "Rounded Corners" field to any non-zero value
5. Observe the error: "Uncaught Promise > Cannot convert 'px' units into '' units !"
**Current behavior:**
The website editor throws a JavaScript error and prevents changing rounded corners.
**Expected behavior:**
Users should be able to modify rounded corners values without errors, regardless of whether the theme uses unitless or unit-based zero values.
**Cause of the issue:**
Some themes define border-radius variables as unitless `0` (e.g., `$border-radius: 0`). When the website editor's areCssValuesEqual() function in utils_css.js compares the new value (e.g., "10px") with the existing computed value ("0" - unitless), it attempts to convert between units. The getNumericAndUnit() function extracts the unit from "0" as an empty string "", then convertValueToUnit() tries to convert "10px" to "" unit. Since there's no conversion defined for "px" to "" (empty unit), convertNumericToUnit() throws the error.
**Fix:**
Add a special case in areCssValuesEqual() to handle unitless zero values before attempting unit conversion. When the first value is unitless "0", we compare the numeric values directly using Number.EPSILON, avoiding the unit conversion entirely. This allows proper comparison between unitless "0" and values like "10px" or "0px" without errors, while maintaining correct equality checks (0 equals 0px, but 0 does not equal 10px).
opw-5412414
Forward-Port-Of: odoo/odoo#246335This update resolves a technical issue where new chart types added to Odoo weren't clearly labeled in the data selection menus. Previously, it was difficult to distinguish between different chart types. Now, a placeholder name has been added to improve the user experience and make chart type selection more intuitive.
Original PR description
We recently added a lot of chart types that handle Odoo data but we faialed to add a placeholder name (which is handy to differentiate them in the datasource menu). Task-5979722 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#251135
This update corrects a bug that occurred when the 'commercial_partner_id' field was visible on the contact form (using web_studio). Previously, an error would be triggered when using the IAP autocomplete, preventing contact creation. This fix ensures the 'commercial_partner_id' field is always populated, resolving the issue and improving the contact creation process.
Original PR description
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251590 Forward-Port-Of: odoo/odoo#248895
This update fixes a bug where combo product prices were being incorrectly doubled. The issue stemmed from an error in how prices were calculated within the Point of Sale system. Now, combo prices are accurately displayed, ensuring correct transactions.
Original PR description
Combo product prices were doubled in the `comboTotalPrice` and `comboTotalPriceWithoutTax` getters, as we were summing the `displayPrice` of all the combo lines, including the parent line, which already had its `displayPrice` as the sum of its children. So now, we filter out the parent line in those getters before summing. Forward-Port-Of: odoo/odoo#247347
This update fixes a limitation where managers needed a specific group to access their team's voip call records. By changing the access rule to the standard 'group_user' group, all managers now automatically have access, simplifying permissions and improving usability.
Original PR description
voip_hr defines a record rule that gives managers access to their subordinates' voip.call records. However, this rule is linked to the group 'hr.group_hr_user', which is not granted to all managers. This commit links the rule to the base.group_user group instead, so that all managers can access their subordinates' records without the need for an additional group. [Task-5363640](https://www.odoo.com/odoo/project/5778/tasks/5363640). Forward-Port-Of: odoo/enterprise#100691
This update corrects a previous issue where users lacking sufficient permissions to modify company settings would encounter an error when sending follow-up reports via snail mail. The fix allows for necessary changes to be made with elevated privileges, ensuring reports can be sent reliably for all users. This improves the overall functionality of the snail mail module.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to modify the res.company model Fix: modifying the external_report_layout_id as sudo opw-5482855 Forward-Port-Of: odoo/odoo#248677