Daily updates from Odoo
Wednesday, February 18, 2026
35 changes · saas-19.1
Resolved issues and error corrections
This update corrects a visual issue in the sign application where the header overlapped due to a red color bar. The fix removed a specific styling tag, resolving the overlap and ensuring a clean, professional appearance for users completing the signing process. This improves the user experience and brand consistency.
Original PR description
Remove `top` tag to prevent header overlap due to neutralize red color bar Before fix: <img width="1953" height="790" alt="image" src="https://github.com/user-attachments/assets/dd9f7a00-eaea-4304-a22d-d8df96203823" /> After fix: <img width="1892" height="639" alt="image" src="https://github.com/user-attachments/assets/247e6067-570a-4fcb-a0e9-6f2640940f21" /> opw-5900244 Forward-Port-Of: odoo/enterprise#106844
This update adjusts the width of the 'Review' button on the ticket screen in the Point of Sale module. Previously, when an order was paid, the button was unusually narrow. Now, it expands to take up the full screen width, providing a clearer and more usable experience for users.
Original PR description
Before this commit: --- - On the ticket screen in small UI, two btns are shown: Review and Load Order. - The Load Order button is only visible when the selected order is not paid. - When the order is paid, only the Review btn is shown, but it takes 50% width. After this commit: --- - When the order is paid, the Review button expands to take 100% width. task-5892189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246743
This update resolves an issue where document previews weren't appearing in the chatter after editing activities and attaching new documents. The fix, originally developed for a related framework component, has now been fully implemented within the Mail module, ensuring accurate document previews are displayed.
Original PR description
Description: Previously, when editing an existing activity and attaching new documents from the user’s device, the edits were saved correctly, but the document previews were not displayed in the chatter. This issue had already been addressed by the framework editor team; however, their fix was not applied to the Mail module. In this PR, we apply the existing framework fix to the Mail module to restore document preview functionality. related PR: https://github.com/odoo/odoo/pull/240114 task-5423808 Forward-Port-Of: odoo/odoo#243805
This update corrects a bug where applicants were seeing job postings from different companies within the recruitment process. The system now ensures that job listings displayed are only those belonging to the applicant's company, improving the accuracy and usability of the application search. This change enhances the applicant experience and reduces potential confusion.
Original PR description
[FIX] hr_recruitment: prevent showing jobs from different company than applicant belongs Bug production steps: Select My Belgium Company -> Recruitment -> Applications -> All applications -> Create new application -> In the job position field, many jobs can be seen that are belong to other companies from applicant company Bug cause: In the previous domain for job_ids, it should be either False (can belongs to many companies) or should be the company that our applicant belongs to. Bug solution: Convert the domain such that it only lists the jobs that the job company and applicant company are same. Also, company_id field made visible when >= 2 companies are selected in the environment. task - 5498859 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#244072
This update corrects a bug where duplicate activities were created on purchase orders when a sale order was cancelled, specifically within the dropshipping feature. The fix ensures that the correct template is only triggered when a purchase order originates from a sale order for a product, preventing unnecessary activity and streamlining the process.
Original PR description
**Steps to Reproduce** * Install `sale_management`, `purchase`, and `stock` with demo data. * In Inventory → Settings, enable `Dropshipping`. * Create a product: * Set a vendor under the Purchase…
**Steps to Reproduce**
* Install `sale_management`, `purchase`, and `stock` with demo data.
* In Inventory → Settings, enable `Dropshipping`.
* Create a product:
* Set a vendor under the Purchase tab.
* Set routes to `Dropshipping` and `Buy`
* Create and confirm a sale order for this product.
* Confirm the generated purchase order.
* Cancel the originating sale order.
* Go back to the linked purchase order.
**Observed behavior**
* Two activities are created on the purchase order when the sale order is cancelled.
**Cause**
* Both templates — `exception_on_so` (from sale_stock) and
`exception_purchase_on_sale_cancellation` (from sale_purchase)
are triggered during sale order cancellation.
* Each module overrides `_action_cancel` and triggers its corresponding exception template.
* When both modules are installed, both templates run.
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_purchase/models/sale_order.py#L26-L32
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/sale_stock/models/sale_order.py#L206-L208
* The template `exception_purchase_on_sale_cancellation` should only be triggered
when the PO originates from an SO and the product is a service, but
the domain lacks the required product-type condition.
**Fix**
* Add the missing condition to ensure that `exception_purchase_on_sale_cancellation`
is not triggered for dropshipped products, preventing duplicate activities.
---
`NOTE` - This issue is resolved from version 19.0 in this [commit](https://github.com/odoo/odoo/pull/212679/changes/ede2898278220a3ba4d8910ef268fe59f1587c72)
---
opw-5153488
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239569A recent test report for MRP production planning was failing because the administrator user lacked the necessary permissions to select product variants. This update adds the required user rights, allowing the test to pass and ensuring accurate reporting of product variants within the test environment.
Original PR description
The _/mrp:TestReportBom.test_mrp_report_bom_variant_selection_ test was failling because administrator user couldn't use the product variants. The needed dropdown menu to switch variant wasn't displayed and the test failed. We add the "product.group_product_variant" rights to the user. Runbot error: 238917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248634
This update fixes a potential issue where abrupt system clock changes could disrupt IoT driver jobs, leading to delays and errors. The system now automatically detects and adjusts schedules to prevent misfires, ensuring consistent operation of custom IoT handlers. This enhances the reliability of the IoT system.
Original PR description
Before this commit: If IoT system clock is wrongly set (happened on a Wi-Fi environment with slow connection). The system clock will abruptly change for a date in the future which will trigger all…
Before this commit:
If IoT system clock is wrongly set (happened on a Wi-Fi environment with slow connection). The system clock will abruptly change for a date in the future which will trigger all `schedule` jobs (which will think they are several days late).
In addition to this oversight, on an IoT on which "custom IoT handlers" configuration is enabled, if the `upgrade.check_git_branch` job is called on IoT boot, it will trigger the following traceback:
```py
2026-02-17 13:53:41,751 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: Exception in thread Thread-4:
2026-02-17 13:53:41,757 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: Traceback (most recent call last):
2026-02-17 13:53:41,758 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/usr/lib/python3.13/threading.py", line 1043, in _bootstrap_inner
self.run()
~~~~~~~~^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/pi/odoo/addons/iot_drivers/tools/helpers.py", line 50, in run
service.server.restart()
~~~~~~~~~~~~~~~~~~~~~~^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: File "/home/pi/odoo/odoo/service/server.py", line 1622, in restart
os.kill(server.pid, signal.SIGHUP)
^^^^^^^^^^
2026-02-17 13:53:41,759 1371 ERROR ? odoo.addons.iot_drivers.exception_logger: AttributeError: 'NoneType' object has no attribute 'pid'
```
Which will prevent the IoT to restart thus to load custom handlers
After this commit:
Brutal time changes (of 10 minutes (in a 3-second loop)) are detected, and jobs schedules are updated to prevent misfire callsThis update resolves an issue where the 'Mark as Paid' button was hidden for users in Mexico when the l10n_mx_hr_payroll_account module was installed. This change ensures the standard payment flow is clear and functional for Mexican users, improving their experience.
Original PR description
The "Mark as Paid" (action_payslip_paid) button on the hr.payslip form view [is hidden](https://github.com/odoo/enterprise/blob/19.0/hr_payroll_account/views/hr_payslip_views.xml#L39) when the l10n_mx_hr_payroll_account module is installed, making the standard payment flow confusing for users in Mexico. target: 19.0 task-5434674 Forward-Port-Of: odoo/enterprise#104390
This update corrects a rare display problem in Firefox where adding text to a link would create duplicate buttons. The fix resets Firefox's internal selection state, preventing this duplication and ensuring links display correctly. This improves the overall user experience for Firefox users.
Original PR description
In some situations Firefox behaves strangely when adding a character add the end of a button, by duplicating the button element without children and inserting the text between both buttons. It seems Firefox maintains an internal selection state that is corrupted after some operations. This commit resets the collapsed selection inside links in order to reset this internal state in Firefox. Steps to reproduce: - Insert a link - Put some text after the link - Delete the first character from the text - Keep deleting until the last character from the button is deleted - Type a character => The button was duplicated and the text was inserted between both buttons. - Note that if you undo/redo, then typing a character did work fine task-5033890 Forward-Port-Of: odoo/odoo#248703 Forward-Port-Of: odoo/odoo#241895
This update fixes a bug where customers could still redeem expired ewallet points. The change ensures that ewallet points are no longer available for claiming after their expiration date, improving the accuracy of point balances and preventing potential revenue loss. This resolves issue OPW-5476686.
Original PR description
### Issue: Due to this issue, ewallet points are claimable after expiry. #### Steps to reproduce: 1- Create a ewallet program, and generate an ewallet for a partner. 2- Set the expiration date in the past. 3- Create a SO with the same partner. 4- Click on reward. Expected: The ewallet shouldn't be claimable. Current outcome: The ewallet is claimable. opw-5476686 Forward-Port-Of: odoo/odoo#248931 Forward-Port-Of: odoo/odoo#247740
This update fixes a bug preventing embedded videos from showing correctly within shopfloor work order instructions. The issue stemmed from a previous fix being lost during a code refactor, and the original solution has now been reapplied. This ensures that video instructions are displayed as intended, improving visual guidance for shop floor operations.
Original PR description
Issue ----- Embedded videos are not displayed in the shopfloor. Steps to reproduce ----- - Create a BOM with at least one operation - Create an instruction in the work order operation - In the instruction text, add a video link - Create a MO and plan it - Open the work order in shopfloor - Open the instruction > Empty window, no video Cause ----- Fix of 61fdab3 got lost in some refactor, so reapplying the logic. ----- Ticket: opw-5926557 Forward-Port-Of: odoo/enterprise#107538
This update fixes a display issue on the Odoo Sales Portal for mobile devices. The section showing order details was not resizing correctly due to differences in how columns (unit price and taxes) were displayed on smaller screens. This change ensures a consistent and properly formatted view for users accessing the portal on their phones and tablets.
Original PR description
The colspan computation on the SO section is broken on mobile. This is because the unit price column is not rendered < sm viewports, and the taxes column is not rendered < md viewports. Thus we need to adapt the colspan accordingly to these responsive columns. task-5942576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248871
This update resolves a technical issue preventing users from removing a date filter on the booking Kanban view in the POS system. The fix involved correcting a missing function within the user interface, ensuring the date filter option is now correctly accessible. This improves the overall usability of the booking management feature.
Original PR description
Steps: - Install pos_appointment. - Open a POS session with bookings configured. - Open the Booking tab and click Remove date filter in the header. Issue: - A traceback occurs with `Invalid handler`. Cause: - The Remove date filter button’s onclick handler was not defined. Fix: - Define a valid onclick handler for the Remove date filter button. Task-5902656 Forward-Port-Of: odoo/enterprise#107633 Forward-Port-Of: odoo/enterprise#106684
This update resolves an issue where the "Order Now" button disappeared in the self-order mobile interface after deleting or paying for an order. The fix ensures that order updates are correctly reflected in both the mobile and POS UIs, improving the customer experience and order management.
Original PR description
**Issues:** 1. Order deleted from backend When a self-order is deleted from the backend, the customer self-order UI is not updated, causing the “Order Now” button to be missing. 2. Order sent and…
**Issues:**
1. Order deleted from backend When a self-order is deleted from the backend, the customer self-order UI is not updated, causing the “Order Now” button to be missing.
2. Order sent and paid from POS UI Steps:
- Create a self-order from mobile
- Load the order in the POS UI
- Add additional items (eligible for preparation)
- Proceed to payment and validate
- Click Order in the Send for preparation popup Problem: After order validation, the customer self-order UI is not refreshed and the “Order Now” button does not reappear.
**Fixes:**
- Ensures order deletion triggers notify calls to refresh both POS and self-order UIs
- Synchronize deleted orders with the customer self-order UI
- Fix the case where setting Service at = `Table` and Pay after = `Meal` in a single operation resets Pay after to `each`.
Task-5373116
Related: https://github.com/odoo/enterprise/pull/103052
Forward-Port-Of: odoo/odoo#248844
Forward-Port-Of: odoo/odoo#240523This update ensures that the preparation display in the backend accurately reflects changes when a POS order is cancelled or deleted. Specifically, related preparation orders and data are now correctly removed, preventing outdated information and improving data consistency.
Original PR description
**In this commit:** Ensure the preparation display UI is updated when a POS order is cancelled or deleted from the backend. - On order cancellation, the preparation display is refreshed accordingly. - On order deletion, related preparation orders, lines, and states are removed via notify call. Task-5373116 Related: https://github.com/odoo/odoo/pull/240523 Forward-Port-Of: odoo/enterprise#107522 Forward-Port-Of: odoo/enterprise#103052
This update resolves an issue where tables in Sale Quotations didn't display borders correctly when printed to PDF, specifically in Firefox. The fix ensures consistent border rendering by explicitly setting a border width in the PDF generation process, improving the visual quality of printed documents.
Original PR description
Problem: When adding a table in the Sale Quotation description and printing it, the generated PDF shows no table borders when opened in Firefox. Cause: Some PDF viewers (e.g., Firefox) do not render table borders correctly of a PDF created by `wkhtmltopdf` without an explicit border width. Solution: Explicitly define the border width in the `base_style` of `html_editor` to ensure consistent rendering in generated PDFs. Steps to reproduce: - Create a new Sale Order. - Add a table in the description. - Print the quotation. - Open the generated PDF in Firefox. - Observe that the table appears borderless. opw-5857255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248613
This update prevents badges from overlapping when multiple badges are added and duplicated on a website page. The issue stemmed from a technical process that merged badges together, causing visual conflicts. This fix ensures badges display correctly and consistently across the Odoo website.
Original PR description
Steps to reproduce: - Go to Website > Edit a page - Add a badge using editor - Duplicate that badge more than once - Save -> badges intersect each other Cause: ====== When saving, `cleanForSave` will be triggered which then will call `mergeAdjacentInlines`, since badges are inline elements, they will be merged into one single badge causing that issue. Solution: ========= We add a predicate to `unsplittable_node_predicates` to prevent `mergeAdjacentInlines` from merging badges. opw-5790891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247368
This update resolves an issue where the website editor would crash after saving changes in Safari and Epiphany. The problem stemmed from outdated event listeners being attached to the parent window, causing conflicts when the iframe reloaded. This fix ensures the editor receives the correct, current service object, improving stability and reliability.
Original PR description
Steps to reproduce: =================== 1. In Website > Shop, open any product. 2. Click "Edit" on the product. 3. Make a change (for example, toggle "Zoom on click") 2 times. -> In the second time a…
Steps to reproduce:
===================
1. In Website > Shop, open any product.
2. Click "Edit" on the product.
3. Make a change (for example, toggle "Zoom on click") 2 times.
-> In the second time a traceback will appear `(Safari, Epiphany)`.
Cause:
======
The website builder uses two contexts:
- The **iframe** runs services (e.g. websiteEditService)
- The **parent window** runs editor plugins (e.g. EditInteractionPlugin)
They communicate via custom events on window.parent.document. The service (in the iframe) registers a listener for
"edit_interaction_plugin_loaded" on the parent document, and responds with a "transfer_website_edit_service" event carrying its service object.
When the iframe reloads after a save, the old listener was never removed from window.parent.document. The new iframe added a second listener. This meant two listeners existed on the parent document:
1. Old listener → responds with OLD websiteEditService (stale)
2. New listener → responds with NEW websiteEditService (correct)
Both fire when the plugin dispatches "edit_interaction_plugin_loaded". But the plugin only accepts the first response ({ once: true }), and since listeners fire in registration order, it always received the OLD stale service.
With the stale service:
- installPatches() early-returned (patches.length > 0 from session 1)
- destroy() called uninstallPatches() on the old service, removing stopInteractionByName from the old prototype
- stopInteraction() then tried to call the now-deleted method → crash: TypeError: publicInteractions.stopInteractionByName is not a function
Solution:
=========
Extract the anonymous event handlers into named functions and register a "beforeunload" listener on the iframe's window that removes them from window.parent.document. This ensures that when the iframe reloads, the old listeners are cleaned up before the new iframe registers its own, so the plugin always receives the current service.
opw-5864798
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248042This update resolves a bug that was causing errors during the creation of payroll records. The fix avoids using a virtual ID (NewId) in search domains, which was triggering a framework error. This ensures smoother record creation and prevents disruptions to payroll processing.
Original PR description
The generic `TestEveryModel` fails because a virtual ID (NewId) is used in a search domain during record creation, causing a crash. This commit uses `.ids` with the `'in'` operator to idiomatically handle virtual records and prevent the framework error. runbot-115303 Forward-Port-Of: odoo/enterprise#107644
This update corrects a bug where the 'CFDI to Public' checkbox was incorrectly checked when creating new invoices in the Mexican accounting module. The fix ensures this checkbox remains unchecked until a customer is selected, preventing incorrect public invoice generation. This improves compliance and accuracy for Mexican businesses using Odoo Enterprise.
Original PR description
Steps to produce: --- - Install `l10n_mx` and `accountant` modules. - Switch to a Mexican company. - Go to Accounting > Customers > Invoices. - Click on New to create a new invoice. Issue: --- - The `CFDI to Public` checkbox is automatically checked even when no customer is selected. Root cause: --- - Here at [1], the field l10n_mx_edi_partner_address_complete evaluates to False when no partner is set. - Due to the OR condition, this causes l10n_mx_edi_cfdi_to_public to be set to True, even though no partner has been selected yet. Solution: --- - We should only evaluate partner address completeness when a partner is explicitly set. - Also, add VAT check for `l10n_mx_edi_partner_address_complete`, as requested by mial(PO). [1] https://github.com/odoo/enterprise/blob/cc00e8f3bb75b8c782fea3a42ad3bbcdbc240e2f/l10n_mx_edi/models/account_move.py#L649 opw-5911542 --- Forward-Port-Of: odoo/enterprise#106943
This update fixes a UI issue where repeatedly right-clicking pinned messages in the Odoo inbox could cause duplicate dropdown menus and instability. The change ensures only one dropdown is displayed at a time, preventing crashes and maintaining a smoother user experience.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When multiple messages are pinned, repeatedly right-clicking different messages in the pinned…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When multiple messages are pinned, repeatedly right-clicking different messages in the pinned messages panel can open multiple context dropdowns simultaneously. This may lead to UI inconsistencies and potential crashes. **Current behavior before PR:** ---------------------------------------------- - Multiple pinned messages can be right-clicked consecutively - Each right-click may open an additional dropdown menu - Duplicate dropdowns can remain visible at the same time - This can cause unstable or inconsistent UI behavior **Desired behavior after PR is merged:** ---------------------------------------------- - Only one dropdown menu is displayed at a time in the pinned messages panel - Repeated right-clicks properly reuse or replace the existing dropdown - Prevents duplicate dropdowns and avoids potential UI crashes Task-5935503 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where right-click actions were incorrectly displayed in the pinned messages panel. The fix ensures that actions are only shown when the panel is open and messages are pinned, aligning with the design intent. This improves the user experience for managing pinned conversations.
Original PR description
Before this commit, when some messages are pinned and the pinned messages panel is open, right-click on a message in pinned panel shows the message actions. The actions are not made visible in pinned messages panel, as intended by the props `hasActions=false` in this panel. However, the right-click showing of message actions lack condition based on this props, which is what this commit fixes. Task-5935503 Before / After (shows right-click of system) <img width="317" height="301" alt="Screenshot 2026-02-18 at 12 14 39" src="https://github.com/user-attachments/assets/e81d5118-09f1-4a67-907d-119e813cbac4" /> <img width="291" height="125" alt="Screenshot 2026-02-18 at 12 15 12" src="https://github.com/user-attachments/assets/417070a2-b926-4558-8479-aacf61a86948" />
This update fixes an issue where the MTO replenishment route was incorrectly suggested by default. The change ensures the system correctly identifies the appropriate replenishment route based on product vendor information, improving the efficiency of stock replenishment processes. This impacts the purchase and stock modules.
Original PR description
*mrp,purchase_mrp,stock Issue ----- MTO gets suggested by default as the replenishment route for products. Steps to reproduce ----- - Enable routes - Unarchive MTO - Create a product with a vendor…
*mrp,purchase_mrp,stock Issue ----- MTO gets suggested by default as the replenishment route for products. Steps to reproduce ----- - Enable routes - Unarchive MTO - Create a product with a vendor and MTO route - Open the replenishment wizard > The default/suggested replenishment route is MTO Cause ----- When creating the widget, we go through its' `default_get` to set its' default route https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/stock/wizard/product_replenish.py#L76-L77 the domain is computed by `_get_route_domain`, which in turn calls `_get_allowed_route_domain` https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/stock/wizard/product_replenish.py#L165-L170 However, since we are creating a new, it does not have a `warehouse_id` yet, so we don't go into the `if` condition. https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/stock/models/stock_replenish_mixin.py#L26-L39 We only get routes from the product, but since buy is set on the warehouse and not the product anymore, it doesn't get included. Solution ----- There is an override of `_get_route_domain` in `purchase_stock` https://github.com/odoo/odoo/blob/310897cf07ebbf484ea6877fb329215e45c481d7/addons/purchase_stock/wizard/product_replenish.py#L91-L96 it filters out the buy route if there is no `seller_ids` for the product, but since the buy route cannot be a part of the domain anymore, the condition should be changed to include buy if the product has a seller. Note: `_get_route_domain` is only ever called in `default_get`. Other changes ----- The same change is also applied for the manufacture route, as the logic is the same. It makes no sens to include route that do not lead to an internal location. ----- Ticket: opw-5388728 Forward-Port-Of: odoo/odoo#246304
This update fixes an issue where loyalty rewards weren't correctly calculated when products were ordered in quantities other than the standard unit. Previously, orders using multiples of the base unit (like dozens) didn't trigger the discount. This change ensures that loyalty rewards are accurately applied regardless of the product's unit of measure, improving the customer experience and discount accuracy.
Original PR description
### Issue: Due to this issue, applying a different uom than unit one, will not apply the reward regarding to quantities. #### Steps to reproduce: 1- Create a program: buy 12 get 6 free. 2- Create a SO, add a dozen of product to SOL. 3- Click on reward. Expect: 6 free unit is added. Current outcome: Nothing is added. Unless you add 12 dozens which is going to add 6 units. ### Cause: In checking rules, `product_uom_qty` is directly used without conversion to quantity. Note: `test_different_uom_to_hours_on_sale_order_confirmation` is failing due to this fix, because the uom_id unit/dozens and hours/days are not compatible. As this is not possible in UI, IMO we can delete the breaking SOL in that test. opw-5913638 Forward-Port-Of: odoo/odoo#248527 Forward-Port-Of: odoo/odoo#247743
This update corrects a bug where a purchase order wasn't automatically created when selling a product with multiple variants. The fix ensures that supplier information isn't incorrectly linked to the product template when a product has several variants, preventing the system from misinterpreting sales orders and failing to generate purchase orders.
Original PR description
Steps to reproduce the bug: - Create an attribute "Test": - Display type: Radio - Attribute values: X1 and X2 - Variant creation: Dynamically - Create a storable product "P1": - Attribute & variants:…
Steps to reproduce the bug: - Create an attribute "Test": - Display type: Radio - Attribute values: X1 and X2 - Variant creation: Dynamically - Create a storable product "P1": - Attribute & variants: add X1 and X2 - Add any vendor - Route: MTO - Create a sale order with one unit of P1-X1 - Confirm it -> the purchase order is created - Create a second sale order with one unit of P1-X2 - Confirm it -> the purchase order is not created Problem: When the Buy route is triggered, a check whether a vendor is linked to the product variant being used. However, since "product.supplierinfo" is linked to the template and also to the first variant (P1-X1), no supplier is found for the other variants, so no PO is created. https://github.com/odoo/odoo/blob/60993a956f127af5bf988b056f9df948a5437d8b/addons/purchase_stock/models/stock_rule.py#L52-L55 https://github.com/odoo/odoo/blob/4759c5f1649b2a9bd3378b6e29cd2b806e86ea37/addons/product/models/product_supplierinfo.py#L113-L114 Solution: When the number of variants changes for a product template, the compute of product_id in the model product.supplierinfo is triggered. In this case, product_id must be set to False when multiple variants are linked to the product template. opw-5871195 Forward-Port-Of: odoo/odoo#248656
This update fixes an issue where single-day time off requests were incorrectly displayed as multi-day events in the calendar, primarily affecting users in the Los Angeles timezone. The change ensures that single-day leaves appear as expected, resolving a visual inconsistency and improving calendar accuracy.
Original PR description
Issues: - Single-day time off requests appear as multi-day events in the Calendar app when using certain times - Full day time offs were not appearing as `allday` events in the calendar (bar over the…
Issues: - Single-day time off requests appear as multi-day events in the Calendar app when using certain times - Full day time offs were not appearing as `allday` events in the calendar (bar over the days instead of a block representing the hours) if the time off type had a request unit of half-days. Causes: The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. - The cause of the second issue was relying on `leave_type_request_unit` which is a simple related to the leave's type unit which doesn't consider cases where the time off duration could be longer than the minimal request duration. After fix: - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 Steps to Reproduce: 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817
This update fixes a memory error that occurred when calculating standard deviation and average for quality points. By disabling a data fetching process and focusing on only two key fields, the system now handles larger datasets more efficiently, preventing crashes and improving performance. This change impacts the Quality Control module.
Original PR description
Before this commit, computing the `standard_deviation` and the `average` of a `quality.point` involved fetching all the quality checks and all their fields. This can cause a memory error because of the field called `notes` that might involve HTML code. To avoid this, I have disabled the prefetcher since we only need two fields for the computation (`x_quality_state` and `measure`). The benchmark done below involved a recordset of quality points of size 1000 and the average size of the `notes` field was 6MB. The recordset was ordered by the size of the note section descending and for the different test cases it was sliced by the $K$ top elements and the compute function was triggered on the sliced version. | Scenario | Before | After | | :--- | :--- | :--- | | 100 | Memory LIMIT | 289.0MB | | 200 | Memory LIMIT | 290.0MB | | 500 | Memory LIMIT | 292.0MB | | 1000 | Memory LIMIT | 331.0MB | Forward-Port-Of: odoo/enterprise#106493
This update resolves a memory issue that could cause slowdowns and errors during Odoo upgrades. By optimizing image processing, particularly when related images have identical dimensions, the system uses less memory and processing time, leading to a more stable and efficient experience.
Original PR description
Description of the issue/feature this PR addresses: Because of the way `Pillow` manages memory, excessive image processing quickly leads to MemoryError, e.g. during upgrades. Current behavior before PR: When a readonly Image field with definied dimensions relates to another Image field of the same dimensions, there is no need to ever process the former one, since the processing will already have happened on the latter one. Still, the current code will process the image superfluously in these cases. Desired behavior after PR is merged: Extending the condition for skipping superfluous image processing to cover these cases will lead to reduced compute time and memory use. Forward-Port-Of: odoo/odoo#248990 Forward-Port-Of: odoo/odoo#248834
This update fixes an issue where multi-employee payslips were defaulting to the language of the first employee. The change ensures that each employee's payslip is printed in their correct, selected language, improving accuracy and user experience. This resolves a previous bug related to date formatting and language selection within the payroll system.
Original PR description
Steps to detect the bug: - Install payroll - Create more than one employee with different payslip languages - Add a contract for the employees - Payroll -> Payslip -> Pay run - Create a new payroll for more than one employee - Select all the employees in the pay run - Click 'print' button - Dates for the employees that are not the first one are in the language of the first employee This commit will allow the user to create multiemployee payslips maintaining the correct selected payslip language for each one of them. The issue was caused by a cache dictionary that used only the date and date format as a key, failing to include the user language. This led the system to reuse the first translated date for all subsequent employees. opw-5865260 Forward-Port-Of: odoo/enterprise#107269 Forward-Port-Of: odoo/enterprise#106575
This update reverts a recent change that was causing all upsell quotes to be canceled and disrupting legitimate business processes. The issue stemmed from a technical error in how quotes were handled, specifically related to alternative quotes and a faulty action call. This fix ensures upsell quotes function as intended.
Original PR description
…mmit/55b6bbe27cc31abcaee40cd4a196e087fdfd4ce5 This commit introduced an issue. All upsell quote were canceled and no filtering was done on "alternative quotes". As a result it could disrupt legit business flow. Moreover, action_cancel was called instead of _action_cancell which can lead to ValueError: Expected singleton as action_cancel can require single record sometimes. Forward-Port-Of: odoo/enterprise#107503 Forward-Port-Of: odoo/enterprise#107417
This update ensures that special products used in point-of-sale (like those with discounts or tips) cannot be deleted or archived. This prevents potential errors and data inconsistencies within the POS system, ensuring accurate sales tracking and reporting.
Original PR description
Before this commit, it was possible to delete or archive some products even if they were special for the pos (discount, tips, settle, etc.). This commit adds a mechanism to prevent this and reduce the risk of errors linked to missing products in the pos. Enterprise PR: https://github.com/odoo/enterprise/pull/95789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230865 Forward-Port-Of: odoo/odoo#229074
This update ensures that essential products like 'settle due' and 'deposit' are automatically configured for all Point of Sale (POS) settings when the pos_settle_due module is installed. Previously, these products were only available in POS sessions without open sessions, causing potential issues. This change guarantees consistent product availability across all POS configurations.
Original PR description
Before this commit, when the module pos_settle_due was installed, the special products (settle due, deposit, settle invoice) were only set on the POS configurations that did not have any open session. This could lead to issues when trying to use these products in a POS session of a configuration that did not have them set. Now, the special products are set on all POS configurations when installing the module. Community PR: https://github.com/odoo/odoo/pull/229074 Forward-Port-Of: odoo/enterprise#96788 Forward-Port-Of: odoo/enterprise#95789
A recent issue with a POS80D printer was causing Odoo to crash. This update fixes a USB error related to printer descriptor validation, preventing the crash and ensuring reliable printer functionality. This resolves a reported problem impacting a specific printer model.
Original PR description
Seen on https://laloux-j.odoo.com/ 12/2 with a POS80D printer the printer triggers a core.USBError. This PR catches the corresponding exception 2026-02-12 04:21:12,496 1117 ERROR ? odoo.addons.iot_drivers.exception_logger: usb.core.USBError: [Errno None] Invalid descriptor task-5932720 Forward-Port-Of: odoo/odoo#248991
This update resolves an issue preventing the generation of P9 reports (tax documents) for Kenyan employees in version 19.0 and later. The fix removes a deprecated field related to employee identification, ensuring the report can be created correctly. Testing confirms the PDF generation now functions as expected.
Original PR description
Bug reproduction: When version >= 19.0, install Kenya payroll and accounting, create payslip for one of the Kenyan employee -> validate the payslip -> Reporting: P9 Report in payroll app -> Create…
Bug reproduction: When version >= 19.0, install Kenya payroll and accounting, create payslip for one of the Kenyan employee -> validate the payslip -> Reporting: P9 Report in payroll app -> Create new tax deduction card -> populate employees -> in the inside of the card: select employees and click to generate pdf -> it will not be generated
Bug cause:
1 - In cron parameters, context passed wrongly, it should take place in the clickable parameters
2 - After saas-18.4 in the migration, employee.l10n_ke_pin field is removed but this field still takes place in l10n_ke_tax_reduction_card_templates.xml and it gets error when the user clicks to generate PDF.
Bug solution:
1 - Fixing cron parameter passing
2 - Removing PIN of employee field from P9 report since it is not available anymore.
Testing: Unit test is written to check PDF's are generated for sure.
1 - Creating Kenya company, employees
2 - Creating payslip for employees and validate them
3 - Creating tax deduction card and generate declarations
4 - Checking PDF's are created
task - 5395267
Forward-Port-Of: odoo/enterprise#104816This update addresses a recent finding that the Mexican SAT now accepts accented characters in tax documents. Previously, the system automatically removed accents to align with SAT practices. This change temporarily allows the ‘É’ character, and further investigation is underway to determine the full extent of accepted accents.
Original PR description
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT…
An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices. In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely. The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`. Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information. [opw-5915515](https://www.odoo.com/odoo/project.task/5915515) ---- *Edit: Miguel (mial) confirmed that names are not always sanitized, but that we expect them to be.* Forward-Port-Of: odoo/enterprise#107677