Daily updates from Odoo
Monday, May 6, 2024
24 changes · 17.0
Enhancements to existing features
The analytic distribution feature now processes multiple requests together instead of one at a time, significantly reducing server load. This improvement prevents server overwhelm when viewing lists with many analytic entries, resulting in faster performance and better system stability.
Original PR description
The analytic distribution widget previously triggered one server request per line when it was used in a list view. Depending on the number of workers, this approach could quickly overwhelm a server. This commit introduces the `batchedOrm` service. This new service optimizes data retrieval by batching and caching requests for analytic account details, thereby reducing the load on the server and improving performance. opw-3867461 opw-3813783 opw-3892785 opw-3813783 opw-3894448
Resolved issues and error corrections
Fixed an issue where the Kitchen Display screen was not showing accurate quantities when the same product appeared multiple times in a restaurant order with different prices. The preparation lines are now created correctly to display all items that need to be prepared, ensuring kitchen staff have complete order information.
Original PR description
**Current behavior:**
POS preparation lines are currently created in a manner that is
liable to have incorrect quantity information when the same
product appears multiple times on a new order.
**Expected behavior:**
The preparation screen should display complete order data.
**Steps to reproduce:**
1. Install pos_restaurant with demo data
2. In the restaurant pos session, add some productA to the order
and modify its price with the keypad
3. Add the same product to the order so that the two order lines
do not merge (as their prices are different)
4. Confirm the order, go to the Kitchen Display, observe that
there is only 1 preparation line
**Cause of the issue:**
In `_process_preparation_changes()` when we end up with a line
that should have >1 quantity, this value is not correctly
evaluated.
**Fix:**
Iterate over the order lines to create preparation order lines
with accurate quantities.
opw-3857347This fix improves the bank account synchronization experience by displaying a clear error message to users when they attempt to connect a bank account that no longer has the required consent. Previously, users would not see an error in this scenario, which could cause confusion during the account connection process.
Original PR description
When a user selects an account, but on connecting it appears there is no consent anymore, we want to show the error to the user. task-3813628 Related to https://github.com/odoo/odoofin/pull/264 Forward-Port-Of: odoo/enterprise#60283
This update fixes a display issue in the Gantt chart view where the header slots were misaligned with the grid cells when users zoomed in. The fix restructures the header to use proper grid alignment, ensuring headers and grid cells stay perfectly aligned at all zoom levels.
Original PR description
When zooming in on the gantt view, the gantt header slots could be badly displayed with an observed decalage with the grid cells. We fix that problem by making the gantt header be a grid and putting grid coordinates to some of its children. opw-3850750 Forward-Port-Of: odoo/enterprise#61849
A bug in the Peruvian cash report query was causing data to appear in unpredictable order. This fix ensures the report consistently displays transactions sorted by journal, date, and transaction ID, making the reports reliable and reproducible.
Original PR description
The query defined `_l10n_pe_get_txt_11_data` does not define an order. It can result in an undeterministic order. We define it based on the date then id. Linked to runbot error 63997 Forward-Port-Of: odoo/enterprise#61867
This fix restores the ability to view receipt attachments when clicking on an expense line within an expense sheet. A recent change had caused duplicate attachments to be created, breaking the link between expense lines and their receipts. The fix uses a more reliable method to match receipts, ensuring users can properly access and view all attached documents for each expense.
Original PR description
In an expense sheet, when an expense line is clicked on, its receipts are shown in the attachment viewer. This was broken in odoo/pull/142029 since it duplicates the attachments from the expense, leaving inconsistency between the attachment ID of the lines and the ones in the sheet. To fix this, the checksum is used instead to find which attachment in the sheet corresponds to the one in the line that was clicked on. task-3758922
This fix resolves issues where images with hover animations weren't being saved correctly when their animation effects were modified. When users changed hover effect settings (like animation type, color, or intensity) and saved, the changes weren't being preserved and the image would revert to raw data. The fix ensures that modified images are properly tracked and saved as new attachments in the system.
Original PR description
[FIX] web_editor, *: create attachment on hover effect modification *: website Steps to reproduce: - Add an image on the website. - Add an "On Hover" animation. - Save and edit. - Change the…
[FIX] web_editor, *: create attachment on hover effect modification *: website Steps to reproduce: - Add an image on the website. - Add an "On Hover" animation. - Save and edit. - Change the animation effect (i.e. from "Overlay" to "Outline"). - Save. -> Problem: although the image options have been modified, there is no new attachment created for this modified image and its src is still the raw data. The problem appears since [1] as the `_reapplyCurrentShape()` method replaces `_applyOptions()`. Due to this, the `o_modified_image_to_save` class is not added anymore on the image when changing hover effect options such as "effect", "color", "intensity", and "stroke width". To solve the problem, the class is added back on the image when changing such options. Thanks to it, the system creates a new attachment linked to the modified image at the editor save. [1]: https://github.com/odoo/odoo/commit/5d83672e0aac40d3484ee45f348dfca5de8f186a task-3820127 -------------------------------------------------------------------------------------------------------------------------------------------------------------- [FIX] website: reapply original source on hovered image in edit mode Steps to reproduce the bug: - Add an image on the website and add an animation of type "On Hover" on it. - Save and edit. - Click on the image to load its options. - Save. -> Problem, the image src is the raw data. When the user clicks on the image, the `ImageHandlerOption` snippet option is started. Because the image has an hover effect, the `_refreshPublicWidgets()` method is called. Due to it, the `ImageShapeHoverEffet` public widget is restarted. The problem is that because the src of the image has been modified in the `_applyOptions()` method of the `ImageHandlerOption`, the src of the image will not be replaced by the original one at the `destroy()` of the `ImageShapeHoverEffet` public widget. At the re start of this public widget, `this.originalImgSrc` will be set to a base 64 source. At the save of the editor, the public widget is destroyed and the image source is set to those raw data. Because the image has not been modified, it keeps it as a src after the save of the editor. To solve the problem, the `destroy()` method of the `ImageShapeHoverEffet` has been adapted to correctly set the source of the image when it has not been modified. To do so, the `originalSrcBeforeHover` attribute is used to keep track of the original image src. It is needed for example if a user applies a filter on the animated image and then clicks on 'undo'; at the filter application, `ImageShapeHoverEffet` is destroyed. Because the image has been modified, the src of the image will not be replaced by the original one. Without the `originalSrcBeforeHover` attribute, the original src would be lost and it would not be possible to reset the src to the original if the user clicks on 'undo' and then save. task-3820127
This update improves the Razorpay payment token flow by eliminating unnecessary API calls and order creation when customers pay using a saved payment token. Previously, the system was performing redundant operations designed only for new payments, which has now been fixed to streamline the token payment process.
Original PR description
### [FIX] payment_razorpay: fix proccessing data in token flow Steps: - Install razorpay and sales app. - Enable Razorpay provider. - Create a create a token in razorpay. - Pay via that token. Issue: - When we are paying via token we really don't need processing values because those processing values only needed when we open Razorpay form so here it is calling APIs(customer and order) and creating order unwantedly. Fix: - Return empty dict when operation is `online_token` in `_get_specific_processing_values` method IMP/REV of PR: https://github.com/odoo/odoo/pull/157533 task-3653372
This update improves the Point of Sale system to display a helpful error message when users try to select a cashier but no employees exist in the database. Previously, the system would do nothing, which could confuse users. Now users receive clear feedback about what's wrong and why they can't proceed.
Original PR description
Prior to this commit, enabling the multi-employee option without any employees in the database would result in no action upon selecting cashier. This could lead to confusion. With this commit, an error message is displayed in such scenarios, enhancing user feedback and preventing confusion. opw-3851823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the system from creating duplicate contact records when an existing contact applies for a job position. Previously, when a contact applied for a job, the system would create a new contact entry even if that person already existed in the system, resulting in duplicate records. This update ensures that existing contacts are properly recognized and reused during the application process.
Original PR description
Current behavior: --- When applying for a job offer, if the partner already exists, it will create a new one anyway. Steps to reproduce: --- 1. install website_hr_recruitment,contacts 2. Go to contacts => only one admin partner 3. Go to Recruitment, select a job offer 4. Click on Job Page, Apply Now! 5. The form should be prefilled with admin info 6. Add missing information (LinkedIn and resume) 7. Click on I'm feeling lucky 8. Go to contacts => two admin partners Cause of the issue: --- Introduced by: https://github.com/odoo/odoo/commit/7774822c0ba9edf979cdc741a6c465a8e84e4da6 When creating an applicant, partner_id is False opw-3837388 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where vendor discounts were not being applied when automatically generating purchase orders for subcontracted services from sales orders. Now when a service is marked for subcontracting, any negotiated vendor discounts will correctly appear on the generated purchase order line items.
Original PR description
Problem --- When an RFQ order-line is auto-generated from a sale order for a subcontracted service, the discount from `supplierinfo` does not get applied. Steps --- * install `sale_management` and `purchase` * create a service product, and in the purchase tab set a vendor for it * set a discount for this vendor (still in purchase tab; unhide the column) * create a sale order for this product and confirm it * click the `purchase` stat button * On the generated RFQ line, the discount is not applied opw-3829675 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where miscellaneous operations were incorrectly displayed on the Accounting Dashboard for bank journals using foreign currencies. When a customer payment was created and confirmed in a foreign currency journal, the dashboard would show misc operations values that shouldn't have appeared, which has now been resolved.
Original PR description
Steps: - Create a Bank journal with foreign currency - Set the `default_account_id` as `payment_account_id` of the first `inbound_payment_method_line_ids` - Create and confirm a customer payment for this journal - Go to Accounting Dashboard -> On the journal card, the misc operations value is displayed although it shouldn't be opw-3869330
The website steps snippet has been updated to support images in addition to icons. Previously, after a refactoring that added SVG connectors, the snippet only worked with icons. Now users can use images with the same styling applied, giving them more flexibility in designing process steps on their website.
Original PR description
Ever since the refactoring of the steps snippet with SVG connectors (see [commit 1]), it only works with icons. Since its behavior is quite rigid (it forces a single height/width on the icons), we simply apply the same styles to images. [commit 1]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4 opw-3863703 Forward-Port-Of: odoo/odoo#163472
Users with access to only one company were unable to select company-specific products when creating quotation templates because the company field wasn't set by default. This fix automatically sets the current company as the default when creating new quotation templates, allowing users to properly select and use their company's products.
Original PR description
Steps: - Install sales app. - Login with user who has single company access. - Create a product and set company on it. - Go to template menu and click on new button - Click on product field in Lines page. Issue: - There is no way user able to select that product in quotation template. Cause: - Company field only visible to multi-company group and we don't set company default on template so user will only able to select products with out company and there is no way user can select company in template. Fix: - Set current company as default company on newly created quotation templates. opw-3853815
This fix corrects how payment transaction status alerts are displayed when using non-English languages like French. Previously, successful payments were showing incorrect visual indicators (no background color and a warning icon instead of a checkmark). The fix ensures that status styling is applied correctly regardless of the language setting.
Original PR description
In payment status template, do not translate `alert_type` otherwise the wrong class and icon will be shown For ex. in french, in case of a successful payment we were showing no background color and a warning icon instead of a check mark. [OPW-3900040](https://www.odoo.com/web#id=3900040&model=project.task&view_type=form&menu_id=) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163958
This fix ensures that sale warning messages and product blocking restrictions are properly displayed when salespeople use the product grid/matrix configurator. Previously, warnings only appeared at the end of the configuration process. Now warnings are loaded upfront, allowing salespeople to see restrictions immediately and preventing them from configuring products that shouldn't be sold.
Original PR description
Warning messages are displayed (and blocking products removed) on the end of the product configurator flow, but were not displayed (and blocking products were not removed) if the grid/matrix was used. This commit makes sure the warning information is loaded before the configurator opening. That way, the warning can be shown early in the flow to the salesman, and the product is directly blocked if it shouldn't be sold anymore. opw-3894805
This update fixes a system crash that occurred when users created vendor bills with products having a quantity of 0. The issue was caused by a mathematical calculation that attempted to divide by zero. With this fix, users can now successfully create and confirm bills with zero-quantity items without encountering errors.
Original PR description
Problem:
The error occurs when the user creates a bill with a product quantity of 0
Steps to reproduce:
- Install "Accounting", "Inventory", "Purchase" and "Sales" apps
- Navigate to Sales > Products > Products and create a new product
- Configure the product to be storable
- Navigate to the "Purchase" tab and set the control policy to "On ordered quantities"
- Navigate back to the "General Information" tab and create a new product category for this product
- Set the "Inventory Valuation" to "Automated"
- Set the "Price Difference Account"
- Navigate to Accounting > Vendors > Bills
- Create a new vendor bill and add the lately created product with a quantity of 0
- Confirm the bill
Cause:
The quantity of the product is 0 and is the denominator of a fraction
opw-3806378
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163246
Forward-Port-Of: odoo/odoo#161825This fix resolves a technical error that occurred when customers tried to download invoices for orders paid with online payment methods. The issue prevented the invoice from being properly generated and downloaded after payment, which has now been corrected to ensure a smooth checkout experience.
Original PR description
This commit fixes the issue where a traceback is shown when an order will be invoiced after paying with an online payment. Steps to reproduce: - Setup online payment and link to the pos.config. - Open a session. - Create an order that will be invoiced and pay with the online payment method. - Traceback during the download of the invoice.
This update prevents duplicate image files from being created when users select the same image multiple times from the media library or Unsplash. Previously, clicking the same image repeatedly would create multiple copies of the file. Now the system recognizes when an image already exists and reuses it instead of creating duplicates, keeping your media library clean and organized.
Original PR description
[Commit 1] made sure uploaded media are not duplicated if they already exist. The media library and Unsplash were not taken into account. This commit makes sure only one attachment is created for…
[Commit 1] made sure uploaded media are not duplicated if they already exist. The media library and Unsplash were not taken into account. This commit makes sure only one attachment is created for each image fetched from the media library or Unsplash, and adds a test. Note: the test is marked 'external' as it calls the Undraw API (twice: once to search the images, a second time to save the selected image as an attachment). The 2nd call cannot be mocked, as it would not test the fix within `save_library_media()` which makes sure the same image is not saved twice. Steps to reproduce: - Open the media dialog on an image - Make a dummy search to show the media library images - Quickly click multiple times on the same image - Reopen the media dialog => The image is saved multiple times. Note: it is also uploaded multiple times if you reopen the dialog and reselect the same image. [Commit 1]: https://github.com/odoo/odoo/commit/1990f2209d6f89e91618896cd6bbae50d0228369 task-3798504 Forward-Port-Of: odoo/odoo#164068 Forward-Port-Of: odoo/odoo#162597
German companies without a VAT ID can now use their Tax Identification Number (TIN) as their VAT ID in Odoo. Previously, the system rejected TIN numbers when entered in the VAT ID field. This fix adds specific validation logic for German tax numbers, allowing companies to properly register their tax information for VAT declarations.
Original PR description
## Issue: - In Germany companies that don't have a VAT ID, make their VAT declarations based on their Tax Identification Number (TIN). However, when the Tax Identification Number is entered as a VAT…
## Issue: - In Germany companies that don't have a VAT ID, make their VAT declarations based on their Tax Identification Number (TIN). However, when the Tax Identification Number is entered as a VAT ID, it is not accepted by Odoo. ## Steps To Reproduce: - Go to a fiscal position - Add a new fiscal position with germany in country and '133/8150/8159' in the Foreign VAT ID field. - Odoo expects another format. ## Solution: - The process begins with the addition of `vat`, which triggers the `check_vat` method. - This method, in turn, calls `_run_vat_test`, wherein `check_func` is set to `self.simple_vat_check`, indicating the default validation function. - The `simple_vat_check` performs the VAT validation. It proceeds with standard validation if no specific `check_func` is defined for the given `check_func_name`. - For Germany, I implemented `check_func_de`, to specifically check and validate German VAT numbers when a TIN is provided. opw-3792306 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163571 Forward-Port-Of: odoo/odoo#159690
This fix resolves an issue that occurs when the accounting system renames taxes multiple times during upgrades. Previously, the system would fail with a naming conflict error. The solution now properly tracks existing tax names to avoid duplicate names, ensuring smooth upgrades without interruption.
Original PR description
If we rename the tax to '[old] taxname' everytime we detect a modification then we will run into a unique name violation. Taking account of how many other taxes with the same name there already are will bypass this constraint. The problem appears during upgrades --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164025
A coding error in the leave accrual system was causing incorrect calculations when processing employee leave allocations. This fix corrects a typo that was using the wrong data reference in the processing loop, ensuring leave accruals are calculated accurately for all employees.
Original PR description
In the refactoring of hr_holidays in odoo@cf33b80aca81, there was a typo in the loop, with the recordset self instead of the record allocation. Fixes #164259
This fix resolves a problem where the Analytic module failed to install properly when certain system defaults were configured. The issue occurred when default settings forced fields to not be stored in the database, preventing the analytic plan field from being created correctly. This fix ensures the plan field is properly stored regardless of those default settings.
Original PR description
In case there is an entry in ir_defaults that forces `store=False` Steps to reproduce: add such default and try to install analytic. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix enables businesses in outlying territories (such as island nations and overseas regions) to use Stripe payment processing. Previously, these territories couldn't set up Stripe Connect accounts or use express checkout because Stripe requires them to register using their parent territory. Odoo now automatically handles this mapping, allowing more businesses worldwide to accept Stripe payments.
Original PR description
Before this commit, outlying territories supported by Stripe couldn't create an account using Stripe Connect nor use express checkout. The problem is that Stripe asks outlying territories to configure their account using their parent territory as a Country. Now, Odoo will automatically use the parent territory for outlying territories supported by Stripe, enabling Stripe Connect and Express Checkout for them. opw-3867753 opw-3865198 Forward-Port-Of: odoo/odoo#164427 Forward-Port-Of: odoo/odoo#164229