Tuesday, March 25, 2025
6 changes · saas-18.1
Resolved issues and error corrections
This fixes a manufacturing form issue where selecting certain products in a Bill of Materials could trigger an error when units of measure were enabled. It also makes related tests more reliable when demo data is not installed, reducing unexpected failures during validation.
Original PR description
Issue ===== In the `mrp_bom_form_view` BoM form view, the `many2one_uom` field widget use the field `product_tmpl_id` as its `product_field` which is related to `product.template` model. The issue…
Issue ===== In the `mrp_bom_form_view` BoM form view, the `many2one_uom` field widget use the field `product_tmpl_id` as its `product_field` which is related to `product.template` model. The issue is, in the `uom.Many2OneUomField` template, we define the `productModel` attribute by looking at the **record's model**: if it's `product.template`, we use it, otherwise we use `product.product`. Here, the model is `mrp.bom`, so `product.product` is used. That leads to an issue in `Many2XUomTagsAutocomplete` `updateReferenceUnit` because we search for a `product.product` with the id of a `product.template`. If it exists a product variant with this id, the error is not visible because we use the UoM reference of the wrong product but all works good. But if there is no product variant for this id, there is a traceback. How to reproduce ================ - Install MRP; - Enable Units of Measure; - Open a BoM form view; - Select a Product (`product.template` field) with an id where no `product.product` exists with this exact same id -> Traceback. Fix === To fix this issue, we removed the condition in the template and get the model on the field itself in the `setup`. If the field model is not `product.product` or `product.template`, we throw an error. The same change is done for both `Many2XUomTagsAutocomplete` and `Many2ManyUomTagsField` since they follow the same logic. Also, the test/tour `test_mrp_bom_product_catalog` was sometime affected by this issue, now the UoM setting is always active for this test to minimize the chance to got an nondeterministic error. Runbot build error: 135062
Fixes an error that could appear when editing the checkout page after a customer adds a product to their cart. This helps website managers edit shop and checkout pages without encountering a disruptive crash.
Original PR description
Versions -------- - saas-18.1+ Steps ----- 1. Go to /shop; 2. add product to cart; 3. go to checkout; 4. try to edit the page with the website editor. Issue ----- Traceback: `TypeError: super.destroy is not a function` Cause ----- `super.destroy` is not a function. Solution -------- Use `this._super.apply` instead of a direct call to `super`. opw-4668627 opw-4669346 opw-4670159
Fixes an issue that prevented Stripe payments from being sent to the payment terminal in PoS self-order kiosks. This restores a key kiosk payment flow and helps avoid failed checkout experiences for customers.
Original PR description
When using stripe in kiosk it was not working Steps to reproduce: ------------------- * Setup stripe * Setup a PoS kiosk * Add a stripe payment method to a kiosk > Observation: There is an error and nothing is sent to the terminal Why the fix: ------------ Instead of using `False` when calling `_verify_authorization` we should send an empty object. opw-4643323
The point of sale system now allows coin and bill values with more than two decimal places. This fixes setup issues for countries where cash denominations require higher precision, helping businesses configure local payment rules correctly.
Original PR description
Same issue as in https://github.com/odoo/odoo/commit/77c921586efbaaf93ea6d9bba399716c9d861c8c It's not possible to create coins/bills with an accuracy greater than 2 but some countries need more than 2 decimals. The decimal precision was reduced with this commit for cleaning purposes: https://github.com/odoo/odoo/commit/96a2478d0dd8342b5278d123b59b1baed1f52d46 opw-4640800
Reloading after switching between spreadsheet dashboards now keeps users on the dashboard they selected. This prevents confusion and helps teams avoid viewing or acting on the wrong dashboard data.
Original PR description
## Description: Previously, when switching dashboards multiple times and reloading the page, the wrong dashboard was loaded. This issue occurred because the `addSpreadsheetActionLazyLoader` function was missing the correct `dashboards` path, which is defined in the XML client action. To resolve this, the correct `dashboards` path has been added to the `addSpreadsheetActionLazyLoader` function. Task: 4636576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users who leave a discussion channel will no longer be unexpectedly added back due to background typing status updates. This prevents confusion and keeps channel membership aligned with the user’s choice to leave.
Original PR description
Before this fix, a user who left a channel could be re-added unexpectedly. Steps to reproduce: - Join a channel. - Leave using the `/leave` command. - Repeat until the channel reappears in the sidebar. This is caused by a race condition: non-members can still access channels, but certain actions (like typing) require membership and members are created when needed. If `action_unfollow` is called before `notify_typing`, the member will be re-created. This is especially problematic when setting `is_typing` to `False` since it is triggered from the composer component's `onDestroy` lifecycle or after 5 seconds without activity which can easily come after an unfollow action. This fix ensures a member is only created when actively typing, preventing unintended re-creation after leaving.