Monday, April 14, 2025
7 changes · master
Enhancements to existing features
Performance test coverage for the Documents app has been consolidated into the Documents module. This helps teams monitor efficiency in one place and catch slowdowns earlier without changing user-facing behavior.
Original PR description
Centralizing performance tests for documents in documents. To come: Other tests for bridges features implemented in documents should also be tested in documents. Task-4548076
This update removes unnecessary request details from the session information loaded by IoT and Studio. It helps keep startup data lighter and better aligned with the main Odoo platform change, with no expected change to normal user workflows.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/205725
This update adjusts Odoo Studio’s test setup so it works with a new caching service for actions and views. The change supports more reliable validation of Studio behavior as caching is introduced, with no direct impact on day-to-day users.
Social media communications for events with multiple time slots are now sent once for the overall event instead of once per slot. This prevents repetitive posts, keeps event promotion cleaner, and reduces unnecessary communication noise.
Miscellaneous changes
Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one. The issue was introduced in Odoo 18.0 with commit [1]. - Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price). - That product should be a service one - Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a vari
Original PR description
Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one. The issue was introduced in Odoo 18.0 with commit [1]. - Create…
Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one. The issue was introduced in Odoo 18.0 with commit [1]. - Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price). - That product should be a service one - Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a variant product that you set there, not a template. - You should see next to the variant product you just selected a price per booking being displayed. It is correctly showing the product variant price and not the product template price. - Repeat those 2 steps with the other product variants: create a new appointment and select another variant, you can see the price is correct in the form view. - Now, go to the website appointment page `/appointment`, you will see that all those appointments will show the same price which is the one from the first variant. - The same price error will appear once you click on an appointment (you should land on something like `/appointment/4?`) - Note that if you go further in the appointment booking and land on the shop cart page, the price will be correct there, using the correct variant one. (You'll need to assign a user on the appointment in the backend to be able to book a slot) Side note: Commit [1] seems to have broken commit [2] too. [1]: https://github.com/odoo/enterprise/commit/26fb20ace27b7b522a1105c221e4a52cf224a508#diff-5ffc6d13c61e692b22e4c2fec9218cf96c0c86201aeac951ef36e53e7baa7620R4-R9 [2]: https://github.com/odoo/enterprise/commit/5068b0ae7d38cb03318ad1e97124021121fd66cb opw-4678998 Forward-Port-Of: odoo/enterprise#83104
Description ----------- When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the `_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all paren
Original PR description
Description ----------- When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or…
Description ----------- When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the `_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all parent articles in the hierarchy, and only then applies grouping and filtering based on the `id` of `self`. This process includes a `LEFT OUTER JOIN` on related tables to fetch specific `fields` passed as arguments, resulting in an O(n^2) complexity on large tables such as `res.partner` and `knowledge.article.member` (the latter being a Many2many relationship that typically contains a high volume of rows). This patch improves performance by shifting the grouping and filtering logic to the start of the process, effectively injecting all preconditions at the base of the recursion. This reduces the hierarchy of articles and memberships to explore. Additionally, the computation of inherited permissions—sourced from the "closest" ancestor article—is now handled at the SQL level instead of Python. This eliminates unnecessary rows in the process, avoiding unnecessary work in the business logic afterward. Benchmark --------- On a client's database with around 600 articles, 5k partners and 15k knowledge.article.member in total, for a specific article which has a total of 1.7k members (direct and inherited): | Request | Before | After | Speed-up | |--------------------------------|---------|-------|-----------| | `_get_article_permission_data` | 4.7+min | 150ms | **1880x** | Reference --------- opw-4603551 Forward-Port-Of: odoo/enterprise#81264
Currently, an exception is generated when a user tries to save a product record without a barcode, whether it is a newly created record or an existing one. Steps to reproduce: 1. Install the Inventory module. 2. Go to Inventory settings. 3. Set Barcode Nomenclature to Default GS1 Nomenclature. 4. Go to Inventory -> Products, create a product with a barcode, and save it. 5. Edit the same product, remove the barcode, and save it again. 6. An error occurs. Error: `StopIteration` T
Original PR description
Currently, an exception is generated when a user tries to save a product record without a barcode, whether it is a newly created record or an existing one. Steps to reproduce: 1. Install the…
Currently, an exception is generated when a user tries to save a product record without a barcode, whether it is a newly created record or an existing one. Steps to reproduce: 1. Install the Inventory module. 2. Go to Inventory settings. 3. Set Barcode Nomenclature to Default GS1 Nomenclature. 4. Go to Inventory -> Products, create a product with a barcode, and save it. 5. Edit the same product, remove the barcode, and save it again. 6. An error occurs. Error: `StopIteration` This issue [1] occurs because when a user tries to save the record without a barcode, the value is false, and an false value is not iterable. [1] - https://github.com/odoo/odoo/blob/9eb6c16cd7d4fe9364d043e2af96876bf82a44d4/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L163 This fix resolves an issue where GS1 preprocessing was always applied when checking for duplicate product barcodes. By introducing the skip_preprocess_gs1 context flag, the GS1 preprocessing step is now bypassed when verifying barcode uniqueness. Related Community PR:- https://github.com/odoo/odoo/pull/196438 sentry-6267124218 Forward-Port-Of: odoo/enterprise#80544