Tuesday, June 24, 2025
20 changes · 18.0
Enhancements to existing features
This change improves how report menu items are updated when reports are turned on in bulk. It reduces repeated work during accounting report setup and testing, helping the process run more efficiently without changing user-facing behavior.
Original PR description
This mostly benefits `test_balance_sheet_balanced` as it mass activates reports on every `_set_up_localization` (so before rendering each report, something it does ~200 times).
When users use the automatic setup fix to make a POS scale certified, the system now also turns on Units of Measure. This helps businesses quickly assign the right product units, such as kilograms, and reduces manual setup after certification fixes.
Original PR description
This commit automatically enables the 'Units of Measure' setting when the user auto-fixes their settings to make their POS scale certified. While this is not a strict requirement, it helps the users to then quickly set the correct units for their products (e.g. kg) task-4885681
Resolved issues and error corrections
A new automated test checks that restaurant table booking and release behavior works as expected in Point of Sale. This helps prevent issues where booked table orders might not be properly sent to the server, improving confidence in restaurant operations.
Original PR description
Following this commit: 9448836cb0307161d829f28bda0bdb5bf50f3a10 This commit adds a test to ensure that the booking and release table functionality works correctly in the POS Restaurant module. The test verifies that when a table is booked the order is correctly sent to the server.
Miscellaneous changes
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 -
Original PR description
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open…
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 - Third line with a price of 0.020 and a qty of 3 - Create a new request for quotation for this product with this vendor - set a quantity of 3 **Current behavior:** The unit price is 0.022 **Expected behavior:** It should be 0.020 **Cause of the issue:** When sorting the set of product.supplierinfo, rounding should not be applied because the rounding will be the one of the currency and the Product Price could allow more decimal than the currency. If we allow vendors price to be more precise the the currency, the sorting should take into account this precision when choosing a vendor. opw-4823919 Forward-Port-Of: odoo/odoo#213826
This fix prevents the Point of Sale screen from failing when an order line is quickly added and then removed, a situation that can happen with loyalty features. It improves cashier reliability by avoiding rendering errors during normal sales workflows.
Original PR description
Before this commit, if an order line was added and then removed (for example, by the loyalty module), it could cause errors during rendering due to missing required props for the orderline. This scenario is common with the loyalty module. opw-4724428 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from printing picking operations for deliveries containing kit products when packaging was selected on one line. The change helps keep warehouse delivery documents reliable for sales involving packaged kits.
Original PR description
Step to reproduce : - Create a quotation with 2 products using kits - Use the delivery smart button - Change one of the line to use a packaging - Print the picking operation Problem: ZeroDivisionError: float division by zero [opw-4824380](https://www.odoo.com/odoo/project.task/4824380) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website eLearning course cards now correctly show the “New Content” ribbon when recently published content has been added. This helps visitors quickly spot updated courses and improves visibility for fresh learning material.
Original PR description
Restore the "New Content" ribbon (activated via page options) which should be displayed on the course card when a new published content has been added during the last 7 days. The ribbon isn't displayed because it's declared in a "t-field" element which replaces its content to display the field at rendering. Task-4852463 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the visual highlighting of selected planning shifts after an underlying calendar behavior changed. It helps users continue to spot important shifts in the Planning calendar as expected.
Original PR description
Before this commit, the PlanningCalendarCommonRenderer override the eventToRender method but this method has been removed in parent class. This commit changes the method overriden to make sure the class is added when some shifts have to be highlighted.
A shop floor manufacturing test now waits for a component update before checking the result. This reduces false test failures and helps keep manufacturing workflows stable for future releases.
Original PR description
### Issue: The tour test_add_component_from_shop_foor_in_multi_step_manufacturing makes an assert on the value of an input before waiting for this input to be updated. runbot-build-error-226734
In certain cases, the unit price value on a partial credit note does not match the unit price on the corresponding invoice This commit solves this issue by using a more precise return value of _get_line_amount_before_discount_jod in XML numbers calculations It also makes sure that all newly created companies in Jordan use `round_globally` for `tax_calculation_rounding_method` task-4877278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F
Original PR description
In certain cases, the unit price value on a partial credit note does not match the unit price on the corresponding invoice This commit solves this issue by using a more precise return value of _get_line_amount_before_discount_jod in XML numbers calculations It also makes sure that all newly created companies in Jordan use `round_globally` for `tax_calculation_rounding_method` task-4877278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214844
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. --- I co
Original PR description
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206026
Steps: - Open any views with a search bar - Press ALT + Q (hotkey used to focus search input) - Nothing happens This behavior has been introduced by https://github.com/odoo/odoo/pull/185960 This commit just adds the focus that had previously been removed to enable the input to be correctly selected so that the user can write directly on it. opw-4874194 Forward-Port-Of: odoo/odoo#215127
Original PR description
Steps: - Open any views with a search bar - Press ALT + Q (hotkey used to focus search input) - Nothing happens This behavior has been introduced by https://github.com/odoo/odoo/pull/185960 This commit just adds the focus that had previously been removed to enable the input to be correctly selected so that the user can write directly on it. opw-4874194 Forward-Port-Of: odoo/odoo#215127
Problem: - When using the same account for both discount allocation and payment method, the system failed to distinguish between the two discount lines resulting in an imbalance during accounting entry generation. Solution: - Added `amount_currency` as part of the key in the discount allocation logic to correctly differentiate between the positive and negative entries. opw-4806356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw
Original PR description
Problem: - When using the same account for both discount allocation and payment method, the system failed to distinguish between the two discount lines resulting in an imbalance during accounting entry generation. Solution: - Added `amount_currency` as part of the key in the discount allocation logic to correctly differentiate between the positive and negative entries. opw-4806356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212231
Calling external resources can lead to random failures in tests test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect. Fixes the test by not following the 301 and checking the target instead. Forward-Port-Of: odoo/odoo#215232 Forward-Port-Of: odoo/odoo#215175
Original PR description
Calling external resources can lead to random failures in tests test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect. Fixes the test by not following the 301 and checking the target instead. Forward-Port-Of: odoo/odoo#215232 Forward-Port-Of: odoo/odoo#215175
When generating a credit note for an invoice with multiple lines of the same product (same product_id, name, and price_unit) but different discounts, the system incorrectly matches both credit note lines to the same invoice line. This commit solves this issue by adding line discount to the criteria used to match credit notes lines with invoices lines. task-4876849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
When generating a credit note for an invoice with multiple lines of the same product (same product_id, name, and price_unit) but different discounts, the system incorrectly matches both credit note lines to the same invoice line. This commit solves this issue by adding line discount to the criteria used to match credit notes lines with invoices lines. task-4876849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214779
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike> Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the
Original PR description
Steps to reproduce: - create a new journal with foreign currency - create an invoice (amount:100) with this journal and set it "to check" - Go to dashboard Issue: check balance is in company currency amount but the symbol is the one from the currency of the journal Solution: Chkl: <strike>Misc and Sales/Purchase Journals should display all amounts in company currency</strike> Eventually, we decided that it would be better for the stable versions to keep the currency displayed as the one from the journals. We therefore use the same logic as for the bill/invoices opw-4349684 Forward-Port-Of: odoo/odoo#208444 Forward-Port-Of: odoo/odoo#203475
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. Forward-Port-Of
Original PR description
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. Forward-Port-Of: odoo/enterprise#83421
The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed the presence of 'client_data' in the context, leading to a KeyError during test_display_name_new_record. This fix checks for the presence of 'client_data' before attempting to call import_vat_obligations. If 'client_data' is not present, it avoids calling import_vat_obligations and raises a UserError, thus preventing the KeyError. build_error-115767 Forward-Port-Of: odoo/enterprise#84327
Original PR description
The default_get method of the 'l10n_uk.hmrc.send.wizard' model assumed the presence of 'client_data' in the context, leading to a KeyError during test_display_name_new_record. This fix checks for the presence of 'client_data' before attempting to call import_vat_obligations. If 'client_data' is not present, it avoids calling import_vat_obligations and raises a UserError, thus preventing the KeyError. build_error-115767 Forward-Port-Of: odoo/enterprise#84327
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
Original PR description
When generating the German tax report, field Kz83 was included in the XML even when the value was 0.00. This caused the exported file to be rejected by the ELSTER platform. This fix removes Kz83 from the XML when its value is null or zero. The ELSTER platform automatically calculates this field if it's missing. source: https://help.deltek.com/product/maconomy/documentation/BPMReporting/CountryReports/Appendix_Germany.html opw-4783544 Forward-Port-Of: odoo/enterprise#86978
Before this PR: - Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records. - The field label for GSTR-2B status was shown as just "Status", which could be ambiguous. After this PR: - Added `copy=False` to all three fields to prevent unintended data duplication. - Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear. OPW: 4882698 Forward-Port-Of: odoo/e
Original PR description
Before this PR: - Fields `l10n_in_exception`, `l10n_in_gst_return_period_id`, and `l10n_in_gstr2b_reconciliation_status` were copied when duplicating records. - The field label for GSTR-2B status was shown as just "Status", which could be ambiguous. After this PR: - Added `copy=False` to all three fields to prevent unintended data duplication. - Updated the label "Status" to "GSTR-2B Status" in `l10n_in.gst.return.period` to make the purpose clear. OPW: 4882698 Forward-Port-Of: odoo/enterprise#88110