Daily updates from Odoo
Navigate
Branch
Wednesday, January 21, 2026
352 changes
20 changes
Resolved issues and error corrections
This update fixes an error in the Point of Sale order report that incorrectly calculated margins for refunded orders. The fix ensures that refunds are properly accounted for, resulting in accurate margin figures displayed in the report. An app update is required to implement this change.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: -…
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241870
This update resolves an issue where the POS system in Ecuador would crash when a customer was removed from the partner list after selecting 'Consumidor Final'. The fix ensures a customer is always selected, either a specific customer or 'Consumidor Final', improving stability and compliance with Ecuadorian tax regulations.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570 Forward-Port-Of: odoo/enterprise#104049 Forward-Port-Of: odoo/enterprise#102221
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change only applied when the 'pos_appointment' module was active. Now, the change is consistent across all POS form dialogs, providing a cleaner and more streamlined user experience.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197 Forward-Port-Of: odoo/odoo#240165
This update removes a redundant 'OK' button from POS form dialogs, ensuring a cleaner and more consistent user experience across all Point of Sale operations. The change was made to standardize the styling across the entire POS module, previously the removal was only applied when the `pos_appointment` module was installed.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165 Forward-Port-Of: odoo/enterprise#102197
This update resolves a potential issue where the website editor could fail due to timing problems when opening. By ensuring the editor waits for the iframe to fully load, the editor now works consistently and reliably, especially on slower network connections. This improves the user experience for creating and editing website content.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039 Forward-Port-Of: odoo/odoo#243256
This update simplifies the process of managing product pricing tags. The 'update all' button has been removed, and now only the buttons for products that have been edited will function. This change streamlines the workflow for pricing adjustments.
Original PR description
To ease update of pricer tags, we removed the "update all" button to only have the one that update edited products. Task: 5380332 Forward-Port-Of: odoo/enterprise#103114
This update fixes a technical issue that could cause list views to crash when aggregating data from certain financial fields. The change ensures that the system gracefully handles situations where currency information isn't automatically provided, preventing errors and improving data reliability in reports and dashboards.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692 Forward-Port-Of: odoo/odoo#244548
This update resolves a test failure related to marking inbox messages as read when opening a channel in Odoo. Previously, the test was unreliable due to messages being fetched before the expected RPC call. This change ensures the initial fetch occurs first, guaranteeing the test's consistent results.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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 Forward-Port-Of: odoo/odoo#244693
This update fixes a visual issue where the 'Invite a User' dialog in the discuss app didn't fully utilize the available screen space. The fix ensures the dialog expands to the full width of the modal window, regardless of screen size. This improves the user experience and ensures consistent appearance.
Original PR description
Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Have window take about half size of a 1080p monitor - Open "General" in…
Before this commit, the channel invitation dialog had its content not taking the whole width of modal. Steps to reproduce: - Have window take about half size of a 1080p monitor - Open "General" in discuss app - Open the Member list - Click on "Invite a User" => Invitation dialog takes about half of the width of modal. This happens because the channel invitation was wrongly assumed to be inside a resizable panel, and thus the size was limited by the max width when in resizable panel. The rule to determine whether the action is in a resizable panel was poor: any action panel in discuss app was considered as resizable. This commit fixes the issue by limiting the responsive sizing, intended only for resizable panel, only when the action panel has the `.o_resizable_panel`, which is specific to when action panel is being used inside resizable panel. Task-5804100 Before / After <img width="625" height="231" alt="Screenshot 2026-01-20 at 16 12 31" src="https://github.com/user-attachments/assets/10c02939-c4c1-47fa-82f8-4d8d037d3f0c" /> <img width="621" height="231" alt="Screenshot 2026-01-20 at 16 12 18" src="https://github.com/user-attachments/assets/eec1447c-cb42-4751-b17a-ff7b2e70b8e9" />
This update resolves an issue where the employee presence status widget incorrectly displayed for archived employees. The code has been updated to hide this widget when an employee record is marked as inactive, improving the user experience and ensuring consistent data presentation.
Original PR description
**Steps to reproduce:** Navigate to Employees -> Open an archived employee -> the presence status appears below the Archived banner **Solution:** Hide the presense status widget when the employee is inactive Task: 5350479 Forward-Port-Of: odoo/odoo#236947
This update ensures that eWaybill invoices for Indian exports accurately reflect reverse charge GST amounts. Previously, these amounts were missing, causing discrepancies between Odoo and the government's eWaybill system. This fix aligns the eWaybill data with the correct values, simplifying compliance and avoiding potential issues with tax authorities.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This update ensures that vendor bills with slightly different VAT number formats (with or without dots) are correctly linked to the same contact in Odoo. Previously, variations in VAT number formatting caused duplicate contact creation, leading to data inconsistencies. This change improves data accuracy and simplifies vendor management.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update corrects a visual bug where an 'Add Item' button incorrectly remained visible when no topics were present in a web page snippet. The fix ensures the button disappears when there are no topics, preventing a technical error. This improves the user experience by removing unnecessary elements.
Original PR description
Steps to reproduce: - Drag and drop a "Topics List" snippet onto a web page. - Remove all "Topic" items from the snippet so that none remain. - Click the "Add New" button. - A traceback occurs. This bug is caused by the fact that the "Add item" option is defined in the "Options" section of the parent element of the topics. As a result, the option button remains visible even when no topics exist anymore. Clicking it then triggers a traceback because the option attempts to duplicate an element that does not exist. In this commit, we fix the issue by adding an "applyTo" on the option, targeting the topics, so that the "Add New" button no longer appears when no topic is present. Note that the same bug exists for other snippets, and this commit fixes them as well. task-5462596 Forward-Port-Of: odoo/odoo#244126 Forward-Port-Of: odoo/odoo#244034
This update resolves an issue preventing users with the Romanian language pack installed for the l10n_ro_edi_stock module from accessing the settings app. The fix corrects a mismatch in the system's search for translated text, ensuring proper functionality in Romanian.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update resolves an issue where government entities using TAN instead of PAN for their GSTINs were incorrectly flagged with a validation error. The fix adjusts the system to properly handle GSTINs based on TAN, ensuring accurate partner data creation for these important customers. This improves the usability of the system for government clients.
Original PR description
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection…
### Issue: When using a GSTIN belonging to a government institution, saving the partner raises a ValidationError This happens because these entities often use a TAN (Tax Deduction and Collection Account Number) instead of a PAN as the base for their GSTIN ### Cause: In 19.0, PAN handling was refactored using the new `pan_entity` mechanism With this change, PAN values are validated through `_check_pan_name()`, which incorrectly raises a `ValidationError` for GSTINs that rely on a TAN instead of a PAN: `The entered PAN seems invalid. Please enter a valid PAN.` The PAN entity shouldn't be created for non PAN number ### Steps to reproduce: - Install `l10n_in` and `contacts`, then switch to IN Company - Create a new contact with GSTIN: `07DELN10357E1DH` - Save and the Error is raised ### Notes: At the same time, we'll set the TAN if the GSTIN is based on it The documentation for the TAN structure: https://incometaxindia.gov.in/tutorials/23.%20tan.pdf opw-5461356 Forward-Port-Of: odoo/odoo#243737
This update corrects a calculation error in the fleet module related to the initial date of vehicle acquisition. By setting a default acquisition date, the system now accurately calculates baseline ATN (Activity Tracking Network) metrics, leading to more reliable fleet performance reporting. This ensures better insights into vehicle usage and operational efficiency.
Original PR description
Forward-Port-Of: odoo/odoo#244705
This update resolves a technical issue where a default rate was incorrectly overriding the rate used in delivery FedEx test scenarios. By clearing the existing rate, the tests now accurately reflect the intended rate configurations, ensuring reliable test results. This improves the stability of the delivery FedEx module.
Original PR description
Issue ----- There is some existing rate that takes precedence over the one specified in the test. Rates should be unlinked for safety. ----- Runbot error 237965 Forward-Port-Of: odoo/enterprise#104779
This update fixes a misleading message related to part-time salary calculations. Previously, the system was displaying information based on full-time gross pay, which is no longer accurate due to the change in calculating part-time gross pay. This ensures the system correctly reflects the new part-time salary figures.
Original PR description
Since we are now setting the part-time gross and not the full time gross, this message is misleading. Forward-Port-Of: odoo/enterprise#104877
This update resolves a bug where the link popover would incorrectly appear on input fields within protected nodes. Previously, focusing an input inside a link would trigger the popover. Now, the popover only appears when the input itself is the active element, ensuring a smoother and more predictable user experience when editing content.
Original PR description
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span…
Problem: When the previous focus was on a link, then focusing an input inside a non-editable protected node shows the link popover on the input. Cause: Given the following structure: `<a>a</a><span protected non-editable><input></span>` If the selection is inside the link and the link preview popover is visible, clicking on the input triggers a selection change. Since the input is inside a protected node, the editor keeps the previous editable selection. As a result, `LinkPlugin.handleSelectionChange` still treats the selection as being inside the link and reopens the link popover. Solution: Only show the link popover when the `activeElement` is the editable element. Steps to reproduce: - Add a link. - Upload a file. - Place the selection on the link. - Focus the file name input to rename it. - Observe that the link popover is shown on the file name input. opw-5414078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240016
Features or functions removed from Odoo
This pull request removes a no-longer-used folder within the Odoo Enterprise software. The folder, related to Indonesian tax reporting ('l10n_in'), was identified as inactive and has been removed to streamline the codebase. This change improves the overall efficiency of the system.
Original PR description
ref - https://github.com/odoo/enterprise/commit/ea7893a978c408e5d4437070ae7a6c7a7fbf7167 Forward-Port-Of: odoo/enterprise#104882
13 changes
Resolved issues and error corrections
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable formatting. The change ensures product names are properly separated with spaces, aligning with API specifications and improving invoice clarity for Vietnam's VAT reporting. This ensures accurate data transmission and compliance.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update corrects a bug where the 'Import Bank Statement' action incorrectly selected a journal in multi-company Odoo setups. The fix ensures the action filters by the currently chosen company, preventing errors and ensuring accurate bank statement encoding. A new test confirms the fix's reliability under sudo rights.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104326
This update fixes a test that previously failed inconsistently when marking inbox messages as read after opening a channel. The change ensures the test waits for the initial message fetch, preventing a common scenario where the test incorrectly reports a failure. This improves the stability and reliability of the inbox read functionality.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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 Forward-Port-Of: odoo/odoo#244693
This update fixes an issue where the HTML editor toolbar wouldn't reopen after a link popover was closed, causing unexpected cursor behavior. The fix ensures the toolbar correctly reappears when focus returns to the editor, improving the user experience and preventing disruptions to content editing.
Original PR description
#### Description of the issue this PR addresses: `focusEditable`: - The previous focusEditable logic failed in the website because `this.editable` is `contenteditable="false"` and there is often a non-editable ancestor near the selection. - As a result, the editor did not receive focus, and focusing the wrong element caused the cursor to collapse or move unexpectedly. `Toolbar not remains open`: - The toolbar closed when focus leaves iframe but not getting reopen when focus returns. ### Desired behavior after PR is merged: - The focusEditable focuses the nearest element with `contenteditable="true"` and then restores the cursor when the selection lies inside a non-editable region. - We dispatch `selection_enter_handlers` when focus returns to the iframe document. - This reopens the toolbar when the selection is not collapsed. task-5261404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update strengthens the way Odoo handles errors during file uploads. Previously, the file upload service struggled with inconsistent responses from Odoo controllers (which could return data in different formats). Now, the service is better equipped to manage these errors, leading to a more stable and reliable file upload experience for users.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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 Forward-Port-Of: odoo/odoo#244704
This update fixes a discrepancy in eWaybill invoices for Indian exports. It now accurately includes reverse charge (RC) amounts for GST, aligning the eWaybill data with Odoo and the Indian government's requirements. This ensures accurate reporting and compliance for international shipments.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This update fixes an issue where Odoo was creating duplicate vendor contacts due to differences in how VAT numbers were formatted. Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of whether the name or VAT number format includes dots. This ensures accurate record-keeping and reporting.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update fixes an issue where employee names were being incorrectly formatted in payroll reports. The change ensures that employee names are consistently displayed as 'FirstName LastName', aligning with Swiss legal requirements and improving data accuracy for payroll processing. The fix also includes updated test data to reflect this corrected format.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851 Forward-Port-Of: odoo/enterprise#95252
This update fixes an error in the Swiss VAT reporting (figures 382a and 383a) for transactions with foreign vendors using reverse charge tax. The issue was caused by incorrect tagging of tax amounts, now corrected to accurately reflect reverse charge calculations and ensure correct VAT reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445 Forward-Port-Of: odoo/odoo#244707 Forward-Port-Of: odoo/odoo#244452
This update resolves an issue where accessing settings in the Romanian language version of Odoo resulted in an error. The fix corrects a mismatch in text matching within the system's configuration views, ensuring proper functionality for Romanian users. This improves the user experience for Romanian-speaking clients.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled, leading to a cluttered UI. Now, a placeholder is used when no image is available, providing a cleaner and more consistent experience.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243222
This update fixes an issue where the cookie consent wasn't being saved correctly when the 'I agree' button style was changed to 'Default'. The change triggered a default behavior in the popup system, preventing the consent from being recorded. This ensures that user cookie consent is properly saved after customizing the cookie bar's appearance.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243562
Features or functions removed from Odoo
This pull request removes a no-longer-used folder within the Odoo Enterprise software. The folder, related to Russian localization ('l10n_in'), was identified as containing obsolete files and has been safely removed. This cleanup improves the overall organization and efficiency of the codebase.
Original PR description
ref - https://github.com/odoo/enterprise/commit/ea7893a978c408e5d4437070ae7a6c7a7fbf7167 Forward-Port-Of: odoo/enterprise#104882
6 changes
Resolved issues and error corrections
This update fixes an error in the Swiss VAT reporting module that was causing negative values to be displayed for reverse charge tax figures (382a and 383a). The fix adjusts how these figures are calculated to accurately reflect the reverse charge mechanism, ensuring correct VAT reporting for Swiss companies.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445 Forward-Port-Of: odoo/odoo#244613 Forward-Port-Of: odoo/odoo#244452
This update fixes a problem where the file upload service wasn't properly handling errors from different types of Odoo API responses (JSON, JSONRPC, or HTML). Now, the service is better equipped to manage these errors, leading to a more stable and reliable file upload experience. This ensures users can consistently upload files without unexpected interruptions.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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 Forward-Port-Of: odoo/odoo#244704
This update fixes a discrepancy in eWaybill invoices for exports to India. It now includes reverse charge (RC) amounts in the total invoice value, aligning with the Indian government's eWaybill system. This ensures accurate reporting and compliance with GST regulations.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This update fixes an issue where Odoo was creating duplicate contacts for vendor bills with slightly different VAT number formats (with or without dots). Now, Odoo will correctly identify and link bills with the same VAT number, regardless of formatting, ensuring accurate record-keeping and reporting. This improves data consistency and simplifies reconciliation processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update resolves an issue where accessing settings in the Romanian language version of the l10n_ro_edi_stock module resulted in an error. The fix ensures that settings can be accessed correctly when the Romanian language is selected for a company, improving usability for Romanian-speaking users.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
Features or functions removed from Odoo
This pull request removes a no-longer-used folder within the Odoo Enterprise software. The folder, related to Russian localization ('l10n_in'), was identified as containing outdated files and has been safely removed. This cleanup improves the overall system organization and efficiency.
Original PR description
ref - https://github.com/odoo/enterprise/commit/ea7893a978c408e5d4437070ae7a6c7a7fbf7167 Forward-Port-Of: odoo/enterprise#104882
8 changes
Resolved issues and error corrections
This update fixes an issue where the 'Import Bank Statement' feature incorrectly selected a journal in multi-company Odoo setups. The change ensures the feature now filters by the currently chosen company, preventing errors and ensuring accurate bank statement encoding. A new test has been added to verify this fix.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104326
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change adds a space to separate the name and description, ensuring invoices comply with API specifications and maintain clear formatting for the Vietnam VAT reporting process. This improves data accuracy and readability.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994
This update fixes an issue where VAT import taxes were incorrectly generating journal entries due to a change in account settings. The fix updates the default account used for taxes tax_purchase_import_10, tax_purchase_import_8, and tax_purchase_import_5, ensuring accurate financial reporting.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253 Forward-Port-Of: odoo/odoo#244434
This update strengthens the file upload process by ensuring the service correctly handles various error responses from Odoo controllers. Previously, the system struggled to interpret different API formats (JSON, JSONRPC, HTML), leading to upload failures. Now, the file upload service is more robust and reliable in handling these diverse responses.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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 Forward-Port-Of: odoo/odoo#244704
This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, invoices with the same VAT number, even with variations in formatting, will always be linked to the same contact, streamlining our accounting processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update allows store managers to directly create new products within the Point of Sale (POS) interface. Previously, this functionality was restricted to system administrators, limiting store managers' ability to quickly add new items to their inventory. This change improves operational efficiency and responsiveness for retail locations.
Original PR description
Before this commit, only system users could create products from the POS interface. This limited the ability of store managers. opw-5418727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240520
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the POS experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241373
This update resolves an issue where accessing settings was blocked when the l10n_ro_edi_stock module was used with the Romanian language selected. The fix corrects a mismatch in the system's text search, ensuring settings are accessible for Romanian users. This improves usability for Romanian-speaking customers.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
25 changes
Enhancements to existing features
This update adjusts the maximum NSSF (National Social Security Fund) contribution limits to align with the latest regulations under the 2013 NSSF Act. Specifically, the lower and upper earnings limits have been revised, impacting the total combined contribution a worker can make. This ensures compliance with current Kenyan law.
Original PR description
This commit updates the NSSF Lower and Upper Earnings Limits in accordance with the 4th year of implementation of the NSSF Act 2013. - Set Lower Earnings Limit (Tier 1) to 9,000. - Set Upper Earnings Limit (Tier 2) to 108,000. - Resulting max combined contribution is now 6,480. Task: 5485002
This update enhances the user experience by visually indicating inactive comodel records (like contacts and users) within Odoo screens. Inactive records are now displayed with a faded text style and grayed-out avatars, making it easier for users to quickly identify and manage archived data. This improves clarity and reduces the need to manually check record status.
Original PR description
**WIP WIP WIP** When a screen displays comodel records (M2x), the only way to check if the record is archived is to open it. This commit sets a `text-faded` on M2x inactive comodel records and grays out the avatars of inactive contacts/users. task-5469063
Resolved issues and error corrections
This update prevents the HTML Builder editor from freezing due to rare errors within its internal processes. A timeout mechanism is now in place to release the editor and alert the user to potential data issues, ensuring a smoother user experience. The change also includes safeguards to prevent long-running operations from causing problems.
Original PR description
Before this commit, if an error occurred within the mutex that did not explicitly throw, the mutex could remain locked indefinitely. This blocked subsequent actions and prevented the user from saving. This commit introduces a timeout mechanism for Operations. This is intended for very rare cases as a last resort to prevent the editor from becoming completely unresponsive. When a timeout occurs: - The mutex is released, allowing the user to recover (e.g. by deleting the faulty snippet). - The user is notified of the issue. - A warning is displayed during saving to indicate that the content might be in a corrupted state. Additionally, the `canTimeout: false` flag is added to options that are expected to remain open for long periods (such as the snippet modal). task-5152911 Forward-Port-Of: odoo/odoo#244786 Forward-Port-Of: odoo/odoo#233079
This update enhances the accuracy of Vietnamese tax reports by correcting outdated calculations and aligning VAT tax definitions. The changes include updating tax labels, assigning accounts, and introducing new tax components, ultimately providing clearer and more reliable tax information for users. This PR is related to a larger Enterprise update.
Original PR description
Before: -`Import tax` remained defined, even though the calculation was not accurate. -Imported VAT taxes were not aligned with the new specifications. -VAT receivable and payable accounts were not assigned to the tax groups. After: -Removed the import tax to match the updated VAT calculation method. -Updated all imported VAT taxes (0%, 5%, 8%, 10%) with the revised labels and descriptions. -Added new VAT-related accounts to the appropriate tax groups to ensure clearer reporting. -Introduced new taxes such as “Subtract Base” and reorganized component taxes. -Cleaned up the tax report by removing the outdated “Import Tax” line. Impact: -Provides clearer, more consistent tax information to users. -Keeps tax reports accurate and easier to understand. Related Enterprise PR: https://github.com/odoo/enterprise/pull/100871 task-5166420
This update enhances the accuracy of tax reports for Odoo Enterprise users in Vietnam by correcting previous calculation errors and aligning VAT tax definitions. The changes ensure clearer, more consistent tax information, simplifying reporting and improving financial data reliability.
Original PR description
Before: -Import tax remained defined, even though the calculation was not accurate. -Imported VAT taxes were not aligned with the new specifications. -VAT receivable and payable accounts were not assigned to the tax groups. After: -Removed the import tax to match the updated VAT calculation method. -Updated all imported VAT taxes (0%, 5%, 8%, 10%) with the revised labels and descriptions. -Added new VAT-related accounts to the appropriate tax groups to ensure clearer reporting. -Introduced new taxes such as “Subtract Base” and reorganized component taxes. -Cleaned up the tax report by removing the outdated “Import Tax” line. Impact: -Provides clearer, more consistent tax information to users. -Keeps tax reports accurate and easier to understand. Related Community PR: https://github.com/odoo/odoo/pull/237873 task-5166420
This update resolves an issue where the POS system in Ecuador would crash when a customer was removed from the partner list after selecting 'Consumidor Final'. The fix ensures a customer is always selected, either a specific customer or 'Consumidor Final', improving stability and compliance with Ecuadorian regulations. This prevents data errors and ensures accurate reporting.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570 Forward-Port-Of: odoo/enterprise#104049 Forward-Port-Of: odoo/enterprise#102221
This update fixes a calculation error in the POS order report's margin calculation. Previously, refunds were incorrectly displayed, leading to inaccurate profit figures. The fix ensures that refund orders are properly accounted for, providing a more precise margin calculation for all order types.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: -…
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241870
This update removes a redundant 'OK' button from form dialogs within the Point of Sale system. Previously, this change only applied when the 'pos_appointment' module was active. Now, the change is applied consistently across all POS form dialogs, improving the user experience and ensuring a uniform design.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task:5406858 Related Enterprise PR: https://github.com/odoo/enterprise/pull/102197 Forward-Port-Of: odoo/odoo#240165
This update removes a redundant 'OK' button from POS form dialogs, ensuring a cleaner and more consistent user experience across all Point of Sale operations. The change was made to standardize the styling, previously only applied when the 'pos_appointment' module was installed.
Original PR description
Before this commit: =================== - The extra `OK` button in form view dialogs was removed only when the `pos_appointment` module was installed. After this commit: ================== - The CSS to remove the extra `OK` button has been moved from `pos_appointment` to the base `point_of_sale` module, ensuring consistent behavior across POS form dialogs. Task: 5406858 Related Community PR: https://github.com/odoo/odoo/pull/240165 Forward-Port-Of: odoo/enterprise#102197
This update resolves an issue where the website editor could become unreliable when creating new pages under slower network conditions. The fix ensures the editor only opens after the iframe has fully loaded, resulting in a more consistent and dependable editing experience. This improves the overall usability of the website builder.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039 Forward-Port-Of: odoo/odoo#243256
This update fixes inaccuracies in the reporting of Undistributed Profit After Tax (420.1 and 420.2) for Vietnamese accounting. The changes ensure accurate calculation of equity balances by correcting formulas and preventing double-counting, improving the reliability of financial reports.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104935 Forward-Port-Of: odoo/enterprise#104373
This pull request resolves a minor issue with the demo functionality within the Quality Control module. The changes ensure the demo runs correctly and provides a functional example for users. This improves the usability and clarity of the Quality Control module's demonstration.
Original PR description
demo
This update resolves an issue preventing localized date/time intervals within the appointment scheduling feature. The fix now correctly localizes only the start and end times of intervals, ensuring accurate display across different locales. This improves the user experience for scheduling appointments in various languages.
Original PR description
Following this refactor PR: https://github.com/odoo/enterprise/pull/96139, the localized method could not be applied to the whole interval object as it contains a model. This commit fixes the issue by localizing only the start and end of the interval. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/238001
This update addresses a potential issue where users could infer application status by seeing warning messages. The change now creates internal activities for applicants, managed by recruiters, providing a more secure and transparent tracking system. This prevents misuse of the application process and improves data privacy.
Original PR description
When applying to a job with an email, phone number, or LinkedIn profile that is already associated with an applicant, a warning would appear showing that there is either an existing applicant or an existing refused applicant. This can cause problems as anyone can use this method to see if a person has applied and deduce the status of their application. This PR replaces these warnings in the frontend by creating activities on the applicant that are assigned to either the applicant's recruiter or the applicant's job's recruiter. task-4943060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update increases the timeout for the main Odoo test suite to address occasional failures during nightly builds. Previously, the suite's execution time exceeded limits due to the continued use of the older, full test run. Increasing the timeout to one hour provides a longer execution window and helps ensure consistent test results.
Original PR description
This commit increases the timeout of the main (desktop) hoot test suite. Since [1], the suite is split by sub-builds, such that each sub-build only runs the tests defined in the addons that are tested by that sub-build. So the suite never timeouts anymore on regular builds. However, in nightly, we still run the whole suite "old school", i.e. all tests in the same run. In that case, the suite sometimes (in 19.1) or often (in master) exceeds the previous timeout (50m). With 1 hour, we hope that it will be enough. Note that the number of tests keeps increasing, hence the need to increase the timeout. [1] https://github.com/odoo/odoo/pull/234132 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 Forward-Port-Of: odoo/odoo#244715
This update resolves a crash that occurred when grouping data in list views using floating-number fields with the 'monetary' widget. The fix ensures the system handles missing currency information gracefully, preventing aggregation errors and improving the stability of list views. This enhances the reliability of reporting and data analysis.
Original PR description
This commit resolves a traceback during list view aggregation when the view is grouped. The crash occurred specifically when aggregating a `float` field that uses the `monetary` widget. Unlike true `monetary` fields, the server does not automatically send a `currency_id` aggregate for `float` fields. The aggregation logic previously failed when this data was missing; it now handles the case by ignoring it since it's not supported. opw-5725692 Forward-Port-Of: odoo/odoo#244548
This update resolves an issue where a test for marking inbox messages as read would intermittently fail due to the order in which messages were processed. The change ensures the initial fetch of messages occurs first, guaranteeing the expected test outcome. This improves the reliability of the inbox read functionality.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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 Forward-Port-Of: odoo/odoo#244693
This update resolves an issue where spreadsheet pivot insertions could fail or not resize correctly. The code has been consolidated and now automatically adds necessary columns, ensuring a smoother and more consistent experience for users inserting pivots from spreadsheets, mirroring the web pivot functionality.
Original PR description
Current behavior before PR: - Inserting a pivot from a spreadsheet could trigger spill errors when the pivot had more columns than the default columns. - Columns could not be resized when inserting a pivot from a spreadsheet, unlike insertion from a web pivot view. Desired behavior after PR is merged: - Both pivot insertion flows are combined into a single implementation to remove duplicated code. - Required columns are added automatically to prevent spill errors. - Columns are resized when inserting a pivot from a spreadsheet, matching the behavior of web pivot insertion. Task: [5404283](https://www.odoo.com/odoo/2328/tasks/5404283) Forward-Port-Of: odoo/enterprise#102524
This update resolves an issue where certain carriers weren't correctly recognized when integrating with shipping partners. The change ensures that all carriers are compatible, streamlining the shipping process and preventing errors related to partner recognition. This improves the reliability of order fulfillment.
Original PR description
Forward-Port-Of: odoo/odoo#244742 Forward-Port-Of: odoo/odoo#244035
This update fixes an issue where the Odoo Studio export process incorrectly excluded certain related and computed fields. The team refined the logic to handle these fields separately, ensuring a more accurate export of data. The Industry team has approved these changes.
Original PR description
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but…
This commit fixes the computation of excluded fields for the studio export models. Before this commit, the excluded fields computation was considering computed and related fields in a similar way but there are subtle differences that cause the excluded fields to sometimes be wrong. While analyzing the heuristic with the ORM team, we decided to separate the computation of related and computed fields. After this commit, we have a refined computation of excluded fields for related and computed fields: - for computed fields (that are not related ones), we always exclude them except when they are writeable (i.e. stored or with inverse) - for related fields, we always exclude them when the relation is in the list of related models to exclude. We also exclude them when they are not writeable on the current record only (not the source record), except if they are required. Some export scenarios have been tested manually and brought with them adaptations in the hardcoded lists of default fields to exclude. The Industry team agreed with these changes. Task id: opw-4974787 Forward-Port-Of: odoo/enterprise#104780 Forward-Port-Of: odoo/enterprise#87530
This update ensures that eWaybill invoices exported from Odoo accurately reflect reverse charge amounts for GST, aligning with the requirements of the Indian government. Previously, the eWaybill JSON didn't include these charges, causing discrepancies. This change fixes this issue, improving data accuracy for export transactions.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This change fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with VAT numbers formatted with or without dots. Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of formatting, ensuring accurate record-keeping and reporting. This improves data consistency and reduces the risk of manual reconciliation.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
A recent issue prevented users from using the database obfuscation command. This update corrects a technical error where the command was incorrectly processing database names, resulting in an error. Now, the obfuscate command functions as intended, ensuring data protection.
Original PR description
It is not possible to use the obfuscate command Steps to reproduce: 1. Initialize a database `test` 2. In a terminal, try to obfuscate the database with the command `python odoo/odoo-bin obfuscate --pwd=1234 -d test` 3. An error occurs Issue: `config['db_name']` returns a list Solution: Make sure we use obfuscate with a single database and get the first (and only) database in the list opw-5480280 Forward-Port-Of: odoo/odoo#244577
Features or functions removed from Odoo
This update removes the `stock.scrap` model, simplifying the product scrap process. The change shifts to using `stock.move` records, offering a more efficient workflow for recording and managing scrap quantities. This improves the underlying system's efficiency and reduces complexity.
Original PR description
This commit removes `stock.scrap` model without affecting its functionality from the user perspective. Previous to this commit, when a user wants to scrap some product, a record of `stock.scrap` is…
This commit removes `stock.scrap` model without affecting its functionality from the user perspective. Previous to this commit, when a user wants to scrap some product, a record of `stock.scrap` is created which is a scrap order containing info about the product, quantity, scrap reason, etc. When a scrap order is confirmed, it generates a `stock.move` and confirms it so that the quantity move is reflected in the quants. That's why `stock.scrap` model itself provides no intrinsic value and is dispensable. This commit removes the model completely and relies only on `stock.move.line` and `stock.move` to achieve the same functionality. The menu item "Scrap" now redirects to a list of stock.move.lines that has the new field `is_scrap` = true. If the user creates a new record from the list, a draft `stock.move.line` is created initially. When it's confirmed, it generates its `stock.move` and its state is changed to be done. The only fields that are added to `stock.move.line` to fully replace `stock.scrap` are `scrap_reason_tag_ids` and `should_replenish_scrapped`. This commit also adds a new action to scrap a lot/serial number from its form view directly. Task-4606260
This update removes the scrap model within Odoo, streamlining the system and aligning with recent changes. The removal was necessary to adapt existing features and tests following a related update (ODOO/210299). This change improves system efficiency and reduces complexity.
Original PR description
This commit adapts `stock.barcode` and some other tests for the changes introduced in https://github.com/odoo/odoo/pull/210299. Task-4606260
18 changes
Resolved issues and error corrections
This update fixes an issue where clicking links within the Odoo chat window on mobile devices caused the chat window to remain open and cover the new page. Now, the chat window automatically folds when a link is clicked, ensuring users can easily view the linked page without manually adjusting the chat window.
Original PR description
Clicking on an odoo link in the chat window will take the user to the related page in odoo. However, in mobile view, the chat window remains unfolded and covers the entire page, so the user can't see the newly opened page below the chat window unless they fold the chat window. This change fixes this by folding the chat window in mobile view when clicking an odoo link inside the chat window. task-4762503 Forward-Port-Of: odoo/odoo#244383 Forward-Port-Of: odoo/odoo#208440
This update resolves an issue where changing a tax lock date to a past date would trigger an error. The fix prevents the system from generating default external values when the lock date is set in the past, ensuring smoother operation and preventing unexpected errors related to date calculations.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update resolves an issue where printers would become unavailable for extended periods after disconnecting, leading to user errors and potential double printing. The change introduces a safeguard to only remove printers from the system after multiple disconnection attempts, ensuring printers are reliably available and jobs are processed correctly.
Original PR description
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2…
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface. The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box. However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds. Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects. The user in pos can then press "retry" which will lead to a double printing. This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups. Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed. The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected Forward-Port-Of: odoo/odoo#244644 Forward-Port-Of: odoo/odoo#244076
This update enhances the security of user profile editing by utilizing a new internal helper function, '_can_edit_country()', to determine if a user is authorized to change their country setting. This change, implemented as a fix, ensures that profile editing aligns with security standards introduced in Odoo 18.4.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916 Forward-Port-Of: odoo/odoo#244694
This update fixes a potential issue where negative taxable income amounts appeared on payslips when state deductions exceeded employee gross income. The change ensures that taxable income defaults to zero in these scenarios, preventing incorrect financial reporting and improving payroll accuracy. This resolves a prior bug related to state tax calculations.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#102599 Forward-Port-Of: odoo/enterprise#98114
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the point-of-sale module. The change ensures the module aligns with legal requirements and automatically installed features. This correction was prompted by a customer and maintains consistent behavior with other fiscal reform modules.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835 Forward-Port-Of: odoo/enterprise#104671
This update removes unnecessary integer rounding from monthly VAT reports for Italy. Previously, rounding was incorrectly applied, leading to inaccurate reporting. This change ensures that monthly VAT reports align with the correct accounting standards and provides more reliable financial data.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243671 Forward-Port-Of: odoo/odoo#243100
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports, a consequence of a previous split in the reporting functionality. This ensures accurate VAT calculations for monthly reporting.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update fixes an error in the Vietnamese financial reports that was causing incorrect calculations for key balance sheet codes (420.1 and 420.2). The changes ensure accurate reporting of undistributed profit, improving the reliability of financial data and compliance with Vietnamese accounting standards.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104786 Forward-Port-Of: odoo/enterprise#104373
A bug was preventing users from adding fields to the invoice report within Studio. This was caused by an outdated XPath reference in the report's configuration. The update corrects this by targeting a stable HTML element, ensuring reports can be edited correctly and consistently.
Original PR description
Currently, an error occurs when editing the invoice report in Studio and adding fields to the report table. ### **Steps to reproduce** - Install 'l10n_sa' and Studio with demo data - Open an invoice and switch to Studio mode - Edit the Invoice report and add the 'Products' field & click save. ### **Error:** `ValueError: Element xpath //div[@id=total_payment_term_details_table]` `cannot be located in parent view` ### **Root Cause:** Due to recent updates with [this commit](https://github.com/odoo/odoo/pull/220167/changes/39ba5962923f04eef85174aaf2667481510cfaf4), payment terms are now targeted from `account/report_invoice.xml`. However, the inherited view was still targeting `td` and `indexed t` nodes, which no longer exist in the updated structure. This causes the xpath to fail when the report is altered by Studio. ### **FIX:** Update the xpath expression to target a stable `div` container. **opw-5485437,5498946**
This update corrects a technical issue where performing an undo operation within the HTML editor would generate a traceback error. The fix ensures that undoing actions now functions smoothly without causing errors, improving the overall stability and usability of the editor. This resolves a minor bug that could potentially disrupt user workflows.
Original PR description
Current behavior before PR: - Inserting a /code block, then adding text above it and performing an undo would trigger a traceback. Desired behavior after PR is merged: - Undo now correctly removes the inserted character without causing any traceback. task-5445873
This update resolves a bug where the column layout within the HTML editor would break after undoing column adjustments. Specifically, the system now correctly maintains column structure after multiple column conversions and undo operations, ensuring a stable and predictable user experience. This prevents disruptions to the editor's functionality.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create 3 columns using powerbox - Convert it into 4 columns - Press ctrl + z to make it 3 columns - Convert it into 4 columns again using powerbox Notice that column structure is broken. This happens because after undo operation, in `changeColumnsNumber` the regex replaces column div className incorrectly leading to invalid colund structure. **Desired behavior after PR is merged:** This PR ensures that column structure doesn't break. task-5468578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where product references were appearing in the names of products displayed on the website's product carousel. This change ensures that product names are clean and accurate, improving the user experience for customers browsing our online store. The fix was triggered by a specific scenario involving a product with a single value in its free text attribute.
Original PR description
**Issue**
When a product has a free text attribute with one value, the product reference appears in the name of the product on the product carousel.
**Expected behavior**
The product reference should not appear in the name of the product on the product carousel.
**Steps to reproduce**
1. Create a product to be sold online
2. Give it an internal reference
3. Add a free text attribute with one value
4. Set a product carousel on a website page
5. Disable "show variants" in the settings of the carousel
=> The product reference appears in the name of the product
**Note**
The issue happened only if the free text attribute has only one value, with more than one value, the product reference did not appear.
**Fix**
Updated the QWeb template to use the prepared clean title with data.get('display_name') instead of record.display_name
opw-5410822
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242791A recent update to the delivery system caused an issue that was subsequently identified. This pull request reverts the problematic changes to restore the previous, correct behavior. The issue will be addressed in a future update.
Original PR description
Bug introdcued in: https://github.com/odoo/odoo/commit/6901863d30f524c160971c9f5c97846ffd1fa5f5 The fix was misleading because forcing the context in the unit test caused incorrect assumptions. Passing `default_carrier_id` in the context prevents the computed method from being called, breaking expected behavior. This revert restores the previous behavior as the fix is incorrect. The issue will be resolved in another PR. Forward-Port-Of: odoo/odoo#244774
This update resolves an issue that previously caused errors when adding new transcription snippets to records before they were saved. The change ensures that record IDs are correctly established, preventing these errors and improving the stability of the AI transcription component. This enhances the user experience by allowing users to consistently add and manage transcription snippets.
Original PR description
This PR fixes an issues where an exception would be thrown when inserting a transcription snippet on an unsaved record. It does so by removing the resId, resModel props and only retrieving them when actually needed (when opening the full composer to send the summary). Also whennever opening the full composer, we force a save on the record to ensure proper resId. task-5788331
This update corrects a minor issue in how overtime hours are recorded, ensuring more accurate calculations for employee balances and reporting. Previously, overtime was rounded to two decimal places, leading to potential inaccuracies when aggregating data. This change improves the reliability of overtime calculations, particularly for large teams and reporting needs.
Original PR description
### Current behavior: Overtime hours are stored with a two-decimal precision. This means a minute is stored as a minute and twelve seconds in the worst case, which would amplify The overtime given or taken on a particular attendance. This is problematic when aggregating the records for large datasets to compute the balance or for reporting ### Expected behavior: A minute should be stored closer to its real decimal value to minimize the error in aggregations. as a minute and 1.2 seconds opw-5422827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where product prices weren't accurately calculated when using Point of Sale (PoS) journals with different currencies. The change ensures standard prices are converted to the PoS currency, preventing incorrect pricelist calculations and ensuring accurate order totals. This improves the reliability of PoS transactions.
Original PR description
The standard price of the products were not converted to the currency of the PoS journal, which could lead to issues when creating pricelist items based on the standard price. Steps to reproduce: ------------------- * Change the currency of any PoS journal to a different currency than the company currency. * Create a product with a standard price > 0. * Create a pricelist that uses the standard price as a base price. (e.g. price = standard price * 2) * Add this product to a PoS order > Observation: The price is not correctly computed according to the pricelist, because the standard price was not converted to the PoS currency. Why the fix: ------------ We just make sure to convert the standard price of the products when loading the products in the PoS session the same way as we do it for the list price. opw-5124388 Forward-Port-Of: odoo/odoo#241620 Forward-Port-Of: odoo/odoo#241168
This update fixes a potential issue in the Nilvera accounting module where the default journal type was incorrectly set. The default has been changed from 'in_invoice' to 'purchase' to prevent incorrect document generation. This ensures Nilvera documents are created with the appropriate accounting settings.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
8 changes
Resolved issues and error corrections
This update fixes an error in the Master Production Schedule (MPS) calculation for kit products sourced from a second warehouse. Previously, the system incorrectly squared the reorder amount, leading to excessive component orders. This change ensures accurate component quantities are ordered, preventing overstocking and improving production efficiency.
Original PR description
***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it…
***Behavior:*** In a setting with a second warehouse that is supplied by the first one. Creating a product that uses that ressuply route, and then adding it to the bom of a kit product will make it so that when ordering the kit product to the second warehouse from the MPS, the system will create an order for an exponential amount of components. When calling action_replenish, kit products for which the components don't have an MPS entry will have their product_ratio computed to know how many components to reorder. However the current formula is wrong or outdated and ends up returning the squared amount. ***Steps to reproduce:*** - Create a second warehouse. - Check Resuply From 'First Warehouse' (this will unarchive a route) - Create a product that uses that route for reordering. - Create a second product - Create a kit for that product BOM composed of the first product make sure the amount of component is more than 1 - In the Master Production Schedule: Add the kit product and make sure it is produced in the second warehouse with the unarchived route. - Add any amount to reorder in 'Replenishment' then click the Order button. - If you go to deliveries and look for your component, you'll see the amount of component per kit squared multiplied by the reordered kit amount. opw-5351460
This update corrects a problem with importing tax rates for Swiss payroll (l10n_ch_hr_payroll) related to the 2026 tax year and single canton reporting requirements. The change ensures accurate tax calculations and reporting compliance for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#104333
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect tax amount formatting. The change ensures the tax amount is calculated using the currency's rounding method, aligning with SInvoice's requirements and preventing errors.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845)
This update corrects errors in VAT import billing by adjusting the default accounts used when creating invoices. Specifically, the account number 33312 was updated, resolving incorrect journal entries. This ensures accurate financial reporting for VAT transactions.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253
This update fixes an issue where Odoo was creating duplicate vendor contacts when receiving invoices with slightly different VAT number formats (with or without dots). Now, Odoo will correctly identify and link invoices with the same VAT number, regardless of formatting variations, ensuring accurate record-keeping.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update fixes an issue where the unit price on Purchase Order Lines created through the vendor catalog wasn't accurately reflecting the vendor's discount. The fix ensures the correct discount is applied and displayed, leading to accurate pricing calculations and improved order accuracy. This impacts how purchase orders are priced when using the catalog feature.
Original PR description
**Steps to reproduce:** - Install the `purchase_stock` module. - Create a product and configure a Vendor Pricelist for a vendor. Include a discount on the vendor pricelist line. - Create a Purchase…
**Steps to reproduce:** - Install the `purchase_stock` module. - Create a product and configure a Vendor Pricelist for a vendor. Include a discount on the vendor pricelist line. - Create a Purchase Order for the same vendor. - In the Purchase Order, add a Purchase Order Line using the catalog (vendor catalog popup) and add a configured product. **Observed behavior:** - The unit price on the Purchase Order Line becomes vendor `unit price − discount` The `discount` field remains empty, causing incorrect price calculations. --- **Example** --- Product-A - > Vendor Price list - > Vendor - > Test Vendor, Unit price = 100 and discount 10 - Create PO with `Test Vendor` and add a Product to POL via catalog then **Current behavior:** Product - A , qty - >1, unit price -> 90, discount->0% , subtotal ->90 **Expected behavior :** Product-A , qty->1, unit_price->100, discount->10%, subtotal->90 --- **Cause:** - The catalog selection applies the vendor pricelist discount directly to the unit price instead of populating the discount field. **Fix:** - Use the vendor pricelist's price as the `unit_price` and apply vendor pricelist discount to the discount field on the Purchase Order Line. --- `NOTE` - This issue is resolved from version 18.2, In this [Commit](https://github.com/odoo/odoo/pull/227695/commits/6b91f393353bcdaeed076d58dcac3149ed587e77#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcd) --- opw-5217345 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235968
This update corrects a typographical error in the tests for the search highlight feature within Odoo. This ensures the search functionality operates correctly and reliably, preventing potential issues with how search results are displayed to users. The fix improves the overall stability and accuracy of the search experience.
Original PR description
Intoduced by https://github.com/odoo/odoo/pull/118794 Forward-Port-Of: odoo/odoo#244720
This update automatically adjusts the start and end dates for salary certificate reporting in the Odoo Switzerland module. Previously, these dates were fixed, but now they dynamically pull from the configured data, ensuring accurate reporting and compliance with Swiss tax regulations. This change simplifies the process for businesses operating in Switzerland.
Original PR description
make Period until and from dynamic from data Forward-Port-Of: odoo/enterprise#104903
2 changes
Resolved issues and error corrections
This update resolves a bug preventing the generation of PDFs with custom header and footer pages when using Python 3.10. The issue was caused by an incompatibility with the previous PyPDF2 version. Upgrading to version 2.12.1 ensures proper PDF rendering and functionality.
Original PR description
The feature of printing PDF with custom header / footer pages does not work with the old version of PyPDF2 on python 3.10. Bump to newer version of PyPDF2 2.12.1. Description of the issue/feature…
The feature of printing PDF with custom header / footer pages does not work
with the old version of PyPDF2 on python 3.10.
Bump to newer version of PyPDF2 2.12.1.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Detail error message with old PyPDF2 version (Ubuntu 20.04 - python 3.10):
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/opt/odoo/17.0/addons/web/controllers/[report.py](https://report.py/)", line 113, in report_download
response = self.report_routes(reportname, docids=docids, converter=converter, context=context)
File "/opt/odoo/17.0/odoo/[http.py](https://http.py/)", line 786, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/opt/odoo/17.0/addons/web/controllers/[report.py](https://report.py/)", line 42, in report_routes
pdf = report.with_context(context)._render_qweb_pdf(reportname, docids, data=data)[0]
File "/opt/odoo/17.0/addons/account/models/[ir_actions_report.py](https://ir_actions_report.py/)", line 58, in _render_qweb_pdf
return super()._render_qweb_pdf(report_ref, res_ids=res_ids, data=data)
File "/opt/odoo/17.0/odoo/addons/base/models/[ir_actions_report.py](https://ir_actions_report.py/)", line 925, in _render_qweb_pdf
collected_streams = self._render_qweb_pdf_prepare_streams(report_ref, data, res_ids=res_ids)
File "/opt/odoo/17.0/addons/sale_pdf_quote_builder/models/[ir_actions_report.py](https://ir_actions_report.py/)", line 57, in _render_qweb_pdf_prepare_streams
pdf.fill_form_fields_pdf(writer, form_fields=form_fields)
File "/opt/odoo/17.0/odoo/tools/pdf/[__init__.py](https://__init__.py/)", line 167, in fill_form_fields_pdf
writer.update_page_form_field_values(page, form_fields)
File "/opt/python3.10-venv/odoo17/lib/python3.10/site-packages/pypdf/[_writer.py](https://_writer.py/)", line 978, in update_page_form_field_values
raise PyPdfError("No /Fields dictionary in Pdf in PdfWriter Object")
pypdf.errors.PyPdfError: No /Fields dictionary in Pdf in PdfWriter Object
```
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an error that occurred when generating PDF accounting reports if a contact lacked a name. The fix ensures that the report exports correctly even when a contact doesn't have a defined name, improving report generation reliability.
Original PR description
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts`…
Currently, an error occurs when exporting an accounting report to PDF if any of the selected contacts do not have a name. **Steps to reproduce:** - Install the `account_reports` and `contacts` modules. - Go to Contacts and open any contact (e.g., Azure Interior). - Click `Add` > `Save & Close`, then `save` the contact. - Navigate to Accounting > Reporting > Aged Receivable. - Click `Partners` button and select the newly created contact (e.g., `Azure Interior, Other Address`). - Click `PDF` to export the report. **Error:** `TypeError: sequence item 0: expected str instance, bool found` **Root Cause:** At [1], `options['selected_partner_ids']` is built using `partner.name`, which may be `False` for unnamed contacts. At [2], the `partner_value` list may therefore contain `False` entries coming from `options['selected_partner_ids']`. When calling `', '.join(partner_value)`, an error is raised because the list contains `non-string` (`bool`) values. **Fix:** This commit prevents errors when exporting reports to PDF and ensures that partner names are displayed in the report the same way as in the partner selection widget. [1]: https://github.com/odoo/enterprise/blob/a0ec2fcdc043cf52f1a646e84b9b97466072d47f/account_reports/models/account_report.py#L745 [2]: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/account_reports/data/pdf_export_templates.xml#L84-L93 opw-5467321