Tuesday, July 9, 2024
24 changes · 17.0
Enhancements to existing features
This change separates the checks that prevent certain accounting entries from being reset to draft, making it easier for custom workflows to bypass those checks when appropriate. It supports audit-related processes where cash basis or exchange difference entries may need to be deleted without creating excessive reversal lines.
Original PR description
The restrictions on `button_draft` method on account move were moved to a new method to allow inherit and mute the restrictions in necessary cases for some customizations. A user case is the next: Allow the deletion of cash basis or Exchange Differential entries to facilitate the accounting audit process. As the number of lines in the accounting entries generated by these transactions can grow significantly, this occurs each time a payment that has generated CABA or Exchange Differential entries is canceled or unreconciled, reverse lines are generated for these entries. Setting the posted journal entries to "draft" when canceling by using the `button_cancel` method was introduced in [1], this does not allow deleting the CABA or Exchange Differential entries generated in the unreconciled and reconcile process. [1] 1de5c98 Related: #96134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes a problem that could prevent the Argentina withholding module from being installed again after removal. Businesses using this localization can now reinstall the module without running into a tax setup validation error.
Original PR description
Uninstall l10n_ar_withholding Install again l10n_ar_withholding Issue: Reinstall will fail with error odoo.exceptions.ValidationError: Invoice and credit note distribution should each contain exactly one line for the base. This occurs because the system attempt to create a tax repartition line in existing tax instead of updating the data opw-3946193
Miscellaneous changes
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the issue: The list comprehension done here --> https://github.com/odoo/odoo/blob/27ff3e0f64f53caa62c3022bd3b7c41e29a8e721/addons/pos_loyalty/models/loyalty_program.py#L59 The complexity is `O(len(self) * ((len(read_group_res) * len(program_reward_ids)) + len(read_group_res<sum method>)))` which pe
Original PR description
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the…
Current Behavior: Computation of the field `pos_order_count` on model `loyalty.program` is slow when there is a large number of `pos.order.line` records with `reward_id` set on them. Cause of the issue: The list comprehension done here --> https://github.com/odoo/odoo/blob/27ff3e0f64f53caa62c3022bd3b7c41e29a8e721/addons/pos_loyalty/models/loyalty_program.py#L59 The complexity is `O(len(self) * ((len(read_group_res) * len(program_reward_ids)) + len(read_group_res<sum method>)))` which performs slowly if the `self` and `read_group_res` are large. Improvement: Delegate the computation to Postgres and assign the values obtained from the result. Benchmark: In method `_compute_pos_order_count` Number of `pos.order.line` records eligible in computation --> 17803 Where `self` is a a `loyalty.program` recordset len(self)| Before (in seconds) | After PR (in seconds) | |---------|--------|--------| |1000| 177.28 s | 6.43 s | |212| 29.73 s| 0.5 s | Improvement by about 98% on average opw-3903159 Forward-Port-Of: odoo/odoo#167386
The loyalty test flow was adjusted so automated checks run in a more consistent order. This helps reduce false failures in validation systems, making releases more dependable without changing the customer-facing loyalty features.
Original PR description
Steps order in the tests was causing an underterministic behavior when the test was run on the runbot. We change the order of the steps to try to make the test more deterministic and consistent. Runbot Error: 57047
Creating a new Discuss channel now keeps the exact capitalization and accents entered by the user. This prevents names from being unintentionally changed, making channels clearer and more respectful of users' language and naming choices.
Original PR description
Before this commit, when creating a channel from the discuss sidebar, the name of the channel would be transformed to lower case and stripped of accents. This happens because the same cleaned term used for searching gets used to define the name of the new channel. This commit fixes the issue by using the unaltered search term. Before:  After: 
This change adjusts when the Turkish localization migration runs during package upgrades. It helps prevent upgrade failures caused by a missing asset-related value, making the upgrade process more reliable for affected users.
Original PR description
[FIX] l10n_tr: Fix migration script's execution phase This is a follow up to https://github.com/odoo/odoo/pull/167258 When we trigger the upgrade button of the package, We get an error that 'create_asset' field is null even that field has a default value The issue is not specified yet, Reaching the upgrade team to get their input changing the phase from 'post-' to 'end-' task-id#3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Paid orders in Point of Sale can now be found when users search using the date format configured on their system. This makes order lookup more reliable and avoids confusion for staff working with localized date formats.
Original PR description
Before this commit, searching for paid orders using the system's date format was not possible due to the lack of proper date parsing and formatting in the search fields. opw-4008489 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point-of-sale loyalty flow now avoids errors when a reward product has been archived. This keeps checkout and reward handling stable even when older or inactive products remain linked to loyalty rewards.
Original PR description
This commit adds a check to prevent errors when a reward product is archived. opw-4012282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The event registration page now lets the Add to Calendar button follow the site's configured secondary button style. This keeps event pages visually consistent when a business customizes its website theme.
Original PR description
## Issue: Due to having 'text-bg-secondary' in our Add to Calendar button, if we modify the secondary button style for the website theme, the new style for the secondary button will not be applied properly even though it's a secondary button. ## Steps to reproduce: 1. Install website_event. 2. Modify the secondary button style for the theme (i.e set it to outline) 3. Check the button inside events > register an event. ## Solution: We could get rid of the class 'text-bg-secondary' for this button which will make the button to keep same style and still be "responsive" to theme changes. opw-3869252
This fixes an issue where deleting accounting entries with attachments could fail for companies not using German localization. It also makes batch deletion handling more efficient when several related messages are removed at once.
Original PR description
Since unlinking `ir.attachment` is done after removing the record from the database, and the cache is already invalidated, we cannot browse `res_id` anymore. Also improve the prefetching for all messages being unlinked at the same time if related to different moves.
This fix makes Odoo report the actual invalid field name when a grouped read request contains a field that does not exist. It helps users and support teams diagnose configuration or reporting mistakes faster by avoiding misleading error messages.
Original PR description
When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error in point-of-sale Viva Wallet payments when failed transaction notifications do not include expected reference data. Instead of crashing while processing the notification, the system now detects the missing information and raises a controlled error so staff can be notified appropriately.
Original PR description
An error occurs when the system tries to retrieve 'session_id' at [1] from 'MerchantTrns' but it is not available. Because of failed transactions (Ref: https://developer.viva.com/webhooks-for-payments/transaction-failed/#response-example) link [1]: https://github.com/odoo/odoo/blob/319cf81da8f16df21900f26bd6d8b4fc686e72eb/addons/pos_viva_wallet/models/pos_payment_method.py#L113 To resolve this issue, add a condition to check if 'MerchantTrns' is not available in 'data_webhook' then raise an error as send notification. Sentry - 5466498742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product badges or ribbons in the online shop now keep the background color selected by website editors. This ensures promotional labels display as intended, improving product presentation and reducing editing frustration.
Original PR description
Steps to reproduce: - Go to Shop page on website - Enable edit mode - Pick a product and create a new Badge/Ribbon - Change the background color - Bug -> the bg-color is not set. Issue : ribbon bg-color is not set on the product. Cause : The !important attribute has been duplicated in the CSS rule since [1] and [2]. As a result, the background colour CSS rule for the ribbon is broken due to having !important twice. [1]: https://github.com/odoo/odoo/commit/c6f4929f65b899736c556f8f0bb7824883a6d893 [2]: https://github.com/odoo/odoo/commit/9ee115b58342b3e0dbc11081e7ff752c10f8bfa9 fix : After removing the '!important' attribute from the create and write methods, we only encounter the '!important' attribute once. As a result, the ribbon background color is applied to the product. opw-3964071
Updated the accounting module's test procedures to comply with German audit trail requirements, which mandate that financial moves cannot be deleted. The fix ensures that only moves associated with the specific test company are removed during testing, while preserving the audit trail integrity required by law.
Original PR description
Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related. We only need to remove the moves linked to the company of the tour.
Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164077 Forward-Port-Of: odoo/odoo#151611
Original PR description
Fix of the COA: There was a bad assignation in the account rate difference profit/loss. As these are minor changes, we make this together with changes in the F29 report VAT base https://github.com/odoo/enterprise/pull/55365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164077 Forward-Port-Of: odoo/odoo#151611
Before this commit, the error service attempted to adapt the `error.stack` format to match the one used by Chrome. But even then, the error_service_tests (that compare exactly the traceback) didn't pass on Firefox. Since version 125, even Chrome itself doesn't pass that test. This commit adapts the stack formatting code to ensure the actual error name is present and its message, but without trying to match a (too) specific format. Also in this commit, the related tests are adapte
Original PR description
Before this commit, the error service attempted to adapt the `error.stack` format to match the one used by Chrome. But even then, the error_service_tests (that compare exactly the traceback) didn't pass on Firefox. Since version 125, even Chrome itself doesn't pass that test. This commit adapts the stack formatting code to ensure the actual error name is present and its message, but without trying to match a (too) specific format. Also in this commit, the related tests are adapted to be a little less strict (and more resilient), but stil ensuring the actual error name and message are present. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172330 Forward-Port-Of: odoo/odoo#172230
This commit optimizes the `_accumulate_amounts` method. Previously, when there were many stock moves per PoS order, the '_compute_average_price' would be called for each move, resulting in multiple identical queries for each valuation layer in each stock move. Now, the stock moves and valuation layers for an order are prefetched at once, significantly reducing the number of database queries. This results in a performance improvement, especially when processing a large number of PoS orders and
Original PR description
This commit optimizes the `_accumulate_amounts` method. Previously, when there were many stock moves per PoS order, the '_compute_average_price' would be called for each move, resulting in multiple identical queries for each valuation layer in each stock move. Now, the stock moves and valuation layers for an order are prefetched at once, significantly reducing the number of database queries. This results in a performance improvement, especially when processing a large number of PoS orders and stock moves. | Scenario | Before Optimization (seconds) | After Optimization (seconds) | |----------|------------------------------|-----------------------------| | 100 orders, 1,000 stock moves | 20 | 5 | | 300 orders, 100,000 stock moves | 617 | 23 | opw-3980597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168963
**Steps to reproduce the bug:** - Create a storable product P1. - Create two purchase agreement with the same product and qty=10 - Create and confirm a PO with only the second PO - Try to export both purchase agreements, selecting the one without a PO first and then the other. For the fields to export, choose: Products to purchase/ordered quantities. **Problem**: Sure, here is the corrected version in English: Both lines will show 0 units. When the `_compute_ordered_qty` is call
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1. - Create two purchase agreement with the same product and qty=10 - Create and confirm a PO with only the second PO - Try to export both…
**Steps to reproduce the bug:** - Create a storable product P1. - Create two purchase agreement with the same product and qty=10 - Create and confirm a PO with only the second PO - Try to export both purchase agreements, selecting the one without a PO first and then the other. For the fields to export, choose: Products to purchase/ordered quantities. **Problem**: Sure, here is the corrected version in English: Both lines will show 0 units. When the `_compute_ordered_qty` is called with the first PO requisition line, no purchase order is linked, and therefore the total quantity remains at 0. However, the product is added as a founded line. So, on the second requisition line, even though the total quantity (10) is correctly calculated because a PO is linked, the condition that checks if the product has already been found will be true, and therefore the quantity will be set to 0. https://github.com/odoo/odoo/blob/e7850da5848993e036ab70b731f37005ccd64604/addons/purchase_requisition/models/purchase_requisition.py#L240-L244 opw-[4005265](https://www.odoo.com/web#id=4005265&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#171972 Forward-Port-Of: odoo/odoo#171809
Fiscal position using 2 taxes including in price are not working in PoS. If you use the fiscal position only the tax should change, not the total price, as both tax are included in price. Steps to reproduce: ------------------- * Create two taxes that are included in price * Create a fiscal position matching those 2 taxes * Create a product using the first tax * Open PoS session, and add the product to the order * Price should be for example 100€ * Now change the fiscal position to the
Original PR description
Fiscal position using 2 taxes including in price are not working in PoS. If you use the fiscal position only the tax should change, not the total price, as both tax are included in price. Steps to…
Fiscal position using 2 taxes including in price are not working in PoS. If you use the fiscal position only the tax should change, not the total price, as both tax are included in price. Steps to reproduce: ------------------- * Create two taxes that are included in price * Create a fiscal position matching those 2 taxes * Create a product using the first tax * Open PoS session, and add the product to the order * Price should be for example 100€ * Now change the fiscal position to the one you created > Observation: Price of the product changed when it shouldn't have Why the fix: ------------ When computing the price of the product with a fiscal position, if the previous tax is included in price and the new one is also included in price, the price of the product shouldn't change. So instead of recomputing the price of the product with the new tax based on the previous tax excluded price. We just use the price of the product opw-3952604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169223
Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270
Original PR description
Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270
**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add any storable product - Delivery date: Tomorrow - Confirm the PO - Go to the Scheduled Actions: Purchase reminder - Run it Manually - Come back to the Dashbord > Emails - Select the email for Azure interior: - Try to click on “YES” **Problem:** A tra
Original PR description
**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add…
**Steps to reproduce the bug:**
- Go to contact and select azure interior:
- Sales & purchase tab:
- Enable “Receipt Reminder” 1 day
- Create a purchase order:
- Select azure interior as vendor
- add any storable product
- Delivery date: Tomorrow
- Confirm the PO
- Go to the Scheduled Actions: Purchase reminder
- Run it Manually
- Come back to the Dashbord > Emails
- Select the email for Azure interior:
- Try to click on “YES”
**Problem:**
A traceback is triggered: `AttributeError: type object 'datetime.datetime' has no attribute 'from_string'`
When the “YES” button is clicked, we retrieve the “confirmed_date” from the arguments as a string and then call the `confirm_reminder_mail` function https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase/controllers/portal.py#L117
This date will be localized to the PO timezone using the `get_localized_date_planned` function: https://github.com/odoo/odoo/blob/a0be5ea52aeff3520f8f1a92206a5aad38fdaa82/addons/purchase/models/purchase.py#L823
We then get the timezone and use the `astimezone` function to transform this date, but since it is in string format, an error is triggered.
opw-4028362
Forward-Port-Of: odoo/odoo#172267Create an analytic plan [TEST] with default optional availability Add an applicability line with: - Domain: Expense - Product Category: [CATEG] - Applicability: Mandatory Create an expense with an expense product having categoy [CATEG] Create Report, submit and approve Issue: No message is raised, the action should have been blocked by the mandatory applicability opw-3955683 Forward-Port-Of: odoo/odoo#168312
Original PR description
Create an analytic plan [TEST] with default optional availability Add an applicability line with: - Domain: Expense - Product Category: [CATEG] - Applicability: Mandatory Create an expense with an expense product having categoy [CATEG] Create Report, submit and approve Issue: No message is raised, the action should have been blocked by the mandatory applicability opw-3955683 Forward-Port-Of: odoo/odoo#168312
A customer has been facing a lot of out of memory issues when using the field service app. A deeper investigation has correlated the problem with the Gantt view. After inspecting the data, it has been found that the customer has developed the habit of including images in task description. Having these images embedded has resulted in project.task table using 5.4GB of space for only ~6700 tasks. The problem is, gantt view is not paginated and therefore would fetch the entire project.task table
Original PR description
A customer has been facing a lot of out of memory issues when using the field service app. A deeper investigation has correlated the problem with the Gantt view. After inspecting the data, it has…
A customer has been facing a lot of out of memory issues when using the field service app. A deeper investigation has correlated the problem with the Gantt view. After inspecting the data, it has been found that the customer has developed the habit of including images in task description. Having these images embedded has resulted in project.task table using 5.4GB of space for only ~6700 tasks. The problem is, gantt view is not paginated and therefore would fetch the entire project.task table to perform a group by user id. Since there are no fields specified, the prefetcher would end up loading all fields (including description) which suddenly bloats the cache beyond the memory limits. However, upon deeper inspection, prefetching all fields has been found to be useless at that step. The solution is to simply disable the prefetcher at that step. Benchmarks: For easier calculation, a debug point was placed before the end of the request to freeze the state of the worker memory. Then the total worker process memory consumption was recorded with `psutil.Process(pid).memory_info().rss`. Since this measurement is recorded before the transaction is finished, it accounts for the cache along with everything else. | peak total worker memory consumption before | peak total worker memory consumption after | | --------------------| -----------------| | > 2GB (worker crash) | 368 MB | opw-4005020 Forward-Port-Of: odoo/enterprise#66175
To reproduce the bug: 1. Upload a CSS template and add the multiline text item. 2. Sign the template and fill in the multiline text item. 3. Zoom in and out, checking if the font size gets updated. 4. Validate the document and repeat step 3. 5. Download the document to check it. While zooming in and out, both before and after validating the document, the text font size does not change, causing the general output to be messy. Additionally, when you download the document, it is downloaded
Original PR description
To reproduce the bug: 1. Upload a CSS template and add the multiline text item. 2. Sign the template and fill in the multiline text item. 3. Zoom in and out, checking if the font size gets updated. 4. Validate the document and repeat step 3. 5. Download the document to check it. While zooming in and out, both before and after validating the document, the text font size does not change, causing the general output to be messy. Additionally, when you download the document, it is downloaded with the zoom set at 100%. This means that if you filled the template at a zoom of 180%, it will be zoomed out, resulting in an excessively large relative font size for the page size. This issue is due to the font size class marked as `!important`, which overrides the changes made at the HTML element level. **opw-3839651** Forward-Port-Of: odoo/enterprise#66140