Daily updates from Odoo
Navigate
Branch
Monday, February 19, 2024
46 changes
4 changes
Resolved issues and error corrections
This update resolves a technical issue where the VAT field on partner records was incorrectly overriding the autocomplete feature. The fix reorganizes the display of VAT information, ensuring the autocomplete functionality now works as expected. This improves the accuracy of VAT data entry.
Original PR description
The xpath used in the res_partner_view replaces the vat field with a div, containing the partner vat and the VIES valid field (such that they are displayed on a single row). This results in the partner-autocomplete being removed from the field. The solution is to make a div, and a subsequent xpath that moves the "vat" field into this div (alongside the vies valid field). This no longer overrides the partner-autocomplete xpath. task-id: none Forward-Port-Of: odoo/odoo#154506 Forward-Port-Of: odoo/odoo#138528
This update enhances the way contract dates are filtered within the HR system. Previously, users could only filter by month, quarter, or year, which has now been expanded to include more granular date selection options. This improves the efficiency and accuracy of contract management.
Original PR description
This will add options for month, quarters and year selection to the start and end dates filters. Task: 3725209 Forward-Port-Of: odoo/odoo#152905
This update resolves a bug where the comparison price (strikethrough) remained visible on the website even after disabling the setting in the database. The fix ensures the strikethrough price only appears when the comparison price setting is actively enabled, improving website consistency.
Original PR description
**Current behavior:** Enabling the 'Comparison Price' setting and filling out the field will result in this strikethrough price appearing even after disabling the setting. **Expected behavior:** The…
**Current behavior:** Enabling the 'Comparison Price' setting and filling out the field will result in this strikethrough price appearing even after disabling the setting. **Expected behavior:** The strikethrough comparison price will only appear when the corresponding setting is enabled in the database settings. **Steps to reproduce:** 1. Enable the 'Comparison Price' setting in website settings 2. Select a product on the 'Shop' page of the website and edit it so it has a comparison price != to its regular one 3. Save product changes, go back to the db settings and disable the 'Comparison Price' setting 4. Go back to the website 'Shop' page and observe that the strikethrough comparison price is still displayed **Cause of the issue:** In the product.template model in website_sale, the price values are modified to those informed by the compare_list_price value independent of the current value of the corresponding database setting. It only checks if there is non-False value in the field. **Fix:** Look at the 'Comparison Price' setting before the price modification/calculations take place and skip them if it's False. opw-3705079 Forward-Port-Of: odoo/odoo#154274 Forward-Port-Of: odoo/odoo#151734
This update resolves an issue where custom attributes weren't consistently applied when closing product configuration forms. The team has reverted a specific workaround and now uses standard Odoo methods for configuration updates, ensuring all custom attributes are correctly saved and applied. This improves the reliability of product configuration workflows.
Original PR description
Updates to existing product configurations with custom attributes were not correctly applied on configurator closure. This was probably caused by a recent update in the framework. Nevertheless, to solve the problem, this commit drops the use of custom code used only by the configurator to stick to the standard usage of magic commands. Fixes #152647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152934
16 changes
Enhancements to existing features
Job listings in the recruitment kanban now follow the website recruitment ordering instead of being changed by referrals. This keeps published and newly created jobs displayed in the expected order for recruiters and visitors.
Original PR description
Before this commit, the job order on kanban view was override by hr_referral module but with this task we want to keep the behaviour of website_hr_recrutment module. Now the order is decided by published date and job's creation date (behaviour of website_hr_recruitment) task: 3610490
Odoo can now synchronize currency exchange rates using the Bank of Thailand's official API. This helps businesses working with Thai baht use a local trusted source, with rates pulled from the previous day because current-day rates are not provided.
Original PR description
Adds the possibility to synchronize exchange rates using the API provided by the Bank Of Thailand (BOT). Rates are synchronized using yesterday as a date, as they do not provide rates for the current day. Task id # 3724438
Administrators can now grant selected users permission to apply inventory adjustments without making them full administrators. This makes stock operations easier to delegate while keeping broader administrative rights restricted.
Original PR description
Before this commit ================== You need to be an admin to have the right to apply inventory adjustments. After this commit ================= Added a new security group named `group_stock_user_apply`. The admin can give access to any user by applying this group user will have access right to do inventory adjustments. Community PR: https://github.com/odoo/odoo/pull/149149 TaskId: 3651040
Barcode inventory workflows now handle demands below one unit more accurately, making it easier for users to fill requested quantities with the plus button. Source and destination locations are also shown consistently, improving clarity during warehouse operations.
India payslips now show the employee's department. This gives payroll and finance teams clearer context for reporting and timing-related payroll processes.
Original PR description
We add the employee's department to their payslips to help with financial timing, task-3649463
The Sign app no longer uses an outdated customization for language selection because the underlying behavior now already does what is needed. This reduces unnecessary maintenance while keeping the signing experience unchanged for users.
Original PR description
See community counterpart, `get_available()` got renamed. The equivalent of `get_available()` is now only returning the active language, which makes this override not needed anymore. Note that the test modified here was introduced with this commit: https://github.com/odoo/enterprise/commit/88c846e910ad25546d4b35355c4d9c337825b9f5
Resolved issues and error corrections
This update prevents an error from appearing in the Payroll dashboard warning setup. It replaces an invalid development-mode value with the expected text, helping users avoid a traceback during configuration.
Original PR description
We made the following point. - Remove Python code from dev mode. - A traceback occurs when we set `return 0` in Python code. However, we have replaced `return 0` with the correct string in this commit. task-3729569
Referral point records now show a clear name and point value in all cases, including when the value is zero. This prevents records from appearing as unnamed, making referral tracking easier and less confusing for users.
Original PR description
This commit improve the display of hr_referral_points records by preventing the name to be 'unnamed' and by displaying the number of points in every situation even when the number of points is 0. The reason of unnamed seems to be that the record is interpretted as "False" when it's value is 0 task-3667797
Features or functions removed from Odoo
The unused Danish EDI module has been removed because it no longer provided any business function. This simplifies the product by eliminating obsolete components without affecting Danish localization behavior.
Original PR description
Remove the module l10n_dk_edi as it does not do anything anymore.
Code cleanup and technical improvements
The Website Sale Renting settings were adjusted to align with updated label formatting behavior. This keeps configuration screens visually consistent after labels are no longer automatically capitalized.
Original PR description
See community commit for details.
This update reorganizes demo data for several country localizations so accounting and HR apps can share one demo company instead of creating duplicates. This makes testing more consistent when multiple localized apps are installed together, without changing day-to-day business workflows.
Original PR description
Up until now, we did not have any common demo data package for localizations. This is an issue for localizations having both accounting and hr packages, because these do not depend on each others. It means that to have complete demo data individually, they need to define demo company in both cases. This leads to duplication in demo companies for a single country when both packages are installed, which is not ideal for testing as it also means that demo data is split between multiple companies. This commit will rename things a bit to bring a common demo data package for multiple localization. l10n_xx as it is known today becomes l10n_xx_account (as it was all along an invoicing module). l10n_xx is instead a new module containing the demo company data. task id # 3555251
Miscellaneous changes
…roduct and no plan We prevent creating subscription sale orders with recurring products and no recurring plans However it's better to be defensive to avoid crashes. This commit adds an additional condition before accessing order_id.plan_id closes odoo/enterprise#56160 Task: 3725476 Forward-Port-Of: odoo/enterprise#56464 Forward-Port-Of: odoo/enterprise#56426
Original PR description
…roduct and no plan We prevent creating subscription sale orders with recurring products and no recurring plans However it's better to be defensive to avoid crashes. This commit adds an additional condition before accessing order_id.plan_id closes odoo/enterprise#56160 Task: 3725476 Forward-Port-Of: odoo/enterprise#56464 Forward-Port-Of: odoo/enterprise#56426
We revert the following commit because payment_utils.generate_access_token is working with request.env which is not available in cron. The change should be done in master after modifying generate_access_token to accept an env parameter allowing to be called in cron and regular flow. https://github.com/odoo/enterprise/commit/d0618c4f042806b3336de759ebd0a1fe96f193c1#diff-df4c76c88a3be1689c375cb4c80009af33c77ccb60b5f604988565309c1f4773 taskid: 3640650 Forward-Port-Of: odoo/enterprise#56523
Original PR description
We revert the following commit because payment_utils.generate_access_token is working with request.env which is not available in cron. The change should be done in master after modifying generate_access_token to accept an env parameter allowing to be called in cron and regular flow. https://github.com/odoo/enterprise/commit/d0618c4f042806b3336de759ebd0a1fe96f193c1#diff-df4c76c88a3be1689c375cb4c80009af33c77ccb60b5f604988565309c1f4773 taskid: 3640650 Forward-Port-Of: odoo/enterprise#56523 Forward-Port-Of: odoo/enterprise#56474
Steps to reproduce ================== - Go to Sales > Quotation - Open studio - Click on Reports - Open the "Quotation / Order" report - Inside the Sale order lines, type /field - Click on "Product >" - Type "128" => The "Image 128" field is missing, only the "Variant Image 128" is displayed Cause of the issue ================== Only searchable fields were displayed opw-3713666 Forward-Port-Of: odoo/enterprise#56500 Forward-Port-Of: odoo/enterprise#55839
Original PR description
Steps to reproduce ================== - Go to Sales > Quotation - Open studio - Click on Reports - Open the "Quotation / Order" report - Inside the Sale order lines, type /field - Click on "Product >" - Type "128" => The "Image 128" field is missing, only the "Variant Image 128" is displayed Cause of the issue ================== Only searchable fields were displayed opw-3713666 Forward-Port-Of: odoo/enterprise#56500 Forward-Port-Of: odoo/enterprise#55839
… period In case the period is locked, don't try to cancel the document to avoid the UserError saying you are in a locked period. Instead, don't block the user. That way, he can manage this case manually outside of the locked period. task_id: 3750701 Forward-Port-Of: odoo/enterprise#56723
Original PR description
… period In case the period is locked, don't try to cancel the document to avoid the UserError saying you are in a locked period. Instead, don't block the user. That way, he can manage this case manually outside of the locked period. task_id: 3750701 Forward-Port-Of: odoo/enterprise#56723
…and renting products Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both boxes enabled. Steps to reproduce: ------------------- * Go to **Rental** App * Select Products * Create a new product * Enable Reccuring and Can be Rented * Save Why the fix: ------------ https://github.com/odoo/enterprise/commit/2579b5896a4c5e949d30a0a51f18437
Original PR description
…and renting products Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to…
…and renting products Currently, it is possible to create a product which can be rentable and recurring. This fix intends to replicate the behavior of previous versions where it was impossible to save a product with both boxes enabled. Steps to reproduce: ------------------- * Go to **Rental** App * Select Products * Create a new product * Enable Reccuring and Can be Rented * Save Why the fix: ------------ https://github.com/odoo/enterprise/commit/2579b5896a4c5e949d30a0a51f18437adc2b5db2 removed the dependence of sale_temporal for sale_subcription. After that, there was no point in keeping the sale_temporal dependence in sale_renting. Thus, the dependence for sale_temporal has also been removed here: https://github.com/odoo/enterprise/commit/6c86a278dbc752009c0985702cb2927c26f5f636. The module sale_temporal was responsible for checking incompatible products types. Currently, both sale_renting and sale_subscription have the module sale in common. This commit is part of a 2-part fix and targets Odoo Enterprise. It re-introduces the constraints on 'rent_ok' and 'reccuring_invoice'. Code re-introduced: * https://github.com/odoo/enterprise/blob/da031dd50501af0b6c02fab804a9af33363d397c/sale_subscription/models/product.py#L12-L19 * https://github.com/odoo/enterprise/blob/da031dd50501af0b6c02fab804a9af33363d397c/sale_renting/models/product_template.py#L19-L26 PR in Community: https://github.com/odoo/odoo/pull/150688 opw-3678715 Forward-Port-Of: odoo/enterprise#56694 Forward-Port-Of: odoo/enterprise#54940
26 changes
Enhancements to existing features
This update improves the Swiss payroll module with corrections to field names and better alignment of data display columns. These changes enhance the accuracy and usability of payroll processing for Swiss operations, making the system more reliable and easier to use.
Original PR description
Several improvements and issues correction on switzerland payroll : name correction, column alignment task : 3644541
The contract management system now provides more flexible filtering options for contract start and end dates. Users can now filter by month, quarter, or year in addition to the previous options, making it easier to find and organize contracts by time period.
Original PR description
This will add options for month, quarters and year selection to the start and end dates filters. Task: 3725209 Forward-Port-Of: odoo/odoo#152905
Resolved issues and error corrections
This update corrects a bug in the intrastat accounting report where a required parent line identifier was not being included in the report line data. This fix ensures that intrastat reports are generated correctly with complete line information, which is important for accurate customs and trade reporting compliance.
Original PR description
The `parent_line_id` parameter and value was missing from the generic line id. Forward-Port-Of: odoo/enterprise#56725
This fix resolves an issue where website layouts with more than 12 columns on mobile devices were not displaying in the correct order. Previously, the system used Bootstrap's built-in ordering classes which only support up to 12 columns. The fix switches to using inline styles instead, allowing any number of columns to be properly ordered on mobile devices without limitations.
Original PR description
Commit [1] introduced mobile orders for columns in flex containers snippets. This was later amended with commit [2] to use Bootstrap's `order-X` classes. Finally, to be complete, commit [3] also added some manipulations around mobile orders. Those classes are limited to 12 possible orders, which means the feature stops working for any column over that threshold: a column with `order-13` will appear as if it didn't have any order. In the end, it has been decided that the trade-off of being capped at 12 mobile orders (and so 12 columns) and the behavior it causes isn't worth using the classes: we will use inline style instead. [1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba [2]: https://github.com/odoo/odoo/commit/143bdfa13d331b93b88e207f181840d91796cdce [3]: https://github.com/odoo/odoo/commit/7b27385dba36c2e741d96e76ad5d847d09f2b084 task-3666688
This fix ensures that optional products added to recurring sale orders have their prices automatically adjusted when the order's subscription plan is changed. Previously, only the original order line items would update their prices, while optional products that were added to the cart would retain their old pricing, creating inconsistencies in the order total.
Original PR description
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is…
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is added to the cart and then the order is brought back into the editor view, should the recurring plan for the order be changed, the optional product (wihch is now added to the order) will not have its price adjusted accordingly. **Expected behavior:** The optional product that has been added to the order will have its price adjusted to match the recurring plan selected for the sale order. **Steps to reproduce:** 1. Create two distinct recurring products and assign them subscription prices for the same recurring plan timetable 2. Create a new sale order, adding one product to the order and the other to the optional products tab 3. Preview the sale order and add the optional product to the cart, then return to the editor view 4. Select a new recurring plan for the sale order where each product has a different set price than the one which is currently displayed on the order lines 5. The product which was initially added in an order line will have its price adjusted accordingly, while the product which was added from the optional products section will remain static. **Cause of the issue:** In sale_management, the _compute_price_unit() method is extended such that it filters SOLs which have order options associated with them. **Fix:** Add a condition to the filter which will keep the lines to have their price recomputed if their associated products are recurring products. opw-3698798
This fix resolves an issue where custom product attributes were not being saved properly when closing the product configurator. The problem was caused by recent framework changes, and has been fixed by simplifying the code to use standard system commands instead of custom workarounds. This ensures that any customizations users make to product configurations are now correctly applied and saved.
Original PR description
Updates to existing product configurations with custom attributes were not correctly applied on configurator closure. This was probably caused by a recent update in the framework. Nevertheless, to solve the problem, this commit drops the use of custom code used only by the configurator to stick to the standard usage of magic commands. Fixes #152647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug where delivery charges were incorrectly counted toward loyalty program purchase requirements. Previously, when customers proceeded through checkout, the delivery line item was being included in the quantity calculation, causing loyalty discounts to appear prematurely. Now delivery items are properly excluded from loyalty program conditions, ensuring discounts only apply when actual product purchases meet the minimum requirements.
Original PR description
[[FIX] sale_loyalty: delivery shant count toward qty bought](https://github.com/odoo/odoo/pull/149279/commits/8aa4e598efdf6c3794edf5cc2db0e9484d528ef2) This commit excludes delivery programs from…
[[FIX] sale_loyalty: delivery shant count toward qty bought](https://github.com/odoo/odoo/pull/149279/commits/8aa4e598efdf6c3794edf5cc2db0e9484d528ef2)
This commit excludes delivery programs from being counted
towards rewards for loyalty programs.
Prior to this commit, there was an issue steaming from the Standard Delivery
line being added to the Sales Order during the transition from the
"Review Order" screen to the "Confirm Order" screen. This flow illustrated
that loyalty programs count delivery line toward rewards for loyalty
programs.
[Reproduce]
- Install Odoo with modules: sale_loyalty,website_sale,delivery
- Create a loyalty program:
- Enable "Discounts, Loyalty & Gift Card."
- Create a program with type "Promotions."
- Set program conditions:
- Minimum Quantity: 2
- Minimum Purchase: 0
- Grant 1 point per order
- Among Product Domain "Match all records."
- Set program Rewards:
- Type: Discount
- In exchange for 1 promo point.
- Navigate to the front-end shop:
- Select 1 item.
- Add it to the cart.
- Proceed to Checkout.
- Ensure there is one item (you need 2 for the discount).
- "Proceed to Checkout" (delivery is added to the Sales Order at this point).
- Click "Review Order" to go back.
- BUG: The discount is shown in the "Review Order" screen.
opw-3675387
Forward-Port-Of: odoo/odoo#149279The live chat widget was displaying Odoo error dialogs on external websites where it was embedded, disrupting the user experience. This fix removes the error notification service from the embedded live chat so that only errors from the chat itself are handled, not errors from the host website.
Original PR description
Before this commit, an Odoo dialog would open to show errors that occurred in the pages embedding the live chat. We should not display errors originating from outside the embedded script. Moreover, the error service listens to the error event on the window object. Thus, errors occurring in the shadow DOM won't be caught. As a result, the error service disrupts the site that embeds it and is entirely useless for the live chat. This PR removes the error service from the embedded live chat. OPW-3699040 Forward-Port-Of: odoo/odoo#154012
This fix resolves an issue where multiple quiz windows would appear when users quickly clicked the 'Done' button after completing a quiz in the eLearning app. The problem occurred because the system was loading multiple quiz instances simultaneously. The fix prevents this by ensuring only one quiz loads at a time, improving the user experience and reducing unnecessary server requests.
Original PR description
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed…
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed if your connection is slow or you click fast enough. The fix ensures that only one quiz is displayed. We do the same change for video to prevent such problem with them. Technical note: when clicking on the "green tick" of the quiz, the method _toggleSlideCompleted is called which cause a _renderSlide. That method clears the content div (o_wslides_fs_content) and appends a new Quiz widget to that div. The problem is that the "append" is asynchronous (it call the "willStart" of Quiz widget that fetch the quiz) so if you click multiple time, the content div is cleared multiple times and then after each quiz created is ready (after having fetched the data), they are appended to the content div, resulting in multiple quiz displayed. We solve the problem by avoiding concurrent execution of the _renderSlide method: the body of the method is skipped when the rendering is ongoing (for example while waiting the quiz from the server). As the method is inserting the slide at the same place, its behavior was anyway unpredictable because depending on the response time of each request. By skipping the method body while already running we make it a bit more predictable, avoid the content duplication on the page, and we avoid unnecessary call to the server. Task-3412847 Forward-Port-Of: odoo/odoo#153819 Forward-Port-Of: odoo/odoo#143743
This fix resolves a technical error that occurred in the inventory list when users didn't have access to print or action menu options due to their permissions or system customization. After this update, users will no longer experience errors when selecting lines in the inventory list, regardless of which menu options are available to them.
Original PR description
Description of the issue/feature this PR addresses: Depending on user rights or customization, "Print" or "Action" menu can equals to "undefined". This causes a client error when selecting lines in the tree view. Current behavior before PR: javascript error " TypeError: print/action is undefined" is raised when selecting lines in the inventory list tree view. Desired behavior after PR is merged: No error raised if user has no print/action menu available. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152751 Forward-Port-Of: odoo/odoo#152301
This fix resolves an issue where PEPPOL endpoints were not being calculated correctly when a VAT number was entered for a contact. The system now properly recognizes VAT numbers from different countries (like a French VAT number for a Belgian contact) and intelligently determines the correct country based on the VAT number prefix or Italian tax ID, ensuring accurate electronic invoice routing across European partners.
Original PR description
1. set a country like belgium 2. set a VAT number like BE123456789 => peppol_endpoint is not computed This is because some dependencies are missing on the field (current is: "country_code"). Step 1: Add the missing dependencies to the field (and improve the tests to make sure it works). Step 2: Try to make the code smarter! If the country_code is BE but the VAT number starts with FR, consider it's FR, not BE. If the codice_fiscale is set, it's IT whatever the country_code. If the VAT number has no ISO country code, use the country_code in that case. task-3690913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150231
When users resized a table in the website editor and pressed undo, the entire table would be removed instead of just undoing the resize. This fix ensures that resizing a table is properly saved as a single action, so undo only reverses the resize operation itself rather than removing the table entirely.
Original PR description
Issue: ===== Undo of resize operation on table do 2 undos in a row. Steps to reproduce the issue: ============================= - Go to website editor - Add a text block - write `/table` to insert a table - Resize the table - Press `ctr+z` to undo - The table is removed Origin of the issue: ==================== The resize operation wasn't saved a step and is considered as draft then it will be discarded and then the undo applied on the last saved step that's why it appears as 2 undo in a row. Solution: ========= Call `historyStep` when we stop resizing. task-3743697 Forward-Port-Of: odoo/odoo#153809
This update prevents users from creating refund orders from multiple invoiced orders at once. Previously, users could attempt this action, but the refund order would fail when trying to invoice it because it was linked to multiple invoices. This fix removes that problematic option upfront, improving the user experience and preventing failed transactions.
Original PR description
Before this commit, users could create a refund order from multiple invoiced orders. However, such an order could not be invoiced as it was associated with more than one account_move, leading to a failure. This commit fixes this issue by preventing users from creating a refund order from multiple invoiced orders. opw-3710539 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154072 Forward-Port-Of: odoo/odoo#153693
This fix addresses a technical issue where electronic invoices (UBL/CII format) were displaying incorrect unit prices due to floating-point precision errors. When calculating prices by dividing subtotals by quantities, the system could produce values like 102.14999999999999 instead of 102.15. The fix applies reasonable rounding to ensure prices display correctly in electronic invoices sent to customers and tax authorities.
Original PR description
We no longer round the PriceAmount since 0fd7284158483bce3308e7c5ba42e3c6ee5abd10. But then, we may encounter a representation error if the PriceAmount is not exactly representable as a binary fraction (see: https://docs.python.org/3/tutorial/floatingpoint.html#representation-error). For instance: having a line with `price_subtotal` = 306.45 and `quantity` = 3, we will compute the PriceAmount as 306.45 / 3 which yields 102.14999999999999. To avoid such a case we round "reasonably" the PriceAmount. opw-3729369 Forward-Port-Of: odoo/odoo#154286 Forward-Port-Of: odoo/odoo#153999
This update fixes an accessibility issue where dropdown menus on websites weren't showing a visible outline when navigated using the Tab key on a keyboard. While the outline was intentionally hidden for mouse hovering to keep the interface clean, keyboard users need this visual indicator to know which menu item they're focused on. The fix restores the outline for keyboard navigation while maintaining the clean appearance for mouse users.
Original PR description
Since commit [1], there is no outline when focusing a hoverable dropdown by using the Tab key. This happens because of a CSS rule that was added so no outline would appear when hovering the dropdown…
Since commit [1], there is no outline when focusing a hoverable dropdown by using the Tab key. This happens because of a CSS rule that was added so no outline would appear when hovering the dropdown menus with the mouse. However, it should still be displayed when using the keyboard, for accessibility reasons. This commit fixes that by always allowing the focus on the hoverable dropdowns, except when they are hovered. If a focus was present on an element in the document when hovering, its focus is kept (to have the same behavior as in previous versions). Steps to reproduce: - Add a submenu and a mega menu with the menu editor. - In edit mode, set the dropdowns as hoverable (set the "Sub Menus" option to "On Hover") and save. - Use the Tab key to navigate through the menus. => The simple menus have an outline but this is not the case for the dropdowns. [1]: https://github.com/odoo/odoo/commit/5846a05fe7bf587d3bfb3ace3e863cb4abd52132 task-3709755 Forward-Port-Of: odoo/odoo#154444 Forward-Port-Of: odoo/odoo#151825
This fix restores the autocomplete feature for the VAT field in partner records. The previous layout change was inadvertently removing the autocomplete functionality. The solution reorganizes how the VAT and VIES validation fields are displayed together without disrupting the autocomplete feature, ensuring users can still benefit from automatic partner suggestions when entering VAT information.
Original PR description
The xpath used in the res_partner_view replaces the vat field with a div, containing the partner vat and the VIES valid field (such that they are displayed on a single row). This results in the partner-autocomplete being removed from the field. The solution is to make a div, and a subsequent xpath that moves the "vat" field into this div (alongside the vies valid field). This no longer overrides the partner-autocomplete xpath. task-id: none Forward-Port-Of: odoo/odoo#138528
This fix ensures that when a sales order includes negative quantities (returns) for products with "delivered quantities" invoicing, the system now correctly updates the delivered quantities and includes these lines in invoices. Previously, negative quantity lines were ignored during invoicing, causing incomplete invoice records.
Original PR description
Current behavior: - Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks.…
Current behavior: - Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks. However, when this delivery is validated, the delivered quantities are not updated on the SO. This is problematic as these quantities are therefore not taken into account on the associated invoice. Expected behavior: - The delivered quantities should be updated negatively on the SO to enable the invoicing of these lines. This is already the behavior in the POS application and when you create an SO with positive quantities followed by a return for a larger quantity than the one delivered. Steps to reproduce: - Create a storable product with an invoicing policy of type "delivered quantities". Create an SO with 2 lines: - a line with positive quantities for any other product. - a line with negative quantities for the product you created. Confirm and validate the corresponding deliveries. Return to the SO. The quantities for the second line are not updated. Create an invoice. The second line is not taken into account. Cause of the issue: - The to_refund field of the stock.move model defined in the stock_account module enables a decrease of the delivered quantities in the associated Sale Order. This field is set to True for "classic" returns but not for the stock.move generated from sale.order.line with negative quantities. Fix: - We rely on the _get_custom_move_fields method to add the to_refund field in the procurement 'values' arguments in case the stock_account module is not installed. It is then available to use in the _get_stock_move_values method where we set its value to True if the quantity is negative (so that the move should be considered as a refund). opw-3676045 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152466
This fix resolves a crash that occurred in the web editor when users pressed arrow keys at the edge of edited text. The issue happened because the editor was trying to access properties of a node that didn't exist in the proper editing area. Now the editor correctly handles these keyboard interactions without crashing.
Original PR description
Steps to reproduce:
1. Type a backtick
2. Type "A"
3. Type a backtick
4. Hit Left Arrow key
5. Hit Right Arrow key 2x
This led to a traceback ("Cannot read properties of null (reading 'isContentEditable') at OdooEditor._onKeyDown") because using `nextLeaf` without specifying the editable bounds returned a node that was not within these bounds, and a subsequent call to `closestElement` on this node returned `null` as a result.
task-3749506
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154365
Forward-Port-Of: odoo/odoo#154217This fix prevents the system from unnecessarily overwriting existing supplier routes when marking a product as having a supplier. Previously, clicking "Set as Supplier" would always replace the route, even if a valid one was already configured. Now the system only updates the route if needed, preserving your existing supplier route settings.
Original PR description
Description of the issue/feature this PR addresses: When clicking on "Set as Supplier", the route will always be overwritten, even if the current one selected fit the requirements (action = 'buy'). Desired behavior after PR is merged: action_set_supplier doesn't have to overwrite the orderpoint.route_id if it already has one that fit the requirements (action = 'buy'). https://drive.google.com/file/d/11zFCUWcQDlpTwjs7fdaGsUpSYnvcT2Id/view?usp=sharing --- OPW-3746624 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154184
This fix resolves an error that occurred when creating a sales lead for a customer who doesn't have an email address on file. Previously, the system would crash when trying to process leads without email information. Now users can successfully create leads for any customer, regardless of whether they have email contact details.
Original PR description
[FIX] crm: allow lead creation with partner without email Issue: When trying to create a lead for a partner that has no email. It raises an error that the email is null. This happens because the code expects 'emails' to contain email_from, even though it could just be email_cc in there. Steps to reproduce: 1- Install CRM app. 2- Enable leads in CRM settings 3- In sales menue choose customers 4- Create a new customer without providing an email 5- Choose Leads 6- Create a new lead using the newely created customer 7- You get "AttributeError: 'bool' object has no attribute 'lower'" in line: https://github.com/odoo/odoo/blob/8e17a4d76bbdd547536e62ee12a2c514a16d1700/addons/crm/models/crm_lead.py#L1873 Solution: The main issue is the code relies on the email to provide a name for the lead, so we need to check if there's an email provided beforehand opw-3681485 Forward-Port-Of: odoo/odoo#154083 Forward-Port-Of: odoo/odoo#150394
This fix corrects how the Time Off calendar handles multi-day selections. Previously, when employees selected multiple days on the calendar, the system would incorrectly use the first selected day as the end date. Now it correctly uses the last selected day as the end date, ensuring accurate time off requests.
Original PR description
Before this commit, highlighting several days from the calendar view in Time Off would still take the first day selected as the default date_to. The expected behaviour is that it should be the last day highlighted instead. Forward-Port-Of: odoo/odoo#154388
This fix resolves an issue where clearing an autocomplete field and then clicking away would not save the cleared value. Users would find that previously selected values remained saved even after being cleared. The fix ensures that clearing an autocomplete field and moving focus away properly triggers the save action, so cleared values are correctly persisted when saving records.
Original PR description
This commit fixes a pretty specific issue within autocomplete behavior where the change event after clearing the value is prevented. Steps to reproduce: - go to an empty autocomplete and click on it…
This commit fixes a pretty specific issue within autocomplete behavior where the change event after clearing the value is prevented. Steps to reproduce: - go to an empty autocomplete and click on it - start typing a search with results - click on the first result - without focusing out, clear the input and finally click out No change event is triggered on click out in this case so the cleared value is not updated in the end and saving the record will keep the non cleared value. The t-on-mousedown.prevent in the dropdown was mainly used to keep the focus on the input after selecting a value for the autocomplete. This introduces a side effect: when one starts typing on the initially empty autocomplete, the browser keeps the initial value of the input in memory until it is focused out (and therefore blurred). When the input is focused out, it will compare the current value of the input with the stored initial value and decide to trigger a change event based on the comparison between the two values: if these are different, the change will trigger. In our case, since the mousedown event on a search result is prevented, no focus out will happen and therefore the browser will still wait for the next focus out to trigger the eventual change event. But since we clear the input before focusing out, the two values are empty and no change event is triggered which introduces the issue. To fix it, we remove the t-on-mousedown.prevent of the template and manually avoid triggering the onInputBlur method with a flag to keep the previous behavior and we finally focus on the input programatically after selecting a value. task-3734818 Forward-Port-Of: odoo/odoo#154307 Forward-Port-Of: odoo/odoo#154203
This fix resolves a warning that occurs when creating invoices in Saudi Arabia with customer phone numbers. The issue was caused by the phonenumbers library automatically formatting phone numbers with spaces, which exceeded the maximum character limit allowed by the Saudi invoicing system. The fix prevents this unwanted formatting to ensure invoices process without warnings.
Original PR description
Steps to reproduce: [l10n_sa_edi] [phonenumbers must be pip installed] - create a customer with all needed information - create an invoice with the customer - confirm and process Issue: There will be a warning Cause: `phonenumbers` format the phone numbers with spaces -> len(phone) > max size authorized by api Note: revert the https://github.com/odoo/odoo/pull/148124 and only apply the fix for l10n_sa_edi in order to avoid test break from https://github.com/odoo/odoo/blob/dceaf735fd2e46342dcd144c1969853a55d7b661/addons/l10n_account_edi_ubl_cii_tests/tests/test_xml_ubl_de.py#L104 opw-3666195 Forward-Port-Of: odoo/odoo#153083
This fix resolves an issue where creating a gamification challenge with a "sum" goal definition would fail to start. Users can now successfully create and launch challenges that automatically sum values on a field without encountering errors. This enables the gamification feature to work as intended for team engagement and motivation.
Original PR description
Description of the issue/feature this PR addresses:
Creating a challenge with a goal definition set to "sum" mode failed to start
- Open Settings/Gamification Tools/Challenges
- Create a new challenge
- Keep "Assign Challenge to" with default values
- Need a domain that return some user
- Create and Edit a goal
- Computation Mode: "Automatic: sum on a field"
- Save & Close
- In reward Tab set "For Every Succeeding User"
- Save
- Start Challenge
Current behavior before PR:
- Traceback due to wrong aggregate value
- Challenge is not started
Desired behavior after PR is merged:
- Challenge is started
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154547This fix ensures that strikethrough comparison prices only appear on your website when the 'Comparison Price' setting is enabled. Previously, comparison prices would continue to display even after disabling this setting, creating confusion for customers. The system now properly checks the setting status before showing these prices.
Original PR description
**Current behavior:** Enabling the 'Comparison Price' setting and filling out the field will result in this strikethrough price appearing even after disabling the setting. **Expected behavior:** The…
**Current behavior:** Enabling the 'Comparison Price' setting and filling out the field will result in this strikethrough price appearing even after disabling the setting. **Expected behavior:** The strikethrough comparison price will only appear when the corresponding setting is enabled in the database settings. **Steps to reproduce:** 1. Enable the 'Comparison Price' setting in website settings 2. Select a product on the 'Shop' page of the website and edit it so it has a comparison price != to its regular one 3. Save product changes, go back to the db settings and disable the 'Comparison Price' setting 4. Go back to the website 'Shop' page and observe that the strikethrough comparison price is still displayed **Cause of the issue:** In the product.template model in website_sale, the price values are modified to those informed by the compare_list_price value independent of the current value of the corresponding database setting. It only checks if there is non-False value in the field. **Fix:** Look at the 'Comparison Price' setting before the price modification/calculations take place and skip them if it's False. opw-3705079 Forward-Port-Of: odoo/odoo#154274 Forward-Port-Of: odoo/odoo#151734
Users experienced an unwanted scrollbar appearing in the spreadsheet share dropdown menu when using non-English languages like French (BE). This fix adjusts the dropdown menu height to display properly without the unnecessary scrollbar, improving the user experience across different language settings.
Original PR description
## Description: Previously, an issue was observed where the dropdown menu of the spreadsheet's share button displayed a scroll bar when users had selected a different language, such as French (BE). This PR addresses the problem by setting the height of the dropdown menu to auto, thereby resolving the issue of unnecessary scroll bar. Task ID: [3742260](https://www.odoo.com/web#id=3742260&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#153834