Daily updates from Odoo
Navigate
Branch
Monday, May 6, 2024
51 changes
1 change
Resolved issues and error corrections
This update resolves intermittent issues where automated tours on the website's sales pages were failing to load correctly. The fix ensures that these tours consistently function, improving the user experience for potential customers browsing our online sales offerings. This change is a minor technical improvement.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
19 changes
Enhancements to existing features
WhatsApp configuration options are now shown under Discuss settings instead of Email settings. This makes the settings page clearer and helps users find WhatsApp-related options in the expected place.
Original PR description
### whatsapp Following the addition of the Email settings group, moves whatsapp settings to the Discuss settings group. task-3859594
Account reports now keep their fixed top-level sections in their original order when users sort report lines. This preserves the intended structure of official reports while still sorting the detailed content within each section.
Original PR description
For most reports (especially the official ones) it is not relevant to sort the fixed parts. That's why this commit excludes the hierarchy level 0 lines from sorting. This makes it so the structure of the report is preserved while sorting, but the content of each part does get sorted. task: 3645935
Invoice and subscription screens were simplified by moving rarely used Intrastat and subscription fields into debug mode, especially on mobile. Column widths were also adjusted to reduce empty space, making invoicing views easier to read and navigate.
Original PR description
*: account_accountant, account_intrastat, sale_subscription This commit aims at improving readability by moving some less used fields to the debug mode Community PR: https://github.com/odoo/odoo/pull/163014 task-3642419
The French FEC import now lets users add a prefix to imported journal entry names and decide whether matching records should be ignored or updated. This helps avoid clashes when importing accounting files by fiscal year, especially when entries in different years share the same name.
Original PR description
In order to handle clashes between imported records and DB records, the following import improvements were incorporated: 1. Added the option to accept a prefix added to moves names. 2. Added the option to give the user control over what should happen to such clashes (ignore or update). User import SAF-T/FEC by fiscal year for simplicity and also because too big file generate time out. We import and update the records by name, but records having the same name in different fiscal years cause import data clashing. Users should be able to differentiate between records imported in different fiscal years. task-3830049
The Knowledge welcome template now encourages users to try the checklist feature sooner by placing the checkbox example first. Wide tables inserted from the editor now automatically use the full article width on desktop, making larger tables easier to read.
Original PR description
### knowledge reorder checkbox elements in example welcome template This puts the checkbox element "Check to mark as done." first in the example list. This calls the user to early action on their part (to try it out for themselves). increase article width on insertion of a large table On computers (or any device capable of seeing the TablePicker), tables inserted with the /table command now trigger full article width if they have at least 5 columns. Note that this cannot happen with tables inserted on mobile devices, as they have a standard fixed size of 3x3. Existing tables onto which more columns are added will not modify article width. Tables with a lot of columns are hard to read with the default article width, and they did not previously increase that width on insertion. task-3847398
Helpdesk managers can now access canned responses directly from the Helpdesk app, even when live chat is not enabled for a team. This makes reusable support replies easier to manage and removes unnecessary options from the helpdesk team form.
Original PR description
We made the following changes: ------------ - Remove some elements and strings from the helpdesk team form the view - Currently, the canned responses menu can be accessed by the helpdesk manager only if livechat is activated in the helpdesk team. In this commit, we have moved it to the helpdesk, so it can be accessed without live chat. task-3776070
Users can now configure custom appointment availability in a simple pop-up without leaving the calendar. This keeps the sharing flow smoother, saves updates before copying the link, and helps ensure invite links point to the correct selected users.
Original PR description
In order to ease the use of custom appointment types, the user, after selecting custom slots in the calendar view, can go to "Configure" button. This creates the appointment type, and before this commit, it redirects to the form view. In order to stay on this view and keep the flow simple and smooth, the button now opens a custom dialog form view, simplified and with custom buttons: "Copy Link" (also saving and closing the dialog) and "More options" leading to the full form view, as it was working before. The user can change the created appointment type and when leaving through one of those two buttons, the appointment is saved and the invitation is updated if users were updated. This ensures that the link is correctly leading to selected users. Task-3805720
Subscription order history has been reorganized so key events such as cancellations, currency changes, and pricing updates are recorded more clearly and in the right order. This gives sales and subscription teams a more reliable view of customer subscription changes while reducing incorrect or confusing log entries.
Sales teams can now more easily filter and group commission and subscription reports using useful criteria such as referrers and subscription log details. This makes it faster to analyze sales activity and understand performance drivers without manual workarounds.
Original PR description
Before this PR, some useful filters and group by were missing.
Resolved issues and error corrections
This fixes an internal test setup issue in the Dutch SBR reporting module caused by an incorrect code rebase. It helps keep automated checks reliable, reducing the risk of unnoticed problems in Dutch tax reporting functionality.
Original PR description
A bad rebase removed the classmethod attribute on the setUpClass runbot-64610
A payroll account test sequence was corrected so the automated checks follow the intended order. This helps keep Belgian payroll account testing reliable and reduces the risk of false test failures during future updates.
Original PR description
This commit fixes wrongly swapped test steps in hr_contract_salary_tour_2
The task portal now uses the correct timesheet hours value when showing subtask totals. This prevents missing or incorrectly formatted hour values for customers viewing project task information online.
Original PR description
Before this commit, due to a bad rebase, the changes made in odoo/odoo#122814 changed `task.subtask_effective_hours` by `timesheets_by_subtask_amount` in span elements inside `hr_timesheet.portal_timesheet_table` but the variable `timesheets_by_subtask_amount` does not exist inside that template. That's why the value cannot be converted by the widget defined for that span element. This commit adapts the template to be sure `task.subtask_effective_hours` is used instead of that variable. runbot-64479
Miscellaneous changes
The reconciliation of journal items imported from Winbooks is done when all those items are posted. However if one of the imported items to reconcile have zero as balance, it will trigger an error "You are trying to reconcile some entries that are already reconciled." because Odoo consider zero balance lines as reconciled and block the user of posting the entries. This fix removes the reconciliation data when the Winbooks file is imported if the item has a zero balance since this item does no
Original PR description
The reconciliation of journal items imported from Winbooks is done when all those items are posted. However if one of the imported items to reconcile have zero as balance, it will trigger an error "You are trying to reconcile some entries that are already reconciled." because Odoo consider zero balance lines as reconciled and block the user of posting the entries. This fix removes the reconciliation data when the Winbooks file is imported if the item has a zero balance since this item does not need to be reconciled in the future. opw-3830355 Forward-Port-Of: odoo/enterprise#61743
*: product, stock_barcode product: - Add a on change method on barcode to add autofill record. - Find products in barcodelookup.com from the barcode field stock_barcode: - Display a popup(form-view) to create a product if the scanned product is not available in the database and autofill the record. Co-authored-by: jva-odoo jva@odoo.com Co-authored-by: rare-odoo rare@odoo.com task-3871453 Forward-Port-Of: odoo/enterprise#61949
Original PR description
*: product, stock_barcode product: - Add a on change method on barcode to add autofill record. - Find products in barcodelookup.com from the barcode field stock_barcode: - Display a popup(form-view) to create a product if the scanned product is not available in the database and autofill the record. Co-authored-by: jva-odoo jva@odoo.com Co-authored-by: rare-odoo rare@odoo.com task-3871453 Forward-Port-Of: odoo/enterprise#61949
With [1], we have changed the field name ``l10n_in_gstr_gst_production_env`` to ``l10n_in_edi_production_env``in some files, but its reference was still present at [2]. This causes an exception when the users follow below steps: Step to reproduce: - Install ``l10n_in_reports_gstr`` module - Switch to ``IN Company`` - Accounting > Configuration > Indian Integration > Indian GST - Click on ``Buy Credits`` Traceback: ``AttributeError: 'res.config.settings' object has no attribute
Original PR description
With [1], we have changed the field name ``l10n_in_gstr_gst_production_env`` to ``l10n_in_edi_production_env``in some files, but its reference was still present at [2]. This causes an exception when the users follow below steps: Step to reproduce: - Install ``l10n_in_reports_gstr`` module - Switch to ``IN Company`` - Accounting > Configuration > Indian Integration > Indian GST - Click on ``Buy Credits`` Traceback: ``AttributeError: 'res.config.settings' object has no attribute 'l10n_in_gstr_gst_production_env'`` This commit will resolve the above error by changing the name of the field to ``l10n_in_edi_production_env`` at [2]. [1] : https://github.com/odoo/enterprise/commit/328c01e601d7905df3ebfb4c6b014c7dbf09fce2 [2] : https://github.com/odoo/enterprise/blob/ba99dd4c236353c43376210a9aabcb0af5bd0299/l10n_in_reports_gstr/models/res_config_settings.py#L68C9-L69C88 sentry-5287121031 Forward-Port-Of: odoo/enterprise#61829
…igher rules Have rules such as: 1. no domain, notification order: 1 2. no domain, notification order: 2 3. a domain that doesn't match the record, notification order: 2 Manually validate the rule 1, that is, do not hit the button of the action, rather, enter the popup of the approvals, and validate the rule. The spec of the flow is that, when all rules from a level (or notification order) have been validated, rules that have a higher order will trigger an activity and a notification
Original PR description
…igher rules Have rules such as: 1. no domain, notification order: 1 2. no domain, notification order: 2 3. a domain that doesn't match the record, notification order: 2 Manually validate the rule 1, that is, do not hit the button of the action, rather, enter the popup of the approvals, and validate the rule. The spec of the flow is that, when all rules from a level (or notification order) have been validated, rules that have a higher order will trigger an activity and a notification to their responsible. After all, those rules are "next in line". Before this commit, both rule 2 and 3 sent a notification and created an activity for the current record. This was wrong as rule 3 should not be considered, because its domain doesn't match the record. After this commit, only rule 2 sends a notification and creates an activity. opw-3815732 Forward-Port-Of: odoo/enterprise#61746
Added a test for partners vat export in DateV report. task-3866785 Forward-Port-Of: odoo/enterprise#61202
Original PR description
Added a test for partners vat export in DateV report. task-3866785 Forward-Port-Of: odoo/enterprise#61202
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
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 will fix the computation of the double holiday pay recovery to match legal requirements. Task: 3893867 Forward-Port-Of: odoo/enterprise#61540
Original PR description
This will fix the computation of the double holiday pay recovery to match legal requirements. Task: 3893867 Forward-Port-Of: odoo/enterprise#61540
31 changes
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
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
Code cleanup and technical improvements
This update removes a leftover initialization file from the l10n_generic_coa module, which was already removed in version 17.0. The file appears to have been accidentally left behind and is no longer needed. This cleanup helps keep the codebase organized and prevents confusion about which modules are actually active.
Original PR description
Description of the issue/feature this PR addresses: The module l10n_generic_coa was removed from version 17.0 but the __init__.py file is still there. I am not sure if this file is necessary or not, maybe for migration, but it looks like a mistake leaving it. 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