Daily updates from Odoo
Monday, December 22, 2025
8 changes · 18.0
Resolved issues and error corrections
This update resolves an issue where user activity wasn't accurately tracked, causing the system to incorrectly display users as 'away'. By enabling event capturing, the system now reliably detects user clicks and updates their presence status in real-time, ensuring accurate user activity monitoring.
Original PR description
Before this PR, Elements that stopped event propagation (e.g., using event.stopPropagation()) prevented the global click listener from firing. As a result, user activity wasn't detected, and the presence status stayed "away" instead of switching back to "online". This PR fixes the issue by enabling event capturing on the global click listener (useCapture: true). With capture mode, the listener receives the event during the capture phase before any element can stop propagation. Bug:  task-[4892229](https://www.odoo.com/odoo/project/1519/tasks/4892229) Forward-Port-Of: odoo/odoo#238650
This update resolves an issue where Documents actions weren't appearing when a secondary language was active but deactivated. The fix ensures that only the currently active language is used when embedding actions, preventing errors and guaranteeing a consistent user experience across all supported languages. This improves the reliability of the Documents app.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Activate a second language (e.g., Arabic `ar_001`). 3. Deactivate the Arabic language by active toggle. 3. Go to the Documents app and open a folder 4. Set the 'Action on Select' (cog menu) to embed a server action. Issue: - Action is not selected. Cause: - The method `action_folder_embed_action` uses `_get_stored_translations`, which returns translations for inactive languages as well. This causes an `Invalid language code` error Solution: - Filter the languages retrieved from the DB to ensure only the currently active languages are used. opw-5380645
This update fixes an issue where manually adjusted prices on customer invoices were being reset when the invoice's fiscal position was changed. The fix ensures that prices remain as the user intended, mirroring the behavior of Sale Orders. This improves accuracy and reduces potential errors in invoicing.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a customer invoice with at least one product line. * Manually adjust the **price_unit** on the invoice line. * Change the fiscal position on the invoice. * Click the **Update Taxes and Accounts** button. **Observed behavior:** * The manually adjusted price is reset to the product’s default sales price (e.g., 1000). * This occurs even though neither the product nor the UoM changed. * In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation. **Cause:** * `action_update_fpos_values` method call the recomputation of unit price each time when we click update taxes and accounts button on invoice. **Fix:** * Add a condition to **skip price recomputation** when fiscal position changes. * This preserves manual prices when only the fiscal position changes. opw-5252832 Forward-Port-Of: odoo/odoo#237914
This update resolves a visual issue where the Sales 3 menu on the website would overflow when multiple menu items were added. The fix prevents the parent element from overflowing, ensuring the menu displays correctly regardless of the number of items. This improves the user experience for customers using the Sales 3 template.
Original PR description
Scenario: - edit the website navbar and set template "Sales - 3" (penultimate) - edit menu to add several menu items that will be larger than possible Result: the menu overflows Cause: a parent element of the menu doesn't overflow, so when computing autoHideMenu where we compute what overflow the list of menu, nothing overflows it since the overflow already happened in the limitless parent element. Fix: using CSS to prevent the parent from overflowing. opw-5178552 __pr note:__ this is happening in 17.0 but I'm targeting 18.0 since the ticket is in 18.0 and code is the same in 18.0 up to master.
This update fixes an issue where the total order amount was incorrect when using 'LOT' tracked products with groupable UoMs in the Point of Sale (PoS) system. The fix ensures that the price unit is consistently applied to the converted quantity, resulting in accurate order totals. This improves the reliability of PoS transactions for products managed with LOT tracking.
Original PR description
Steps to reproduce ------------------ 1. Make a product tracked by 'LOT' and having a groupable in pos UoM 2. Make a SO with that product, choosing another UoM from the same category (if we chose Kg in first step, choose gram here, etc) 3. Settle the order in PoS. We observe that the order's total amount is totally off, we explain why below. Why it's happening ------------------ The `lot_remaining_quantity` is quantity after converting to the original UoM (that of step 1, not that of step 2). We are using that quantity for lines having products tracked by 'LOT' and a groupable UoM; however, we are keeping price unit as if we are using the quantity before conversion, i.e. the quantity in the UoM of step 2. That creates a mismatch between the UoM and thus we miscalculte the total price. The fix ------- When using the converted quantity, also use the converted price unit. opw-5144326
This update resolves an issue where portal users couldn't update lead data after a recent security change. The team implemented a temporary workaround using 'sudo()' to grant necessary write access, ensuring portal users can now modify leads as intended. This maintains seamless data synchronization between the portal and the CRM.
Original PR description
## Steps to reproduce: - Install 'website_crm_partner_assign' module. - Create a partner X with a partner level. - Save and go to "Opportunities". - Create an new opportunity. - Edit it and set the…
## Steps to reproduce: - Install 'website_crm_partner_assign' module. - Create a partner X with a partner level. - Save and go to "Opportunities". - Create an new opportunity. - Edit it and set the partner X as the assigned partner - Grant the partner x portal access and change his password. - Logout then login with the partner X credentials. - Go to "My account" page and click on "Opportunities" - Select the opportunity Y and edit the revenue or another field. - Traceback on save. (Or no reaction, popup traceback from notification) ### Issue: Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead. ### Solution: To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead. opw-2764563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237599
This update fixes a visual inconsistency in the Point of Sale (POS) system. Previously, product images were always displayed in combo product configurations, regardless of the user's settings. Now, the combo product configurator correctly respects product image visibility settings, ensuring a consistent and professional user experience across all product types.
Original PR description
Before this commit: ==================== In POS, when product images were configured to be hidden, the setting was correctly applied to normal products. However, in the combo product configurator, product images were still displayed, causing inconsistency with the configured behavior. After this commit: ====================== The combo product configurator now respects the product image visibility configuration, ensuring consistent behavior across all product types in the POS interface. Task-5163955
This update resolves a problem preventing Argentinian users from completing the checkout process. The system was failing to recognize required tax information fields, leading to an error. The fix ensures these fields are correctly displayed and validated, allowing users to proceed with their purchase.
Original PR description
Versions -------- - 18.0 `l10n_ar_website_sale` was removed in later versions via 5a93da8e9220 Steps ----- 1. Create a partner with an address; 2. set up a company with Argentinian localization; 3.…
Versions -------- - 18.0 `l10n_ar_website_sale` was removed in later versions via 5a93da8e9220 Steps ----- 1. Create a partner with an address; 2. set up a company with Argentinian localization; 3. assign website to Argentinian company; 4. as partner, go to website & add something to your cart; 5. go to checkout. Issue ----- Cannot get past the address form. Cause ----- The `l10n_latam_identification_type_id` and `l10n_ar_afip_responsibility_type_id` fields are required, but not shown. Because they're not editable, the `website_sale` controller doesn't consider them "missing", making the `l10n_ar_website_sale` override not handle the missing fields. Going to "My Account" to edit details also doesn't allow you to add them, as the form lacks the `can_edit_vat` value. Solution -------- Instead of relying on the `missing_fields` value from the base method call, have the `_validate_address_values` override explicitly check the presence of those fields in either the address values or the current partner record (adding them to address values if it's the latter). If the values are missing, show an error message telling the client to add the missing info via "My Account". In the portal controller, provide the `can_edit_vat` value to make the fields editable. opw-5376149