Daily updates from Odoo
Tuesday, December 9, 2025
15 changes · 17.0
Resolved issues and error corrections
This update corrects a technical issue where the text displayed in the confirmation window of a button was not included in the translation files. This ensures that the text can be properly translated into different languages, improving the user experience for international users. The fix adds the necessary attribute to the XML file to allow for translation.
Original PR description
Description of the issue/feature this PR addresses: The texts from the "confirm-title" attribute of a tag are missing from the POT files. Current behavior before PR: In this line there is a text (the caption of the confirmation window): https://github.com/odoo/odoo/blob/19.0/addons/mass_mailing/views/mailing_mailing_views.xml#L66 "Ready to unleash emails?" - This text is missing from the POT file. Desired behavior after PR is merged: * These texts will apeear in POT files * Someone needs to translated them * It will show up as translated texts in UI --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where large product images on the Shop page appeared blurred. The change ensures product images maintain their correct aspect ratio when displayed, providing a better visual experience for customers. This was achieved by adding a specific CSS class to control image scaling.
Original PR description
Steps to reproduce: =================== 1- Add a product with a very large image width & publish product. 2. Go to the Shop page & type product name. -> The product image is blurred. Cause: ====== The product images have `h-100 w-100` classes which force them to fill the container dimensions exactly, ignoring their intrinsic aspect ratio. Solution: ========= Add the `object-fit-contain` class to the image. This ensures the image scales to fit within the container while preserving its aspect ratio. Side note: `object-fit-contain` class will be added only in version 17.0 In the next versions the class already exists. opw-5258658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test related to holiday tax calculations in the Belgian payroll module (l10n_be_hr_payroll) was failing due to an outdated date setting on the payslip. This update changed the payslip date to a relative one, resolving the crash that occurred in future years and ensuring the test continues to run correctly.
Original PR description
Before this commit, the test `test_compute_double_holiday_withholding_taxes_with_3_children` was testing on a payslip that was set in 2024. As this test was based on a contract starting on the system's date -2, the test would start crashing in 2026. This commit changes the payslip date to make it relative instead of fixed runbot error 230738 Forward-Port-Of: odoo/enterprise#101348
This update fixes a bug in the contact import process. Previously, if an import batch contained invalid data (like incorrect values), it wouldn't display any error messages. Now, the system will correctly identify and report these errors during batch imports, ensuring data integrity and preventing incorrect data from being added to the system.
Original PR description
Steps to reproduce ================== - Go to contact, - Import the following file ```csv id,name,active __import__.res_partner_SV_test_01,Name 1,TRUE __import__.res_partner_SV_test_02,Name 2,TRUE __import__.res_partner_SV_test_03,Name 3,TRUE __import__.res_partner_SV_test_04,Name 4,TRUE __import__.res_partner_SV_test_05,Name 5,incorrect value __import__.res_partner_SV_test_06,Name 6,TRUE __import__.res_partner_SV_test_07,Name 7,TRUE __import__.res_partner_SV_test_08,Name 8,TRUE ``` - Set the batch size to 4 - Click on the import button => Only 4 records have been imported and no error is displayed Cause of the issue ================== Errors were only checked in test mode opw-5242285
This update fixes an issue where multiple quality checks were being created for the same picking when adding additional products. The change ensures that only one quality check is generated per operation type (Receipts), streamlining the process and preventing errors. This improves efficiency and data accuracy related to stock quality control.
Original PR description
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations…
Steps to reproduce: -------------------------- 1. Install the Quality module. 2. Create a Quality Control Point with: * Control per: Control on Operation. * Operation: Receipts (set in the Operations field). 3. Create a Receipt containing one product. 4. Click the Mark as To Do button. 5. Add another product to the same Receipt and save it. Observation: -------------------------- Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation. Issue: -------------------------- No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation. Solution: -------------------------- Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created. opw-5249233
This update resolves an issue where the OCR process incorrectly assigned foreign currencies to expense items, particularly when linked to products with standard costs. The fix now allows users to correct the total amount after the OCR, ensuring accurate currency conversions and proper reimbursement processing. This prevents errors and improves the reliability of expense reporting.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236
This update fixes inaccuracies in the module description for the Danish localization (l10n_dk) within Odoo. The changes ensure accurate and clear information for users and stakeholders regarding the module's functionality. This improves the overall user experience and documentation.
Original PR description
There were some mistakes in the Danish part of the module description. This commit corrects those mistakes.
This update addresses a change in Facebook's data reporting, specifically regarding audience trends. Due to a rapid fix needed, the trend calculation wasn't fully verified, but the system now utilizes total page follows to account for potential unfollows, ensuring more accurate reporting. This improves the reliability of Facebook insights for our users.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend,…
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend, because we needed a fix rapidly, and we wasn't sure about unfollow. And indeed, `page_daily_follows` only count for positive value, unlike the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent of `page_fan_removes`... Example of data for a month: ``` page_follows 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 page_follows 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ``` So we now use `page_follows`, so the total value at a given time, and we look for the newest and oldest value (note that if we could do the same for `page_post_engagements`, then we could just make 2 APIs calls for the year stat). Task-5353390 Forward-Port-Of: odoo/enterprise#100275
This update corrects a bug where records in the `ir.model.data` table weren't properly removed when a model was unlinked. This prevented data inconsistencies and potential errors. The fix ensures data integrity by cleaning up related records, improving system stability.
Original PR description
When a model is unlinked, the `ir.model.data` related to that model wasn't cleaned up. This leaves dangling records that can generate issues. sentry-6938852090
This update ensures that users' presence status is consistently updated after they return from periods of inactivity. Previously, the system didn't always track these status changes, leading to inaccurate user presence information. This fix guarantees a more reliable and accurate representation of user availability.
Original PR description
Before this commit, the user's presence might not be updated after returning from inactivity. This occurs because the status service only sends an update if the user was away during the previous update. However, this condition doesn't account for cases where the update was never sent.
This update fixes a problem where blog post publication tests were unreliable due to inconsistent timing. By freezing time during key test steps, the tests now produce consistent results, ensuring accurate performance measurements. This improves the reliability of our blog performance metrics.
Original PR description
Some blog post are published with a post_date matching the time the test is run meaning that they are not considered published. We have multiple possibilities when _get_url_hot_query is called: - all call to /blog are executed before the publication date: 9 - some call to /blog are executed after the publication date: 11 - only the last call is executed after the publication date: ~40-50 Using freezetime after the publication date ensures a consistent result This can be easily reproduced by freezing the time on the first calls in _get_url_hot_query and not on the last one. Runbot error [55754](https://runbot.odoo.com/odoo/error/55754)
This update ensures that Luxembourg (`l10n_lu`) companies' general ledger reports correctly include vendor invoices in the required FAIA XML format. A recent change in FAIA reporting standards necessitates the addition of a 'PurchaseInvoices' tag, and this PR implements the necessary template to meet these requirements.
Original PR description
Since version 2.01 of FAIA, it is a requirement to include the `PurchaseInvoices` tag in the FAIA XML. With a `l10n_lu` company: - Create a vendor bill. - In the general ledger, download the FAIA XML report. In the generated XML document, the vendor bill will not appear under `PurchaseInvoices`. The `PurchaseInvoices` section is meant to mirror the `SalesInvoices` section and contains the exact same structure. This PR implements a generic template for both. **Specs and source** (in `FAIA_v2.01_full`): https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360572
This update adds a specific group to the teleworking field within the HR contract and employee records. This ensures accurate reporting of employee benefits for Swiss tax compliance (ELM transmission), addressing a previous reporting issue. The change improves the accuracy of payroll calculations for Swiss businesses using the Enterprise module.
This update resolves an issue where Odoo's demo data installation caused problems when used with databases that don't use US dollars. The fix ensures the demo data integrates correctly with various currency settings, improving compatibility across different company setups. The change is a minor correction to avoid a complex refactoring.
Original PR description
Currently in the `_merge_move_itemgetter` the system call `self.company_id.currency_id.decimal_places`. However the demo data of stock create a database with US currency and some `stock.move` in it. If we have an existing database with EUR for example. The upper call will return a `currency_id.decimal_places` since we have multiple currency. The best solution, would be to split `_action_confirm` to do a loop by company. But it would need a small refactoring and we will do a minimal diff to fix this issue. Using the smallest currency among all the company is not always correct but it's a super edge case and we should probably remove this code since it went to far. Close #230965, #234078
This update fixes an error in the Peru tax return (RVIE Sales 14.4) report that incorrectly included credit note amounts in the tax columns. The change aligns with SUNAT regulations, ensuring accurate reporting of credit notes based on their modification period, improving compliance and reducing potential tax discrepancies.
Original PR description
Backport of 5151bbf70a50d3762c4979365fb5412d0a888840 How to reproduce the issue: With l10n_pe localization: - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466