Thursday, February 15, 2024
25 changes · 17.0
Enhancements to existing features
This update improves the performance of calendar searches by simplifying how the system filters events. Previously, the system was performing unnecessary database lookups when filtering by related record IDs. The change removes these redundant lookups when they're not needed, making calendar operations faster without affecting functionality.
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA warning message has been added to alert users when importing modules with demo data. This improvement helps users understand the implications of demo data installation and make informed decisions during the module import process.
Original PR description
task-3725221
This update optimizes how the system searches for users when handling complex database queries. Previously, the system would retrieve and process entire user lists even when not needed, causing slow performance on large databases. The fix skips this unnecessary processing when the search doesn't require a specific order, significantly reducing database load and query times.
Original PR description
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a…
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a `_name_search` on `res.users` with no limit to resolve the leaf when calling `_where_calc`. The current implementation in the `web` module overrides the `_name_search` to implement a spec to propose the current user as a first suggestion, but to do that it first execute the query (the list conversion), and then manipulates the list of ids to insert the current user first. (1c2ce8c213754aa47c51d68b6a8acd4770588864) On large databases with many `res.users`, where the condition matches all users besides 1, this is a probably Seq.Scan on the `res_users` table. Then this gigantic list of `ids` will be injected by the ORM into the main query to satisfy the original domain. This incurs not only bandwidth costs, but also usually leads to bad plans, ending up most likely into a Seq.Scan on the original table. The worse of it, in the case of a `web_search_read`, there is a `search_count`, so this whole fiasco is repeated once more. The nail in the coffin, is that the result isn't even needed, when resolving a comodel's `_name_search`, we care about the subset, the internal order is irrelevant. ## Solution The ORM calls the `_name_search` without a limit, while in general the `name_search` is called with a limit from the front-end, therefor we can use it as a discriminant -> If no limit, don't suggest `uid` first. ## Affected versions saas-16.3 -> master (saas-17.2) ## Reference task-3610657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152488
Resolved issues and error corrections
Point of Sale orders with the same product sold from multiple lots now create delivery records that correctly reflect each selected lot. This ensures inventory quantities are assigned to the right lots after closing a POS session, reducing stock discrepancies and manual corrections.
Original PR description
Current behavior: When you make an order in the PoS with different lots for the same product, the lots are not correctly selected in the picking. And only one lot is affected by the order. Steps to reproduce: - Create a product with tracking by lot, and 2 lots with some quantity - Create a PoS order with 2 lines of the same product, and select a different lot for each line - Validate the order - Close the PoS session - Check the picking, and the lot quantities Note: This partly revert this part of commit : https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-0ef4eb66998f308afe5f09748bc2af04ad79e9647507c25fe9007e03a79a1249L265-L303 And also make sure that the original created line quantity is set to 0 so that the each lot has a line, and the total quantity is correct. opw-3621363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where adding a product with the same attribute could unintentionally update existing order lines in Point of Sale. Attribute details now stay tied to the correct item, and attributes configured to be hidden are added to the order line note instead of being shown normally.
Original PR description
In the current system, the order widget experienced undesired updates to all order lines when a new product with the same attribute was added. Our recent changes address this issue, ensuring that existing attribute values remain unaffected by the addition of new ones. Moreover, we've refined the display of attribute information. If an attribute is designated as "never," it will now be incorporated into the order line note. Conversely, attributes with different settings will continue to be displayed in their usual format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now create 15-minute calendar events directly by dragging with the mouse. This prevents the calendar from mistakenly creating a default one-hour event, making scheduling short meetings more accurate and efficient.
Original PR description
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectange" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: --------- Thanks to the pointer, it is possible to know the original coordinates. We can use them with the following strong hypothesis: "If the origin coordinates along the Y axis are equal, a click is made." Note: ----- It is necessary to patch upstream when events are triggered. After that, we have to believe the information we receive and apply it. opw-3743945
This fix prevents users from creating products that are both rentable and recurring, which is not a supported configuration. Previously, a system module was responsible for enforcing this rule, but after recent changes, the validation was lost. This update restores the necessary checks to ensure data integrity and prevent configuration errors.
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
The MRP Master Planning module was displaying products in an inconsistent order that didn't match the system's standard product ordering rules. This fix ensures products are now sorted according to the proper product model settings (by default code, name, and other standard fields), making the display more predictable and consistent with how products appear elsewhere in the system.
Original PR description
The previous implementation returned data based on record computation order, and not the actual model `_order`. This is confusing for the user, and inconsistent with the`_order` defined on the model. Moreover the `product.product` model isn't ordered by `sequence`, but rather by [priority, default_code, name, etc](https://github.com/odoo/odoo/blob/99bcda76fbffe804eeb974cc225daa5324fb9418/addons/product/models/product.py#L80). In any case, by ordering by product_id the actual order will be taken from the related model, which makes more sense that an incorrect hardcoded one. ping @amoyaux Forward-Port-Of: odoo/enterprise#30093
This update fixes validation issues in the Chilean electronic invoice export system. It corrects how customs-related fields are validated (checking only fields required by Chilean customs authorities, not the tax authority), simplifies error messages to focus on currency mismatches, and updates translations for better user clarity. These changes ensure smoother invoice processing for businesses operating in Chile.
Original PR description
This PR replaces https://github.com/odoo/enterprise/pull/55511
This fix resolves a display issue where emoji icons and article titles were overlapping when knowledge articles were published and viewed by website visitors. The fix removes a previous workaround that is no longer needed since the underlying layout problem was resolved in the platform.
Original PR description
Install website, knowledge and website_knowledge, open any knowledge article and publish it to website visitor, then as a visitor access the public link of that article. In case the article had a emoji on top, that emoji and the title overlaps. This is a partial revert of commit 7a8fde881229 which introduced those changes in the layout to correct this same bug, also in 16.4, about the title icon and the title text overlapping. Reading the history, it seems that a generic frontend layout problem arose in 16.4 in july, that 7a8fde881229 fixed the bug but in knowledge only and that since then the generic frontend layout problem got resolved, obsoleting 7a8fde881229 here in december. References: 7a8fde881229 ([FIX] (website_)knowledge: fix various layout issues) Task-3525618 Forward-Port-Of: odoo/enterprise#52315
Fixed an issue where the WhatsApp template count wasn't updating after syncing templates from a WhatsApp Business Account. The page now refreshes automatically after syncing to display the correct number of templates, ensuring users see accurate information without manually reloading.
Original PR description
When the user tries to sync all the templates from `WhatsApp Business Account` the number of templates in the stat button is not updated. Steps to produce: - Create a `WhatsApp Business Account` - Click on `Sync Templates` Problem: The compute function `_compute_templates_count` is responsible for updating the `templates_count` field. But this compute function has no dependencies on it. So it will be called when the page is reloaded. Solution: The function `button_sync_whatsapp_account_templates` returns a `display_notification` for displaying the Template Created and Updated count. After this, we will reload the page using `soft_reload`. Task - 3619128 Forward-Port-Of: odoo/enterprise#51460
This fix allows accountants with invoice management rights (but not full admin access) to set Addenda information in customer and vendor contact records. Previously, this capability was restricted to administrators only. This change improves workflow efficiency for accounting teams managing Mexican EDI requirements without requiring full system administration privileges.
Original PR description
Allow user with accountant rights but not admin rihgts to set Addenda in contact view. The addenda is an ir.ui.view instance. This commit allows read access to this model to group_account_invoice group. Task: opw-3504839 Forward-Port-Of: odoo/enterprise#56478 Forward-Port-Of: odoo/enterprise#51384
The rental search feature was incorrectly showing product availability by checking inventory across all company warehouses instead of just the website's assigned warehouse. This fix ensures customers see accurate rental availability based on the specific warehouse serving their website, improving search accuracy and preventing overselling.
Original PR description
Rental search bar filtering didn't properly consider the website warehouse: * fetching all SOLs of the company regardless of their warehouse * computing the available quantity of products with the wrong contextual key, not restricting the quantities to the website warehouse. (correct context key is warehouse, not warehouse_id, cf `_get_domain_locations` in stock/models/product.py) Forward-Port-Of: odoo/enterprise#43224
A recent update to the Intrastat reporting feature introduced a conflict between two warning systems that prevented proper error notifications. This fix removes the outdated warning system and ensures the correct data is used when identifying problematic records, restoring proper error handling for users.
Original PR description
During a forward port (https://github.com/odoo/enterprise/commit/bb67df2f37a65acd9f62a28d8a52fbd335ef903e), we introduced a bug because the old warning system was in conflict with the new one. The aim of this commit is removing the old one (that are not working) for the new one. In the same time, we make sure that we use the right key when getting ids that have an issue. opw-3741287 opw-3741721 opw-3741658 Forward-Port-Of: odoo/enterprise#56683
Fixed an issue where pressing the Enter key on single-line survey questions (like text or number fields) would reload the form instead of submitting it. Users can now properly submit surveys by pressing Enter, improving the survey-taking experience and making the form behave as expected.
Original PR description
Steps to reproduce =================== 1. Create single-line questions like numbers and single-line text. 2. Test the survey. 3. Press the 'enter' key on a single line input. The form reloads and does not submit. Technical ========== With commit https://github.com/odoo/odoo/commit/7109f480ec27e929a43c4bae78912bad42458e90, a next button is added before the submit button, so when you press enter on single-line questions the first button of the form is clicked which refreshes the page without any action. Ref-https://github.com/odoo/odoo/blob/66b4e080e29551d1c74cdc4b3d9ccba92ce81dd1/addons/survey/static/src/js/survey_form.js#L116 After this PR ================= We can submit the form with the 'enter' key from single-line input. Task-3650231
This fix prevents users from accidentally creating products that are both rentable and subscription-based at the same time, which is not a supported configuration. The system will now block saving a product with both options enabled, restoring the behavior from earlier versions and ensuring data integrity in rental and subscription workflows.
Original PR description
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…
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 Community. It transfers the code responsible for the checking of incompatible product types in the module sale. Code transferred: https://github.com/odoo/enterprise/blob/4cf9e6f013f75c082c5b5b42b9d2591554b75503/sale_temporal/models/product_template.py#L15-L33 PR in Enterprise: https://github.com/odoo/enterprise/pull/54940 opw-3678715
Fixed a bug in the web editor where inserting a new icon would accidentally delete an existing icon in the same note. The issue occurred because the system incorrectly identified icon elements as empty blocks and removed them. Users can now add multiple icons without losing previously inserted ones.
Original PR description
Current behavior before PR: On inserting icon in note, it replaces another icon.It occurs because `isEmpty(block)` returns true, when block element was font-awesome, which causes the code in `insert` method to remove current node, resulting in removal of previous icon. Desired behavior after PR is merged: Now icon is added without replacing the another icon. task-3482264 Forward-Port-Of: odoo/odoo#134121
This update fixes two issues in the website event module: edit links in the website editor now properly open in the backend window instead of the iframe, and empty content sections are now correctly detected so that missing descriptions display appropriate notifications. These fixes ensure the event exhibitor editing experience works as intended.
Original PR description
Currently, links in the website editor always open in the iframe except for a few exceptions defined in `_isTopWindowURL` As the enable_editor parameter is only valid for the parent window containing the iframe clicking a link with `<a href="?enable_editor=1" has no effect. To fix this for the two cases we do have this message, we add `@` as the root of the path of the url. Which indicated we want to open a "back-end" route, which will be set in the parent window. We also fix the exhibitor version of this pop-up not showing up. task-3607615 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143162
This fix restores the ability to mention OdooBot in messages, which was broken by a recent update. The system now correctly includes archived users (like OdooBot) in mention suggestions while keeping them at lower priority. This ensures users can properly reference the OdooBot assistant in their communications.
Original PR description
1. Make sure to return archived users in partner format. 2. Remove the condition to check for archived users in suggestion code. The condition made no sense since the refactoring (that's the opposite of what we want, and it didn't compare the partner records correctly). The feature is broken since https://github.com/odoo/odoo/pull/133065/ because it "fixed" the way records are compared. Making the condition we don't want in the first place actually working and excluding OdooBot (instead of allowing it). 3. Since archived partners are displayed anyway since the refactoring, and nobody complained, let's consider it a wanted feature. Archived partners are given lowest priority and moved to the bottom. task-3747277
This fix enables automatic printing in Point of Sale to work with web printing, even when no physical printer is configured. Previously, automatic printing only functioned with a dedicated printer setup. This improvement provides more flexibility for businesses that prefer digital or web-based printing solutions.
Original PR description
Prior to this commit, automatic printing was only functional when a printer was configured with the Point of Sale. It did not support web printing. This commit rectifies this issue, allowing automatic printing to work seamlessly with or without a physical printer setup, supporting web printing. opw-3706400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a crash that occurred when attempting to print multiple invoices at once for Swiss companies using QR codes. The issue affected the invoice printing functionality in the German/Swiss invoice format module, and this update ensures invoices can be printed without errors.
Original PR description
### Steps to reproduce * install `l10n_ch_reports` * switch to a Swiss company * enable "QR Codes" in Settings > Accounting > Customer Payments * create and confirm two invoices for a Swiss partner * on the invoice list view, select and attempt to print the two invoices at once You should be met with traceback. opw-3697569 Forward-Port-Of: odoo/odoo#153903 Forward-Port-Of: odoo/odoo#153461
This fix resolves an error that occurred when users tried to set a default scheduled date for product replenishment. The system now properly handles date formats sent from the user interface, allowing the 'Set Defaults' feature to work correctly for date fields without displaying an 'Invalid type' error.
Original PR description
**Steps to reproduce:** 1- Install Sales module 2- Activate developer mode 3- Navigate to any storable product 4- Click on 'Replenish' 5- Click on 'developer bug' and Choose 'Set Defaults' 6- Choose 'Scheduled Date' from the 'Default' dropdown menu and Save **Current behavior before PR:** When trying to set a default value for scheduled date in 'Replenish' for a product it will display an error for 'Invalid type' this is happening because when converting the string value to a datetime value it does not handle iso format date and this is the format that gets passed from the UI. **Desired behavior after PR is merged:** It is handled now from the UI side that the format that is been sent is the server valid format of datetime. opw-3692472 Forward-Port-Of: odoo/odoo#150447
This fix resolves an issue where opening the Odoo web client was sending duplicate subscription requests through the messaging system. The problem occurred because the system wasn't properly tracking whether subscriptions had already been made, causing unnecessary duplicate requests. This update improves system efficiency by eliminating these redundant connection attempts.
Original PR description
Since 16.3, opening the web client on the Odoo backends results in two subscribe events being sent through the bus websocket. Discuss listens to the thread changes to know when the subscription should be refreshed. In order to do so, the last subscription that was made is kept. This issue is that this subscription is empty in the first place so the first evaluation always considers the subscription should be made. In order to fix this issue, this PR refine the condition to determine if the subscription should be renewed: - The last subscription is different from the last one - The user joined a channel after the bus initialization - The user left a channel after the bus initialization In order to test those scenario in a reliable way, this PR also backports https://github.com/odoo/odoo/pull/147455 Forward-Port-Of: odoo/odoo#154057 Forward-Port-Of: odoo/odoo#153666
Users can now create 15-minute calendar events directly by selecting a time period with their mouse. Previously, the system would always create 1-hour events instead of respecting the selected duration. This fix improves the calendar application's usability by allowing more precise event scheduling.
Original PR description
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause:…
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectange" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: --------- Thanks to the pointer, it is possible to know the original coordinates. We can use them with the following strong hypothesis: "If the origin coordinates along the Y axis are equal, a click is made." Note: ----- It is necessary to patch upstream when events are triggered. After that, we have to believe the information we receive and apply it. opw-3743945 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from accidentally canceling locked sales orders by hiding the cancel button until the order is unlocked. Users must now unlock an order before they can cancel it, improving data integrity and preventing unintended order cancellations.
Original PR description
You have to unlock the order before cancelling it. Introduced by 17bece3e797913bcba8dd7e07fc8541c0a45e3f7 Fixes #153987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr