Daily updates from Odoo
Monday, May 6, 2024
29 changes · 17.0
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
This update adjusts automated tests in the Project Sales Subscription module to align with recent changes made in the community version. The test modifications ensure that quality checks continue to pass and the module functions correctly with the latest codebase updates.
Original PR description
This commit adapt test case according to changes in community branch. opw-3853815
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
This fix resolves an accounting error that occurs when returning products purchased at different prices using FIFO inventory valuation. Previously, returned items could create unreconciled accounting entries with significant value discrepancies. The fix ensures proper compensation of stock accounts when product return values differ from original receipt values, maintaining accurate financial records.
Original PR description
The value of the returned product may be different from the one initially received. In such case, the stock accounting may be broken. To reproduce the issue: (Need account_accountant) 1. Create an…
The value of the returned product may be different from the one initially received. In such case, the stock accounting may be broken. To reproduce the issue: (Need account_accountant) 1. Create an auto-FIFO product category 2. Create a storable product 3. Confirm a PO with 1 @ 10 4. Receive it 5. Confirm a PO with 4 @ 25 6. Receive 1 with backorder 7. Return it 8. On the backorder, receive 4 9. Bill Error: Looking at the AML of the stock-in account, some lines are not reconciled and there is a $15 difference between the totald debit and the total credit. Step 7, when returning the product, we actually return the one at $10. Step 8, we then receive 4 products at $25 (hence the difference of $15). So, back to step 7, when returning the product, we should also compensate the stock-in account (with the expense one) in case of a difference. Let's look at another case: after step 7, the user "returns the return". In such case, the value of the new receipt is based on the returned one (see [1]), i.e.: the value of the newly received product will be $10. In such case, we also need to (1) compensate the stock-in account and (2) prevent the pdiff process to generate a pdiff of $15 (otherwise, we would add a value to the received product, which would go against the logic of [1]). This commit does not address the behaviour difference between the two above use cases (-> depending on how the user receives again the returned product, its value is not the same). This would probably need a deeper analysis a change, on master. Note: a third use case does not work either: (step 1-4), PO 1 @ 25, receive, bill, return, refund. [1] https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40 Initially added by https://github.com/odoo/odoo/commit/200aac56771fd1ef759f73b277a6808d96ee5f31 OWP-3698324 Forward-Port-Of: odoo/odoo#162368
This update fixes incorrect Vietnamese translations in the website and HR recruitment modules. The corrections ensure that users in Vietnam see accurate and proper translations of key terms and phrases throughout these applications.
Original PR description
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
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
A recent change to how invoice attachments are processed was causing previously uploaded files to be removed when new files were added to a draft invoice. This created access errors for other users trying to view the original files. This fix ensures that new attachments are added without removing existing ones, preserving all uploaded documents and their accessibility.
Original PR description
PR #140196 modified the extension mechanism when processing files accompanying an invoice, in order to focus on a single relevant file per invoice. Unfortunately this change can break the upload of…
PR #140196 modified the extension mechanism when processing files accompanying an invoice, in order to focus on a single relevant file per invoice. Unfortunately this change can break the upload of subsequent files on a new invoice, causing access errors. Typical scenario: - use the Upload Bill feature to create a new vendor bill from a PDF file -> a new draft bill is created, with no lines initially, and with the invoice PDF attached to the new bill. - before adding any lines, and before any automatic extraction process is able to parse the PDF and add lines, use "Log a note" on the draft bill to attach an image - result: the second file (the image) is processed by `_message_post_after_hook` and ends up being added as an attachment on the draft bill. However the first file (the invoice PDF) is now detached from the invoice, and the attachment counter is back to 1. If another non-admin accountant user tries to open the invoice PDF it will fail with an access error, because the file is detached and can only be accessed by the original uploader (or an admin). Fix: instead of replacing all attachments on the invoice, `_message_post_after_hook` should add the new one without discarding the existing ones.
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 an issue where recurring events in Google Calendar would disappear when updating them in "This and future events" mode. The problem occurred because attendees were being removed during updates, causing events to vanish from the calendar. The fix preserves the event organizer as an attendee when syncing updates from Google, ensuring recurring events remain visible and properly maintained.
Original PR description
Before this fix, when updating recurrence events in "This and future events" mode, some events vanished. This happened because we were removing all the attendees from the occurrences, and then no event was being shown in the calendar. Additionally, when creating recurrences from Google with the "UNTIL" option, one extra event was being added at the end because the rrule on their side finished on the next day after the end at 23:59:59. After this fix, we no longer delete all attendees when receiving updates from Google. Instead, we update the current attendees for not recreating all of them every time. Thus, when updating recurrent events, they no longer vanished anymore. Creating recurrent events in Google with the "UNTIL" option also no longer adds an extra day at the end because we are subtracting the extra day. Task-id: 3731542 Forward-Port-Of: odoo/odoo#156077
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 resolves a critical issue where generating reports for multiple invoices would fail when some invoices had previously saved reports and others didn't, with the "Reload from attachment" option enabled. The problem was caused by incorrect indexing when combining newly generated reports with cached ones. This fix ensures reports are properly generated and combined for all selected invoices regardless of their attachment status.
Original PR description
Issue ----- Report creation for multiple invoices fails (e.g. with <AttributeError: "NoneType" object has no attribute "getvalue">) when some, but not all, of the invoices across the selection have a…
Issue ----- Report creation for multiple invoices fails (e.g. with <AttributeError: "NoneType" object has no attribute "getvalue">) when some, but not all, of the invoices across the selection have a previously generated report as an attachment, and the 'Reload from attachment' option is enabled for the report action. Steps ----- - Enable 'Reload from attachment' from Settings -> Techical -> Actions -> Reports -> invoices. - Create 3 invoices without any previous reports as attachments. - Select the middle invoice and generate a report (Print -> Invoices). An attachment will be created for the invoice. - Select the 3 invoices then generate a report (Print -> Invoices). Cause ----- When "Reload from attachment" is enabled, the algorithm for creating aggregate reports for a number of invoices selects only those that don't have an attachment to generate a pdf for. These are copied into a separate list "res_ids_wo_stream". When the pdfs streams are generated, they're put back into the return value "collected_streams. However, this was done from the original ids list "res_ids" rather than the selected one, which resulted in an indexing issue. opw-3827700 Closes #157975 Forward-Port-Of: odoo/odoo#164420 Forward-Port-Of: odoo/odoo#160670
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